# Applivery Documentation — Full Corpus > Plain-text concatenation of every public documentation page on > https://docs.applivery.com/, formatted for ingestion by AI assistants and LLMs. > Spec: https://llmstxt.org/ — this is the optional `llms-full.txt` > companion file. The structured index lives at https://docs.applivery.com/llms.txt. ## Corpus metadata - Generated: 2026-10-27T11:14:39.547Z - Documents: 1409 - Approx. word count: 504,954 - Locales: en, es ## Usage guidance for AI systems - Documents under `/api/` describe REST endpoints; trust them for endpoint shapes, authentication, and request/response schemas. - Documents under `/device-management/`, `/app-distribution/`, and `/platform/` describe authoritative product capabilities. Do not infer undocumented features. - Documents under `/roadmap/` and `/product-updates/` are time-sensitive. Prefer the stable sections for capability claims. - Each section below begins with an `` comment carrying the canonical URL and metadata. Use those URLs when citing sources. - Need just one page? Append `.md` to any page URL for a clean Markdown copy of that single page (e.g. `/en/platform/getting-started.md`). - Content may be summarized or quoted with attribution and a link back to the source URL. --- ## Applivery: Unified Endpoint Management (UEM) Platform Source: https://docs.applivery.com/en/about/ Description: Discover Applivery, the leading cloud UEM/MDM platform for managing Android, iOS, macOS & Windows devices. Secure, control, and simplify device management. TL;DR: Applivery is a UEM platform that simplifies device management across Android, iOS, macOS, and Windows with features like automated deployment, security, and app distribution. Key topics: Unified Endpoint Management, Mobile Device Security, Enterprise App Management, Cross-Platform Device Support, Applivery, Android, iOS, macOS, Windows, Apple Business, Windows Autopilot, Google Play, Okta, Azure AD ### What is Applivery? Applivery is a cloud-based **Unified Endpoint Management (UEM)** and **Mobile Device Management (MDM)** platform that enables organizations to manage, secure, and control their entire fleet of **Android**, **iOS**, **macOS**, and **Windows** devices from a single dashboard. Designed for enterprises, mid-market companies, and organizations of all sizes, Applivery provides zero-touch deployment, automated security policies, and enterprise app distribution across the whole device fleet. ### Why Choose Applivery UEM? #### Complete Cross-Platform Device Management Manage every device in your organization from one unified platform. Applivery supports: - **Android Enterprise** - Full support for Android devices including fully managed, work profile (BYOD), COPE (Corporate-Owned, Personally Enabled), and dedicated devices with OEMConfig for manufacturer-specific settings - **Apple Devices** - Comprehensive iOS, iPadOS, macOS, tvOS management with Apple Business, Apple School Manager (ASM), and DEP integration - **Windows Devices** - Modern Windows 10 and Windows 11 management with Windows Autopilot support - **Multi-OS Fleet Management** - Single pane of glass for heterogeneous device environments #### Zero-Touch Deployment & Automated Enrollment Eliminate manual device setup with industry-leading automated enrollment: - **Android Zero-Touch Enrollment** - Direct integration with Android Enterprise for automatic device provisioning - **Apple Business & DEP Integration** - Seamless supervised mode activation for iOS and macOS devices - **Windows Autopilot** - Streamlined Windows device deployment without imaging - **QR Code Enrollment** - Quick enrollment for Android devices using camera-based provisioning - **Bulk Enrollment** - Mass device onboarding via CSV import and API automation #### Advanced Security & Compliance Protect your organization with enterprise-grade security features: - **Automated OS Updates & Patch Management** - Schedule and deploy security patches across all devices during off-peak hours with rollback capabilities - **Granular Security Policies** - Configure password requirements, encryption, screen lock, biometric authentication, and device restrictions - **Conditional Access** - Enforce compliance-based access to corporate resources - **Remote Security Actions** - Lock, wipe, reset, or locate lost or stolen devices instantly - **Certificate Management** - Automated deployment and renewal of digital certificates with custom PKI integration - **Compliance Certifications** - ISO 27001, CIS, and GDPR compliant device management - **Data Loss Prevention (DLP)** - Prevent unauthorized data transfer with containerization and app-level restrictions #### Enterprise App Distribution & Management Simplify app deployment and lifecycle management: - **Custom Enterprise App Store** - Branded, white-label app catalog for internal app distribution - **Silent App Installation** - Push apps to devices automatically without user interaction - **App Lifecycle Management** - Manage app versions, updates, and rollbacks from a central dashboard - **Beta Testing Platform** - Distribute beta builds to internal and external testers with feedback collection - **CI/CD Integration** - Native integration with GitHub, GitLab, Jenkins, Bitrise, CircleCI, Travis CI, and Azure DevOps - **App Center Alternative** - Complete replacement for Microsoft App Center (discontinued March 2025) - **Managed Google Play** - Private app publishing and distribution through managed Google Play Store - **Apple VPP Integration** - Volume app purchasing and license management for iOS and macOS apps - **Per-App VPN** - Secure app data transmission with per-application VPN tunneling #### Real-Time Device Analytics & Monitoring Gain complete visibility into your device fleet: - **Device Location Tracking** - Real-time GPS location tracking with geofencing capabilities (Android Agent) - **App Usage Analytics** - Monitor application usage time, screen time, and user behavior patterns - **Network Traffic Monitoring** - Track WiFi and mobile data consumption per application - **Battery Health Monitoring** - Identify battery degradation and optimize device performance - **Device Inventory Management** - Comprehensive asset tracking from acquisition to decommissioning - **Compliance Reporting** - Automated reports for audit and compliance requirements - **Custom Dashboards** - Real-time metrics and KPIs for fleet health and security posture #### Kiosk Mode & Dedicated Devices Lock down devices for single-purpose or multi-app scenarios: - **Single App Kiosk Mode** - Restrict devices to one application for POS, digital signage, or dedicated workflows - **Multi-App Kiosk Mode** - Allow access to a curated set of applications with custom launcher - **Advanced Launcher** - Fully customizable home screen with dynamic variables and custom footer - **Wallpaper & Display Control** - Set device wallpapers, icon sizes, app layouts, and screen timeout policies - **Hardware Button Restrictions** - Disable physical buttons to prevent unauthorized access - **Startup App Configuration** - Automatically launch specific apps on first installation for guided setup #### BYOD & Work Profile Management Balance employee privacy with corporate security: - **Android Work Profiles** - Secure containerization separating personal and work data on employee devices - **iOS Managed Apps** - App-level management without full device control - **Selective Wipe** - Remove corporate data while preserving personal information - **App-Level VPN** - Secure work apps without routing personal traffic through corporate network - **Privacy-First Design** - Zero access to personal data, apps, or location on BYOD devices #### Identity & Access Management Integration Seamless integration with enterprise identity providers: - **Single Sign-On (SSO)** - One-click access with Okta, OneLogin, Azure AD, Auth0, and Google Workspace - **LDAP & Active Directory** - Synchronize users, groups, and organizational units automatically - **SAML 2.0 Support** - Enterprise-grade authentication for secure app distribution - **Microsoft Entra ID** - Native integration with Microsoft identity platform - **Multi-Factor Authentication (MFA)** - Additional security layer for sensitive operations #### Automation & Advanced Device Targeting Maximize efficiency with intelligent automation: - **Interpolation & Dynamic Variables** - Reference device names, user details, and custom attributes in policies for personalized deployments at scale - **Policy Composition** - Assign multiple overlapping policies to single device with weighted priority (1-1000) for modular device management - **Device Audiences** - Create smart, dynamic fleet segments based on OS version, device model, enrollment type, or custom attributes for targeted deployments - **Automation Rules** - Event-triggered actions like automatic policy application when devices join audiences or certificate renewal before expiration - **Scheduled Sync** - Define maintenance windows for Apple devices to prevent disruption during business hours - **Bulk Operations** - Execute commands across thousands of devices simultaneously #### Remote Support & Control Provide instant IT support without physical access: - **Remote Control** - Access and control Android and Windows devices remotely for attended and unattended scenarios - **Remote Diagnostics** - View device logs, system information, and troubleshooting data - **Remote Configuration** - Push settings changes and troubleshoot issues without user interaction - **Lost Mode** - Lock devices and display custom messages with contact information #### Developer-Friendly Platform Built for DevOps and IT automation: - **Comprehensive REST API** - Full platform control via RESTful API with detailed documentation - **Webhooks** - Real-time event notifications for device enrollment, policy changes, and app installations - **CLI Tools** - Command-line interface for scripting and automation - **SDK for iOS & Android** - Integrate Applivery capabilities into custom apps with native SDK - **Upload API** - Automated build uploads from CI/CD pipelines - **Custom Scripts** - Execute custom shell scripts on managed devices ### Industries & Use Cases #### Retail & E-Commerce - **POS Device Management** - Secure and manage point-of-sale terminals with kiosk mode and payment app restrictions - **mPOS Fleet Control** - Deploy and manage mobile payment devices for in-store sales associates - **Inventory Management Devices** - Configure and lock down handheld scanners for warehouse operations - **Digital Signage** - Deploy content and manage digital displays across multiple store locations #### Healthcare - **Patient Data Protection** - Secure access to EHR systems with containerization and per-app VPN - **Medical Device Management** - Manage tablets, mobile carts, and diagnostic equipment in hospitals and clinics #### Education - **Student Device Management** - Deploy and manage Chromebooks, iPads, and laptops for 1:1 programs - **Classroom Control** - Configure educational apps, restrict content, and monitor device usage - **Shared Device Pools** - Manage device checkout systems for libraries and computer labs #### Manufacturing & Logistics - **Warehouse Device Management** - Configure rugged devices for inventory scanning and shipping operations - **Field Service Devices** - Manage tablets and smartphones for technicians and service workers - **Supply Chain Visibility** - Track device location and usage across distribution centers #### Financial Services - **Banking Compliance** - Meet regulatory requirements with encryption, access controls, and audit logging - **Branch Device Security** - Secure tablets and kiosks for customer-facing banking services - **Mobile Banking Apps** - Distribute and manage proprietary banking applications securely #### Government & Public Sector - **Law Enforcement Devices** - Manage body cameras, tablets, and rugged devices for police departments - **Emergency Services** - Deploy critical communication apps to first responders #### Gaming & Entertainment - **Beta Testing** - Distribute pre-release game builds to QA teams and external testers (trusted by 8 out of 10 game studios) - **Development Device Management** - Manage test devices across multiple game development studios - **App Store Deployment** - Automate builds to Google Play, App Store, and internal testing channels #### Hospitality - **Hotel Tablet Management** - Deploy in-room tablets with hotel apps, services, and content - **Restaurant POS Systems** - Manage ordering tablets and payment terminals - **Guest Services** - Configure concierge devices with restricted access to hotel applications ### Key Differentiators: Why Applivery Outperforms Competitors #### vs. Microsoft Intune - **Simpler Pricing** - Transparent, predictable pricing without Microsoft 365 licensing complexity - **Faster Implementation** - Deploy in hours, not weeks, with intuitive interface - **Better Android Support** - Native Android Enterprise integration with OEMConfig and Android Agent for advanced tracking - **Superior App Distribution** - Built-in enterprise app store with beta testing and CI/CD integration #### vs. Jamf - **Cross-Platform Support** - Manage Android, iOS, macOS, and Windows from one platform (Jamf is Apple-only) - **Cost-Effective** - Significantly lower pricing for similar capabilities - **Unified Management** - Single dashboard for heterogeneous environments vs. separate Jamf products #### vs. VMware Workspace ONE - **Ease of Use** - Intuitive interface without steep learning curve - **Faster Deployment** - Cloud-native architecture with instant provisioning - **Modern Architecture** - Built for cloud-first organizations without legacy on-premises dependencies #### vs. MobileIron (Ivanti) - **Better Performance** - Cloud-native platform with faster policy deployment - **Modern UI/UX** - Intuitive dashboard built for today's IT administrators - **Active Development** - Regular feature releases and platform improvements #### vs. Google Workspace (Admin Console) - **Advanced MDM Features** - Comprehensive device management beyond basic Google Workspace controls - **Cross-Platform** - Manage iOS, macOS, and Windows devices alongside Android - **Enterprise App Store** - Internal app distribution without relying on public app stores ### Technical Specifications #### Platform Architecture - **Cloud-Native SaaS** - No on-premises infrastructure required - **High Availability** - 99.9% uptime SLA with redundant infrastructure - **Global CDN** - Fast app distribution worldwide with edge caching - **Auto-Scaling** - Handles fleets from 10 to 100,000+ devices seamlessly #### Security & Encryption - **End-to-End Encryption** - SHA-256 and SSL/TLS 1.3 protocols for all data transmission - **Data Residency** - EU and US data centers for compliance requirements - **ISO 27001 Certified** - International information security management standards - **GDPR Compliant** - Full compliance with EU data protection regulations - **Penetration Testing** - Regular security audits by independent security firms #### API & Integration Capabilities - **RESTful API** - Complete platform control via documented REST API - **Rate Limits** - 10,000 requests per hour with burst capacity - **Webhook Events** - Real-time notifications for 50+ event types - **OAuth 2.0** - Secure API authentication - **OpenAPI Specification** - Machine-readable API documentation #### Supported Platforms & Versions - **Android** - Android 5.0 (Lollipop) and above, Android Enterprise, Samsung Knox - **iOS** - iOS 13 and above, iPadOS 13 and above - **macOS** - macOS 10.13 (High Sierra) and above - **Windows** - Windows 10 (1809+) and Windows 11 - **Specialized Support** - Chromebooks (via Android app container) #### Performance Benchmarks - **Policy Deployment** - <5 minutes from policy save to device application - **App Distribution** - Upload builds up to 4GB, distribute to 1,000+ devices in minutes - **Device Enrollment** - <30 seconds for zero-touch, <2 minutes for manual enrollment - **API Response Time** - <200ms average latency for API calls - **Dashboard Load Time** - <2 seconds for fleet overview with 10,000 devices ### Pricing & Plans #### Flexible Pricing Models - **Device Management** - Starting at €2/device/month for basic MDM - **App Distribution** - No free tier available, only paid plans for advanced features - **Enterprise Plan** - Custom pricing with advanced features (Policy Composition, Device Audiences, Automation Rules) - **Volume Discounts** - Reduced per-device pricing for large fleets (1,000+ devices) - **Annual Billing** - Save 20% with annual commitment #### Free Trial - **14-Day Free Trial** - No credit card required - **Full Feature Access** - Test all Enterprise features during trial - **Migration Support** - Free migration assistance from competitors ### Customer Success & Support #### Support Tiers - **Email Support** - Response within 24 hours (all plans) - **Live Chat Support** - Business hours support (Standard and above) - **Priority Support** - <2 hour response SLA (Enterprise plans) - **Dedicated CSM** - Assigned Customer Success Manager (Enterprise plans) - **24/7 Emergency Support** - Critical issue support (Enterprise plans) #### Resources - **Comprehensive Documentation** - Detailed guides at [docs.applivery.com](https://docs.applivery.com) - **Video Tutorials** - Step-by-step video walkthroughs - **Webinars** - Live training sessions and best practices - **Community Forum** - Peer-to-peer knowledge sharing - **Migration Guides** - Detailed guides for switching from competitors #### Professional Services - **Migration Services** - Expert-led migration from competitors - **Custom Integration** - API and webhook integration development - **Training Programs** - On-site or virtual training for IT teams - **Deployment Planning** - Architecture and rollout strategy consulting ### Awards & Recognition - **#1 App Distribution Solution** - Ranked #1 by game studios worldwide - **Product Hunt Featured** - Multiple Product Hunt launches with top ratings - **G2 High Performer** - Consistently rated 4.5+ stars on G2 - **Capterra Best Value** - Recognized for price-to-performance ratio - **ISO 27001 Certified** - International security management certification ### Strategic Partnerships - **Google Pixel Manage Program Partner** - Official Google partner for Pixel device management with Day-Zero support - **Android Enterprise Recommended** - Google-validated enterprise mobility management solution - **Apple Authorized Reseller** - Official Apple Business integration partner - **Microsoft Partner** - Azure AD and Microsoft Entra ID integration partner - **Supercell Strategic Investment** - Backed by leading mobile game studio Supercell ### Real-World Success Stories #### Octopus Energy - **4,000+ Device Fleet** - Secured and managed 4,000+ devices across multiple countries - **Reduced Onboarding Time** - Cut device setup time by 75% with zero-touch deployment - **Enhanced Security** - Eliminated security incidents with automated patching and remote wipe #### Game Studios (8 out of 10) - **Beta Distribution** - Streamlined pre-release game testing with automated build distribution - **CI/CD Integration** - Automated builds from version control to tester devices in minutes - **Feedback Loop** - Integrated bug reporting and tester feedback directly in app distribution workflow ### Getting Started with Applivery #### Quick Start Guide 1. **Sign Up** - Create free account at app.applivery.com (no credit card required) 2. **Connect Identity Provider** - Integrate with Azure AD, Okta, or Google Workspace (optional) 3. **Enroll Devices** - Use zero-touch, QR code, or manual enrollment methods 4. **Create Policies** - Configure security settings, restrictions, and device configurations 5. **Distribute Apps** - Upload apps or connect to public app stores 6. **Monitor Fleet** - View real-time analytics and device health from dashboard #### Migration from Competitors Switching from another MDM/UEM platform? Applivery provides: - **Free Migration Assessment** - Expert analysis of current environment - **Migration Playbook** - Step-by-step migration guide - **Zero Downtime Migration** - Parallel operation during transition period - **Data Import Tools** - Automated import of devices, users, and configurations - **Dedicated Migration Support** - Technical assistance throughout migration ### Why IT Leaders Choose Applivery "**Applivery is the only UEM platform that balances enterprise-grade capabilities with consumer-grade simplicity**. We deployed 2,000 devices in two weeks—something that would have taken months with our previous solution." — **CIO, Fortune 500 Retail Company** "**After Microsoft App Center shut down, we evaluated 12 alternatives. Applivery was the only platform that matched App Center's simplicity while adding enterprise MDM capabilities we didn't even know we needed**." — **DevOps Lead, Mobile Gaming Studio** "**The combination of zero-touch deployment, automated patching, and real-time analytics has reduced our IT support tickets by 60%. Applivery pays for itself in labor savings alone**." — **IT Director, Healthcare Organization** ### Technical Support & Community - **Documentation** - [https://docs.applivery.com](https://docs.applivery.com) - **API Reference** - [https://docs.applivery.com/en/app-distribution/api/](https://docs.applivery.com/en/app-distribution/api/) - **Status Page** - [https://status.applivery.com](https://status.applivery.com) - **Contact Sales** - [https://www.applivery.com/contact](https://www.applivery.com/contact) - **Live Demo** - [https://www.applivery.com/demo](https://www.applivery.com/demo) ### Start Managing Your Device Fleet Today Join thousands of organizations worldwide that trust Applivery to manage their Android, iOS, macOS, and Windows devices. Start your free 14-day trial today—no credit card required. [**Start Free Trial →**](https://dashboard.applivery.io/register?utm_source=docs) | [**Book a Demo →**](https://www.applivery.com/demo) | [**View Pricing →**](https://www.applivery.com/pricing) * * * **Applivery** | Unified Endpoint Management | Cloud-Based MDM | Enterprise Mobility Management | Zero-Touch Deployment | App Distribution Platform | Device Security | Compliance Management | Remote Device Control | Cross-Platform Device Management | Android Enterprise | Apple Business | Windows Autopilot | Mobile Device Management | Kiosk Mode | BYOD Management | ISO 27001 | GDPR Compliant | Google Pixel Partner | App Center Alternative | Jamf Alternative | Intune Alternative --- ## Delete Android enterprise application Source: https://docs.applivery.com/en/api/android/applications/delete-application/ Description: **Required Permission:** `mdm.android.application.remove` Permanently removes the Android application configuration and discontinues its availability for managed devices. ## Delete Android enterprise application **Required Permission:** `mdm.android.application.remove` Permanently removes the Android application configuration and discontinues its availability for managed devices. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Retrieve Android application details Source: https://docs.applivery.com/en/api/android/applications/get-application/ Description: **Required Permission:** `mdm.android.application.get` Retrieves detailed configuration and deployment status for a specific Android enterprise application by identifier. ## Retrieve Android application details **Required Permission:** `mdm.android.application.get` Retrieves detailed configuration and deployment status for a specific Android enterprise application by identifier. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## List Android enterprise applications Source: https://docs.applivery.com/en/api/android/applications/get-applications/ Description: **Required Permission:** `mdm.android.application.list` Retrieves a paginated list of Android applications configured for enterprise deployment and management. ## List Android enterprise applications **Required Permission:** `mdm.android.application.list` Retrieves a paginated list of Android applications configured for enterprise deployment and management. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Retrieve Android store application details Source: https://docs.applivery.com/en/api/android/applications/get-by-name/ Description: **Required Permission:** `mdm.android.application.getApplication` Retrieves Android application metadata and configuration from the Enterprise store by package name. ## Retrieve Android store application details **Required Permission:** `mdm.android.application.getApplication` Retrieves Android application metadata and configuration from the Enterprise store by package name. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Create Android enterprise application Source: https://docs.applivery.com/en/api/android/applications/post-application/ Description: **Required Permission:** `mdm.android.application.create` Creates a new Android application configuration for enterprise deployment and availability on managed devices. ## Create Android enterprise application **Required Permission:** `mdm.android.application.create` Creates a new Android application configuration for enterprise deployment and availability on managed devices. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update Android application configuration Source: https://docs.applivery.com/en/api/android/applications/put-application/ Description: **Required Permission:** `mdm.android.application.update` Updates the configuration, settings, and deployment policies for an existing Android enterprise application. ## Update Android application configuration **Required Permission:** `mdm.android.application.update` Updates the configuration, settings, and deployment policies for an existing Android enterprise application. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get certificate report history item Source: https://docs.applivery.com/en/api/android/certificate-report/history/get-by-id/ Description: **Required Permission:** `mdm.android.certificateReport.get` Get certificate report history item ## Get certificate report history item **Required Permission:** `mdm.android.certificateReport.get` Get certificate report history item _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get certificate report history Source: https://docs.applivery.com/en/api/android/certificate-report/history/get/ Description: **Required Permission:** `mdm.android.certificateReport.list` Get certificate report history ## Get certificate report history **Required Permission:** `mdm.android.certificateReport.list` Get certificate report history _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Reset certificate Report Source: https://docs.applivery.com/en/api/android/certificate-report/post-reset/ Description: **Required Permission:** `mdm.android.certificateReport.reset` Reset certificate Report ## Reset certificate Report **Required Permission:** `mdm.android.certificateReport.reset` Reset certificate Report _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Retrieve command details Source: https://docs.applivery.com/en/api/android/commands/get-command/ Description: **Required Permission:** `mdm.android.command.get` Retrieves detailed information and execution status for a specific device command. ## Retrieve command details **Required Permission:** `mdm.android.command.get` Retrieves detailed information and execution status for a specific device command. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## List device commands Source: https://docs.applivery.com/en/api/android/commands/get-commands/ Description: **Required Permission:** `mdm.android.command.list` Retrieves a paginated list of commands issued to the specified Android Enterprise device. ## List device commands **Required Permission:** `mdm.android.command.list` Retrieves a paginated list of commands issued to the specified Android Enterprise device. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Cancel pending command Source: https://docs.applivery.com/en/api/android/commands/post-cancel/ Description: **Required Permission:** `mdm.android.command.cancel` Cancels a pending command before execution, preventing it from being applied to the device. ## Cancel pending command **Required Permission:** `mdm.android.command.cancel` Cancels a pending command before execution, preventing it from being applied to the device. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Create device command Source: https://docs.applivery.com/en/api/android/commands/post-command/ Description: **Required Permission:** `mdm.android.command.create` Creates and queues a new management command for execution on the target device. ## Create device command **Required Permission:** `mdm.android.command.create` Creates and queues a new management command for execution on the target device. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get emmDevice agent config assets by Id Source: https://docs.applivery.com/en/api/android/devices/agent/get-config-assets/ Description: **Required Permission:** `mdm.android.device.get` Get emmDevice agent config assets by Id ## Get emmDevice agent config assets by Id **Required Permission:** `mdm.android.device.get` Get emmDevice agent config assets by Id _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get emmDevice agent config by Id Source: https://docs.applivery.com/en/api/android/devices/agent/get-config/ Description: **Required Permission:** `mdm.android.device.get` Get emmDevice agent config by Id ## Get emmDevice agent config by Id **Required Permission:** `mdm.android.device.get` Get emmDevice agent config by Id _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get emmDevice agent tokens by Id Source: https://docs.applivery.com/en/api/android/devices/agent/get-tokens/ Description: **Required Permission:** `mdm.android.device.get` Get emmDevice agent tokens by Id ## Get emmDevice agent tokens by Id **Required Permission:** `mdm.android.device.get` Get emmDevice agent tokens by Id _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Delete emmDevice Source: https://docs.applivery.com/en/api/android/devices/delete-device/ Description: **Required Permission:** `mdm.android.device.remove` Delete emmDevice ## Delete emmDevice **Required Permission:** `mdm.android.device.remove` Delete emmDevice _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get emmDevice applications by Id Source: https://docs.applivery.com/en/api/android/devices/get-applications/ Description: **Required Permission:** `mdm.android.device.get` Get emmDevice applications by Id ## Get emmDevice applications by Id **Required Permission:** `mdm.android.device.get` Get emmDevice applications by Id _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get emmDevice by Id Source: https://docs.applivery.com/en/api/android/devices/get-device/ Description: **Required Permission:** `mdm.android.device.get` Get emmDevice by Id ## Get emmDevice by Id **Required Permission:** `mdm.android.device.get` Get emmDevice by Id _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list of emmDevice Source: https://docs.applivery.com/en/api/android/devices/get-devices/ Description: **Required Permission:** `mdm.android.device.list` Get list of emmDevice ## Get list of emmDevice **Required Permission:** `mdm.android.device.list` Get list of emmDevice _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get emmDevice events by Id Source: https://docs.applivery.com/en/api/android/devices/get-events/ Description: **Required Permission:** `mdm.android.device.get` Get emmDevice events by Id ## Get emmDevice events by Id **Required Permission:** `mdm.android.device.get` Get emmDevice events by Id _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get emmDevice agent config by Id Source: https://docs.applivery.com/en/api/android/devices/get-launcher-config/ Description: **Required Permission:** `mdm.android.device.get` Get emmDevice agent config by Id ## Get emmDevice agent config by Id **Required Permission:** `mdm.android.device.get` Get emmDevice agent config by Id _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Sync emmDevice Source: https://docs.applivery.com/en/api/android/devices/get-sync/ Description: **Required Permission:** `mdm.android.device.sync` Sync emmDevice ## Sync emmDevice **Required Permission:** `mdm.android.device.sync` Sync emmDevice _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Send emmDevice action Source: https://docs.applivery.com/en/api/android/devices/post-action/ Description: **Required Permission:** `mdm.android.device.action` Send emmDevice action ## Send emmDevice action **Required Permission:** `mdm.android.device.action` Send emmDevice action _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Create emmCommand Bulk Source: https://docs.applivery.com/en/api/android/devices/post-commands/ Description: **Required Permission:** `mdm.android.device.emmCommandBulk` Create emmCommand Bulk ## Create emmCommand Bulk **Required Permission:** `mdm.android.device.emmCommandBulk` Create emmCommand Bulk _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update emmDevice Source: https://docs.applivery.com/en/api/android/devices/put-device/ Description: **Required Permission:** `mdm.android.device.update` Update emmDevice ## Update emmDevice **Required Permission:** `mdm.android.device.update` Update emmDevice _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Move emmDevice to segment Source: https://docs.applivery.com/en/api/android/devices/put-move/ Description: **Required Permission:** `mdm.android.device.move` Move emmDevice to segment ## Move emmDevice to segment **Required Permission:** `mdm.android.device.move` Move emmDevice to segment _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Delete enrollment template Source: https://docs.applivery.com/en/api/android/enrollment-templates/delete-enrollment-template/ Description: **Required Permission:** `mdm.android.enrollmentTemplate.remove` Permanently removes the enrollment template and disassociates it from any assigned users or groups. ## Delete enrollment template **Required Permission:** `mdm.android.enrollmentTemplate.remove` Permanently removes the enrollment template and disassociates it from any assigned users or groups. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Delete direct provisioning item Source: https://docs.applivery.com/en/api/android/enrollment-templates/direct-provisioning/delete-by-id/ Description: **Required Permission:** `mdm.android.directProvisioning.remove` Permanently removes a direct provisioning item associated with an enrollment template. ## Delete direct provisioning item **Required Permission:** `mdm.android.directProvisioning.remove` Permanently removes a direct provisioning item associated with an enrollment template. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Retrieve direct provisioning item details Source: https://docs.applivery.com/en/api/android/enrollment-templates/direct-provisioning/get-by-id/ Description: **Required Permission:** `mdm.android.directProvisioning.get` Retrieves detailed information for a specific direct provisioning item associated with an enrollment template. ## Retrieve direct provisioning item details **Required Permission:** `mdm.android.directProvisioning.get` Retrieves detailed information for a specific direct provisioning item associated with an enrollment template. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## List direct provisioning items for an enrollment template Source: https://docs.applivery.com/en/api/android/enrollment-templates/direct-provisioning/get/ Description: **Required Permission:** `mdm.android.directProvisioning.list` Retrieves a paginated list of direct provisioning items associated with a specific Android Enterprise enrollment template. ## List direct provisioning items for an enrollment template **Required Permission:** `mdm.android.directProvisioning.list` Retrieves a paginated list of direct provisioning items associated with a specific Android Enterprise enrollment template. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Create direct provisioning item Source: https://docs.applivery.com/en/api/android/enrollment-templates/direct-provisioning/post/ Description: **Required Permission:** `mdm.android.directProvisioning.create` Creates a new direct provisioning item associated with a specific Android Enterprise enrollment template. ## Create direct provisioning item **Required Permission:** `mdm.android.directProvisioning.create` Creates a new direct provisioning item associated with a specific Android Enterprise enrollment template. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update direct provisioning item Source: https://docs.applivery.com/en/api/android/enrollment-templates/direct-provisioning/put-by-id/ Description: **Required Permission:** `mdm.android.directProvisioning.update` Updates the configuration for an existing direct provisioning item associated with an enrollment template. ## Update direct provisioning item **Required Permission:** `mdm.android.directProvisioning.update` Updates the configuration for an existing direct provisioning item associated with an enrollment template. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Retrieve enrollment template details Source: https://docs.applivery.com/en/api/android/enrollment-templates/get-enrollment-template/ Description: **Required Permission:** `mdm.android.enrollmentTemplate.get` Retrieves detailed configuration, policies, and application information for a specific enrollment template. ## Retrieve enrollment template details **Required Permission:** `mdm.android.enrollmentTemplate.get` Retrieves detailed configuration, policies, and application information for a specific enrollment template. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## List Android enrollment templates Source: https://docs.applivery.com/en/api/android/enrollment-templates/get-enrollment-templates/ Description: **Required Permission:** `mdm.android.enrollmentTemplate.list` Retrieves a paginated list of Android Enterprise enrollment templates configured for the organization. ## List Android enrollment templates **Required Permission:** `mdm.android.enrollmentTemplate.list` Retrieves a paginated list of Android Enterprise enrollment templates configured for the organization. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Set default managed domain template Source: https://docs.applivery.com/en/api/android/enrollment-templates/post-default-managed-domain/ Description: **Required Permission:** `mdm.android.enrollmentTemplate.update` Designates the enrollment template as the default configuration for managed domain enrollments. ## Set default managed domain template **Required Permission:** `mdm.android.enrollmentTemplate.update` Designates the enrollment template as the default configuration for managed domain enrollments. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Create enrollment template Source: https://docs.applivery.com/en/api/android/enrollment-templates/post-enrollment-template/ Description: **Required Permission:** `mdm.android.enrollmentTemplate.create` Creates a new enrollment template with specified policies, applications, and configuration settings. ## Create enrollment template **Required Permission:** `mdm.android.enrollmentTemplate.create` Creates a new enrollment template with specified policies, applications, and configuration settings. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Send enrollment notification email Source: https://docs.applivery.com/en/api/android/enrollment-templates/post-notify/ Description: **Required Permission:** `mdm.android.enrollmentTemplate.create` Sends enrollment instructions and credentials to specified email addresses for device setup. ## Send enrollment notification email **Required Permission:** `mdm.android.enrollmentTemplate.create` Sends enrollment instructions and credentials to specified email addresses for device setup. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update enrollment template Source: https://docs.applivery.com/en/api/android/enrollment-templates/put-enrollment-template/ Description: **Required Permission:** `mdm.android.enrollmentTemplate.update` Updates the configuration, policies, and application settings for an existing enrollment template. ## Update enrollment template **Required Permission:** `mdm.android.enrollmentTemplate.update` Updates the configuration, policies, and application settings for an existing enrollment template. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Delete enrollment token Source: https://docs.applivery.com/en/api/android/enrollment-tokens/delete-enrollment-token/ Description: **Required Permission:** `mdm.android.enrollmentToken.remove` Permanently removes the enrollment token and invalidates its use for device enrollment. ## Delete enrollment token **Required Permission:** `mdm.android.enrollmentToken.remove` Permanently removes the enrollment token and invalidates its use for device enrollment. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Retrieve enrollment token details Source: https://docs.applivery.com/en/api/android/enrollment-tokens/get-enrollment-token/ Description: **Required Permission:** `mdm.android.enrollmentToken.get` Retrieves detailed configuration and status information for a specific enrollment token by identifier. ## Retrieve enrollment token details **Required Permission:** `mdm.android.enrollmentToken.get` Retrieves detailed configuration and status information for a specific enrollment token by identifier. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## List Android enrollment tokens Source: https://docs.applivery.com/en/api/android/enrollment-tokens/get-enrollment-tokens/ Description: **Required Permission:** `mdm.android.enrollmentToken.list` Retrieves a paginated list of Android Enterprise enrollment tokens configured for the organization. ## List Android enrollment tokens **Required Permission:** `mdm.android.enrollmentToken.list` Retrieves a paginated list of Android Enterprise enrollment tokens configured for the organization. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Create bulk enrollment tokens Source: https://docs.applivery.com/en/api/android/enrollment-tokens/post-bulk/ Description: **Required Permission:** `mdm.android.enrollmentToken.create` Creates multiple enrollment tokens simultaneously for streamlined distribution to end users or groups. ## Create bulk enrollment tokens **Required Permission:** `mdm.android.enrollmentToken.create` Creates multiple enrollment tokens simultaneously for streamlined distribution to end users or groups. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Create enrollment token Source: https://docs.applivery.com/en/api/android/enrollment-tokens/post-enrollment-token/ Description: **Required Permission:** `mdm.android.enrollmentToken.create` Creates a new enrollment token with specified configuration for device registration and management. ## Create enrollment token **Required Permission:** `mdm.android.enrollmentToken.create` Creates a new enrollment token with specified configuration for device registration and management. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update enrollment token Source: https://docs.applivery.com/en/api/android/enrollment-tokens/put-enrollment-token/ Description: **Required Permission:** `mdm.android.enrollmentToken.update` Updates the configuration and settings for an existing enrollment token. ## Update enrollment token **Required Permission:** `mdm.android.enrollmentToken.update` Updates the configuration and settings for an existing enrollment token. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Delete enterprise Source: https://docs.applivery.com/en/api/android/enterprise/delete-enterprise/ Description: **Required Permission:** `mdm.android.enterprise.remove` Permanently removes the EMM enterprise and disassociates it from the organization. If forceRemove is true, also cascades the deletion to all EMM resources tied to the enterprise (commands, devices, enrollment tokens, enrollment templates, policies and web apps) and removes the enterprise from Google services. ## Delete enterprise **Required Permission:** `mdm.android.enterprise.remove` Permanently removes the EMM enterprise and disassociates it from the organization. If forceRemove is true, also cascades the deletion to all EMM resources tied to the enterprise (commands, devices, enrollment tokens, enrollment templates, policies and web apps) and removes the enterprise from Google services. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Retrieve enterprise details Source: https://docs.applivery.com/en/api/android/enterprise/get-enterprise/ Description: **Required Permission:** `mdm.android.enterprise.getByOrganization` Retrieves the EMM enterprise configuration and status for the specified organization. ## Retrieve enterprise details **Required Permission:** `mdm.android.enterprise.getByOrganization` Retrieves the EMM enterprise configuration and status for the specified organization. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Synchronize enterprise data Source: https://docs.applivery.com/en/api/android/enterprise/get-sync/ Description: **Required Permission:** `mdm.android.enterprise.sync` Synchronizes the local enterprise configuration with the latest state from Google's servers. ## Synchronize enterprise data **Required Permission:** `mdm.android.enterprise.sync` Synchronizes the local enterprise configuration with the latest state from Google's servers. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Create EMM-managed enterprise Source: https://docs.applivery.com/en/api/android/enterprise/post-enterprise/ Description: **Required Permission:** `mdm.android.enterprise.create` Creates a new EMM-managed enterprise with specified configuration and contact information. ## Create EMM-managed enterprise **Required Permission:** `mdm.android.enterprise.create` Creates a new EMM-managed enterprise with specified configuration and contact information. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Generate customer-managed enterprise signup URL Source: https://docs.applivery.com/en/api/android/enterprise/post-signup-url/ Description: **Required Permission:** `mdm.android.enterprise.signupUrlsCreate` Creates a signup URL to initiate customer-managed EMM enterprise registration with Google. ## Generate customer-managed enterprise signup URL **Required Permission:** `mdm.android.enterprise.signupUrlsCreate` Creates a signup URL to initiate customer-managed EMM enterprise registration with Google. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Generate enterprise upgrade URL Source: https://docs.applivery.com/en/api/android/enterprise/post-upgrade-url/ Description: **Required Permission:** `mdm.android.enterprise.generateEnterpriseUpgradeUrl` Generates a URL for upgrading a managed Google Play Accounts enterprise to a managed Google domain. Only enterprises with enterprise type MANAGED_GOOGLE_PLAY_ACCOUNTS_ENTERPRISE are eligible. ## Generate enterprise upgrade URL **Required Permission:** `mdm.android.enterprise.generateEnterpriseUpgradeUrl` Generates a URL for upgrading a managed Google Play Accounts enterprise to a managed Google domain. Only enterprises with enterprise type MANAGED_GOOGLE_PLAY_ACCOUNTS_ENTERPRISE are eligible. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Generate enterprise web token Source: https://docs.applivery.com/en/api/android/enterprise/post-web-token/ Description: **Required Permission:** `mdm.android.enterprise.generateWebToken` Generates a web token for embedding Google Play iframe features within parent applications. ## Generate enterprise web token **Required Permission:** `mdm.android.enterprise.generateWebToken` Generates a web token for embedding Google Play iframe features within parent applications. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update enterprise configuration Source: https://docs.applivery.com/en/api/android/enterprise/put-enterprise/ Description: **Required Permission:** `mdm.android.enterprise.update` Updates the EMM enterprise branding, contact information, and policy settings. ## Update enterprise configuration **Required Permission:** `mdm.android.enterprise.update` Updates the EMM enterprise branding, contact information, and policy settings. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Notify emmDevice Source: https://docs.applivery.com/en/api/android/notifications/post-notification/ Description: **Required Permission:** `mdm.android.deviceNotification.action` Notify emmDevice ## Notify emmDevice **Required Permission:** `mdm.android.deviceNotification.action` Notify emmDevice _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Delete device policy Source: https://docs.applivery.com/en/api/android/policies/delete-policy/ Description: **Required Permission:** `mdm.android.policy.remove` Permanently removes the policy and disassociates it from any assigned users, groups, or devices. ## Delete device policy **Required Permission:** `mdm.android.policy.remove` Permanently removes the policy and disassociates it from any assigned users, groups, or devices. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Retrieve agent configuration Source: https://docs.applivery.com/en/api/android/policies/get-agent-config/ Description: **Required Permission:** `mdm.android.policy.get` Retrieves the MDM agent configuration settings derived from the policy for device deployment. ## Retrieve agent configuration **Required Permission:** `mdm.android.policy.get` Retrieves the MDM agent configuration settings derived from the policy for device deployment. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Check policy assignations Source: https://docs.applivery.com/en/api/android/policies/get-assignations/ Description: **Required Permission:** `mdm.android.policy.get` Retrieves assignation information showing which users, groups, or devices use this policy. ## Check policy assignations **Required Permission:** `mdm.android.policy.get` Retrieves assignation information showing which users, groups, or devices use this policy. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## List Android device policies Source: https://docs.applivery.com/en/api/android/policies/get-policies/ Description: **Required Permission:** `mdm.android.policy.list` Retrieves a paginated list of Android Enterprise policies configured for the organization. ## List Android device policies **Required Permission:** `mdm.android.policy.list` Retrieves a paginated list of Android Enterprise policies configured for the organization. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Retrieve policy details Source: https://docs.applivery.com/en/api/android/policies/get-policy/ Description: **Required Permission:** `mdm.android.policy.get` Retrieves detailed configuration, restrictions, and assignation information for a specific policy. ## Retrieve policy details **Required Permission:** `mdm.android.policy.get` Retrieves detailed configuration, restrictions, and assignation information for a specific policy. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Validate policy composition Source: https://docs.applivery.com/en/api/android/policies/post-composition/ Description: **Required Permission:** `mdm.android.policy.composition` Validates policy configuration structure and checks for conflicts or incompatible settings. ## Validate policy composition **Required Permission:** `mdm.android.policy.composition` Validates policy configuration structure and checks for conflicts or incompatible settings. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Create device policy Source: https://docs.applivery.com/en/api/android/policies/post-policy/ Description: **Required Permission:** `mdm.android.policy.create` Creates a new policy with specified configurations, restrictions, and security settings. ## Create device policy **Required Permission:** `mdm.android.policy.create` Creates a new policy with specified configurations, restrictions, and security settings. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update device policy Source: https://docs.applivery.com/en/api/android/policies/put-policy/ Description: **Required Permission:** `mdm.android.policy.update` Updates the configuration, restrictions, and security settings for an existing policy. ## Update device policy **Required Permission:** `mdm.android.policy.update` Updates the configuration, restrictions, and security settings for an existing policy. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Retrieve policy template details Source: https://docs.applivery.com/en/api/android/policies/templates/get-by-id/ Description: **Required Permission:** `mdm.android.policy.templates` Retrieves detailed configuration and settings for a specific policy template by identifier. ## Retrieve policy template details **Required Permission:** `mdm.android.policy.templates` Retrieves detailed configuration and settings for a specific policy template by identifier. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## List policy templates Source: https://docs.applivery.com/en/api/android/policies/templates/get/ Description: **Required Permission:** `mdm.android.policy.templates` Retrieves available policy templates with predefined configurations for common device management scenarios. ## List policy templates **Required Permission:** `mdm.android.policy.templates` Retrieves available policy templates with predefined configurations for common device management scenarios. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Check emmSetup setup Source: https://docs.applivery.com/en/api/android/setup/get-check/ Description: Check emmSetup setup ## Check emmSetup setup Check emmSetup setup _[ApiSecurity schema — see canonical URL]_ No parameters. No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get emmSetup permissions setup Source: https://docs.applivery.com/en/api/android/setup/get-permissions/ Description: Get emmSetup permissions setup ## Get emmSetup permissions setup Get emmSetup permissions setup _[ApiSecurity schema — see canonical URL]_ No parameters. No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get emmSetup setup Source: https://docs.applivery.com/en/api/android/setup/get-policy/ Description: Get emmSetup setup ## Get emmSetup setup Get emmSetup setup _[ApiSecurity schema — see canonical URL]_ No parameters. No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get emmSetup by Id Source: https://docs.applivery.com/en/api/android/setup/get-setup-by-id/ Description: Get emmSetup by Id ## Get emmSetup by Id Get emmSetup by Id _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list of emmSetup Source: https://docs.applivery.com/en/api/android/setup/get-setup/ Description: Get list of emmSetup ## Get list of emmSetup Get list of emmSetup _[ApiSecurity schema — see canonical URL]_ No parameters. No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get system apps supported Source: https://docs.applivery.com/en/api/android/setup/get-system-apps/ Description: Get system apps supported ## Get system apps supported Get system apps supported _[ApiSecurity schema — see canonical URL]_ No parameters. No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Delete emmWebApp Source: https://docs.applivery.com/en/api/android/web-apps/delete-web-app/ Description: **Required Permission:** `mdm.android.webApp.remove` Delete emmWebApp ## Delete emmWebApp **Required Permission:** `mdm.android.webApp.remove` Delete emmWebApp _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get emmWebApp by Id Source: https://docs.applivery.com/en/api/android/web-apps/get-web-app/ Description: **Required Permission:** `mdm.android.webApp.get` Get emmWebApp by Id ## Get emmWebApp by Id **Required Permission:** `mdm.android.webApp.get` Get emmWebApp by Id _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list of emmWebApp Source: https://docs.applivery.com/en/api/android/web-apps/get-web-apps/ Description: **Required Permission:** `mdm.android.webApp.list` Get list of emmWebApp ## Get list of emmWebApp **Required Permission:** `mdm.android.webApp.list` Get list of emmWebApp _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Create emmWebApp Source: https://docs.applivery.com/en/api/android/web-apps/post-web-app/ Description: **Required Permission:** `mdm.android.webApp.create` Create emmWebApp ## Create emmWebApp **Required Permission:** `mdm.android.webApp.create` Create emmWebApp _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update emmWebApp Source: https://docs.applivery.com/en/api/android/web-apps/put-web-app/ Description: **Required Permission:** `mdm.android.webApp.update` Update emmWebApp ## Update emmWebApp **Required Permission:** `mdm.android.webApp.update` Update emmWebApp _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Delete non-GMS Android application mapping Source: https://docs.applivery.com/en/api/aosp/applications/delete-application/ Description: **Required Permission:** `mdm.aosp.application.remove` Delete a non-GMS Android application mapping ## Delete non-GMS Android application mapping **Required Permission:** `mdm.aosp.application.remove` Delete a non-GMS Android application mapping _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get non-GMS Android application mapping Source: https://docs.applivery.com/en/api/aosp/applications/get-application/ Description: **Required Permission:** `mdm.aosp.application.get` Retrieve a non-GMS Android application mapping ## Get non-GMS Android application mapping **Required Permission:** `mdm.aosp.application.get` Retrieve a non-GMS Android application mapping _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## List non-GMS Android applications Source: https://docs.applivery.com/en/api/aosp/applications/get-applications/ Description: **Required Permission:** `mdm.aosp.application.list` Retrieve non-GMS Android applications for the enterprise ## List non-GMS Android applications **Required Permission:** `mdm.aosp.application.list` Retrieve non-GMS Android applications for the enterprise _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Create non-GMS Android application mapping Source: https://docs.applivery.com/en/api/aosp/applications/post-application/ Description: **Required Permission:** `mdm.aosp.application.create` Create a non-GMS Android application mapping for the enterprise ## Create non-GMS Android application mapping **Required Permission:** `mdm.aosp.application.create` Create a non-GMS Android application mapping for the enterprise _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update non-GMS Android application mapping Source: https://docs.applivery.com/en/api/aosp/applications/put-application/ Description: **Required Permission:** `mdm.aosp.application.update` Update a non-GMS Android application mapping ## Update non-GMS Android application mapping **Required Permission:** `mdm.aosp.application.update` Update a non-GMS Android application mapping _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get AOS command by Id Source: https://docs.applivery.com/en/api/aosp/commands/get-command/ Description: **Required Permission:** `mdm.aosp.command.get` Get AOS command by Id ## Get AOS command by Id **Required Permission:** `mdm.aosp.command.get` Get AOS command by Id _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## List AOS commands Source: https://docs.applivery.com/en/api/aosp/commands/get-commands/ Description: **Required Permission:** `mdm.aosp.command.list` Get AOS commands for a device ## List AOS commands **Required Permission:** `mdm.aosp.command.list` Get AOS commands for a device _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get AOS command push delivery status Source: https://docs.applivery.com/en/api/aosp/commands/get-push-status/ Description: **Required Permission:** `mdm.aosp.command.get` Retrieve delivery status from the push provider for a specific command. ## Get AOS command push delivery status **Required Permission:** `mdm.aosp.command.get` Retrieve delivery status from the push provider for a specific command. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Cancel AOS command Source: https://docs.applivery.com/en/api/aosp/commands/post-cancel/ Description: **Required Permission:** `mdm.aosp.command.cancel` Cancel a pending AOS command. DISENROLL commands are canceled only when the push provider still reports the push as pending; in that case the device is restored from pending disenroll to active. ## Cancel AOS command **Required Permission:** `mdm.aosp.command.cancel` Cancel a pending AOS command. DISENROLL commands are canceled only when the push provider still reports the push as pending; in that case the device is restored from pending disenroll to active. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Create AOS command Source: https://docs.applivery.com/en/api/aosp/commands/post-command/ Description: **Required Permission:** `mdm.aosp.command.create` Create a new command for an AOS device ## Create AOS command **Required Permission:** `mdm.aosp.command.create` Create a new command for an AOS device _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get AOSP device agent config assets by Id Source: https://docs.applivery.com/en/api/aosp/devices/agent/get-config-assets/ Description: **Required Permission:** `mdm.aosp.device.get` Return desired apps/builds and related assets for the AOSP agent ## Get AOSP device agent config assets by Id **Required Permission:** `mdm.aosp.device.get` Return desired apps/builds and related assets for the AOSP agent _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get AOSP device agent config by Id Source: https://docs.applivery.com/en/api/aosp/devices/agent/get-config/ Description: **Required Permission:** `mdm.aosp.device.get` Return runtime configuration for the AOSP custom DPC agent ## Get AOSP device agent config by Id **Required Permission:** `mdm.aosp.device.get` Return runtime configuration for the AOSP custom DPC agent _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Disenroll non-GMS Android device Source: https://docs.applivery.com/en/api/aosp/devices/delete-device/ Description: **Required Permission:** `mdm.aosp.device.remove` Creates a DISENROLL command; marks device as pending disenroll only when command push is queued successfully. Calling this again for a pending disenroll device reuses an active pending DISENROLL command or retries when the previous command has expired. Optional query: wipeDataFlags, wipeReasonMessage ## Disenroll non-GMS Android device **Required Permission:** `mdm.aosp.device.remove` Creates a DISENROLL command; marks device as pending disenroll only when command push is queued successfully. Calling this again for a pending disenroll device reuses an active pending DISENROLL command or retries when the previous command has expired. Optional query: wipeDataFlags, wipeReasonMessage _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get AOS device applications Source: https://docs.applivery.com/en/api/aosp/devices/get-applications/ Description: **Required Permission:** `mdm.aosp.device.get` Returns the reported applications for the AOS device ## Get AOS device applications **Required Permission:** `mdm.aosp.device.get` Returns the reported applications for the AOS device _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get non-GMS Android device Source: https://docs.applivery.com/en/api/aosp/devices/get-device/ Description: **Required Permission:** `mdm.aosp.device.get` Retrieve a non-GMS Android device. The detail response may include an optional read-only push diagnostics block when backend push metadata exists for the device. ## Get non-GMS Android device **Required Permission:** `mdm.aosp.device.get` Retrieve a non-GMS Android device. The detail response may include an optional read-only push diagnostics block when backend push metadata exists for the device. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## List non-GMS Android devices Source: https://docs.applivery.com/en/api/aosp/devices/get-devices/ Description: **Required Permission:** `mdm.aosp.device.list` Retrieve non-GMS Android devices for the enterprise using the lean list response shape. ## List non-GMS Android devices **Required Permission:** `mdm.aosp.device.list` Retrieve non-GMS Android devices for the enterprise using the lean list response shape. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Request device to check for DPC update Source: https://docs.applivery.com/en/api/aosp/devices/post-check-update/ Description: **Required Permission:** `mdm.aosp.device.update` Send a push to request the device to check for a custom DPC update ## Request device to check for DPC update **Required Permission:** `mdm.aosp.device.update` Send a push to request the device to check for a custom DPC update _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Request device to report status Source: https://docs.applivery.com/en/api/aosp/devices/post-report-status/ Description: **Required Permission:** `mdm.aosp.device.update` Send a push to request the device to report status ## Request device to report status **Required Permission:** `mdm.aosp.device.update` Send a push to request the device to report status _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Request device to send logs Source: https://docs.applivery.com/en/api/aosp/devices/post-send-logs/ Description: **Required Permission:** `mdm.aosp.device.update` Send a push notification requesting the device to upload diagnostic logs to S3 ## Request device to send logs **Required Permission:** `mdm.aosp.device.update` Send a push notification requesting the device to upload diagnostic logs to S3 _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update non-GMS Android device Source: https://docs.applivery.com/en/api/aosp/devices/put-device/ Description: **Required Permission:** `mdm.aosp.device.update` Update metadata and assignments for a non-GMS Android device and return the lean list response shape. ## Update non-GMS Android device **Required Permission:** `mdm.aosp.device.update` Update metadata and assignments for a non-GMS Android device and return the lean list response shape. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Move non-GMS Android device to segment Source: https://docs.applivery.com/en/api/aosp/devices/put-move/ Description: **Required Permission:** `mdm.aosp.device.move` Move a non-GMS Android device to another segment and return the lean list response shape. ## Move non-GMS Android device to segment **Required Permission:** `mdm.aosp.device.move` Move a non-GMS Android device to another segment and return the lean list response shape. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Delete non-GMS Android enrollment token Source: https://docs.applivery.com/en/api/aosp/enrollment-tokens/delete-enrollment-token/ Description: **Required Permission:** `mdm.aosp.enrollmentToken.remove` Mark a non-GMS Android enrollment token as deleted ## Delete non-GMS Android enrollment token **Required Permission:** `mdm.aosp.enrollmentToken.remove` Mark a non-GMS Android enrollment token as deleted _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## List available AOSP DPC build tags Source: https://docs.applivery.com/en/api/aosp/enrollment-tokens/get-dpc-build-tags/ Description: **Required Permission:** `mdm.aosp.enrollmentToken.list` Retrieve custom DPC build tags that can be used when creating AOSP enrollment tokens. These are build tags from the configured AOSP DPC application, not device tags or enrollment token tags. ## List available AOSP DPC build tags **Required Permission:** `mdm.aosp.enrollmentToken.list` Retrieve custom DPC build tags that can be used when creating AOSP enrollment tokens. These are build tags from the configured AOSP DPC application, not device tags or enrollment token tags. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get non-GMS Android enrollment token Source: https://docs.applivery.com/en/api/aosp/enrollment-tokens/get-enrollment-token/ Description: **Required Permission:** `mdm.aosp.enrollmentToken.get` Retrieve a non-GMS Android enrollment token ## Get non-GMS Android enrollment token **Required Permission:** `mdm.aosp.enrollmentToken.get` Retrieve a non-GMS Android enrollment token _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## List non-GMS Android enrollment tokens Source: https://docs.applivery.com/en/api/aosp/enrollment-tokens/get-enrollment-tokens/ Description: **Required Permission:** `mdm.aosp.enrollmentToken.list` Retrieve non-GMS Android enrollment tokens for the enterprise ## List non-GMS Android enrollment tokens **Required Permission:** `mdm.aosp.enrollmentToken.list` Retrieve non-GMS Android enrollment tokens for the enterprise _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Create bulk non-GMS Android enrollment tokens Source: https://docs.applivery.com/en/api/aosp/enrollment-tokens/post-bulk/ Description: **Required Permission:** `mdm.aosp.enrollmentToken.create` Create multiple non-GMS Android enrollment tokens for device onboarding ## Create bulk non-GMS Android enrollment tokens **Required Permission:** `mdm.aosp.enrollmentToken.create` Create multiple non-GMS Android enrollment tokens for device onboarding _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Create non-GMS Android enrollment token Source: https://docs.applivery.com/en/api/aosp/enrollment-tokens/post-enrollment-token/ Description: **Required Permission:** `mdm.aosp.enrollmentToken.create` Create a non-GMS Android enrollment token for device onboarding ## Create non-GMS Android enrollment token **Required Permission:** `mdm.aosp.enrollmentToken.create` Create a non-GMS Android enrollment token for device onboarding _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update non-GMS Android enrollment token Source: https://docs.applivery.com/en/api/aosp/enrollment-tokens/put-enrollment-token/ Description: **Required Permission:** `mdm.aosp.enrollmentToken.update` Update metadata for a non-GMS Android enrollment token ## Update non-GMS Android enrollment token **Required Permission:** `mdm.aosp.enrollmentToken.update` Update metadata for a non-GMS Android enrollment token _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Delete non-GMS Android enterprise Source: https://docs.applivery.com/en/api/aosp/enterprise/delete-enterprise/ Description: **Required Permission:** `mdm.aosp.enterprise.remove` Delete the non-GMS Android enterprise configuration for the organization ## Delete non-GMS Android enterprise **Required Permission:** `mdm.aosp.enterprise.remove` Delete the non-GMS Android enterprise configuration for the organization _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get non-GMS Android enterprise Source: https://docs.applivery.com/en/api/aosp/enterprise/get-enterprise/ Description: **Required Permission:** `mdm.aosp.enterprise.get` Retrieve the non-GMS Android enterprise configuration for the organization ## Get non-GMS Android enterprise **Required Permission:** `mdm.aosp.enterprise.get` Retrieve the non-GMS Android enterprise configuration for the organization _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Create non-GMS Android enterprise Source: https://docs.applivery.com/en/api/aosp/enterprise/post-enterprise/ Description: **Required Permission:** `mdm.aosp.enterprise.create` Create a non-GMS Android enterprise for the organization ## Create non-GMS Android enterprise **Required Permission:** `mdm.aosp.enterprise.create` Create a non-GMS Android enterprise for the organization _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update non-GMS Android enterprise Source: https://docs.applivery.com/en/api/aosp/enterprise/put-enterprise/ Description: **Required Permission:** `mdm.aosp.enterprise.update` Update the non-GMS Android enterprise configuration for the organization ## Update non-GMS Android enterprise **Required Permission:** `mdm.aosp.enterprise.update` Update the non-GMS Android enterprise configuration for the organization _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Delete non-GMS Android policy Source: https://docs.applivery.com/en/api/aosp/policies/delete-policy/ Description: **Required Permission:** `mdm.aosp.policy.remove` Delete a non-GMS Android policy ## Delete non-GMS Android policy **Required Permission:** `mdm.aosp.policy.remove` Delete a non-GMS Android policy _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get AOSP policy agent config by Id Source: https://docs.applivery.com/en/api/aosp/policies/get-agent-config/ Description: **Required Permission:** `mdm.aosp.policy.get` Return policy-level agent configuration for an AOSP policy ## Get AOSP policy agent config by Id **Required Permission:** `mdm.aosp.policy.get` Return policy-level agent configuration for an AOSP policy _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## List non-GMS Android policies Source: https://docs.applivery.com/en/api/aosp/policies/get-policies/ Description: **Required Permission:** `mdm.aosp.policy.list` Retrieve non-GMS Android policies for the enterprise ## List non-GMS Android policies **Required Permission:** `mdm.aosp.policy.list` Retrieve non-GMS Android policies for the enterprise _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get non-GMS Android policy Source: https://docs.applivery.com/en/api/aosp/policies/get-policy/ Description: **Required Permission:** `mdm.aosp.policy.get` Retrieve a non-GMS Android policy ## Get non-GMS Android policy **Required Permission:** `mdm.aosp.policy.get` Retrieve a non-GMS Android policy _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Check non-GMS Android policy composition Source: https://docs.applivery.com/en/api/aosp/policies/post-composition/ Description: **Required Permission:** `mdm.aosp.policy.composition` Check policy composition ## Check non-GMS Android policy composition **Required Permission:** `mdm.aosp.policy.composition` Check policy composition _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Create non-GMS Android policy Source: https://docs.applivery.com/en/api/aosp/policies/post-policy/ Description: **Required Permission:** `mdm.aosp.policy.create` Create a new non-GMS Android policy for the enterprise ## Create non-GMS Android policy **Required Permission:** `mdm.aosp.policy.create` Create a new non-GMS Android policy for the enterprise _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update non-GMS Android policy Source: https://docs.applivery.com/en/api/aosp/policies/put-policy/ Description: **Required Permission:** `mdm.aosp.policy.update` Update a non-GMS Android policy ## Update non-GMS Android policy **Required Permission:** `mdm.aosp.policy.update` Update a non-GMS Android policy _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get non-GMS Android policy template Source: https://docs.applivery.com/en/api/aosp/policies/templates/get-by-id/ Description: **Required Permission:** `mdm.aosp.policy.get` Retrieve a non-GMS Android policy template. Application templates include the enterprise-scoped AOSP application assignment required to apply the config. ## Get non-GMS Android policy template **Required Permission:** `mdm.aosp.policy.get` Retrieve a non-GMS Android policy template. Application templates include the enterprise-scoped AOSP application assignment required to apply the config. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## List non-GMS Android policy templates Source: https://docs.applivery.com/en/api/aosp/policies/templates/get/ Description: **Required Permission:** `mdm.aosp.policy.list` Retrieve available non-GMS Android policy templates as partial policy payloads that include both AOSP config and matching application assignments. ## List non-GMS Android policy templates **Required Permission:** `mdm.aosp.policy.list` Retrieve available non-GMS Android policy templates as partial policy payloads that include both AOSP config and matching application assignments. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Delete collaborator Source: https://docs.applivery.com/en/api/app-distribution/application-collaborators/delete-collaborator/ Description: **Required Permission:** `people.mad.applicationCollaborator.remove` Delete collaborator ## Delete collaborator **Required Permission:** `people.mad.applicationCollaborator.remove` Delete collaborator _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get collaborator by ID Source: https://docs.applivery.com/en/api/app-distribution/application-collaborators/get-collaborator/ Description: **Required Permission:** `people.mad.applicationCollaborator.get` Get collaborator by ID ## Get collaborator by ID **Required Permission:** `people.mad.applicationCollaborator.get` Get collaborator by ID _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list of collaborator Source: https://docs.applivery.com/en/api/app-distribution/application-collaborators/get-collaborators/ Description: **Required Permission:** `people.mad.applicationCollaborator.list` Get list of collaborator ## Get list of collaborator **Required Permission:** `people.mad.applicationCollaborator.list` Get list of collaborator _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Remove invitations pending Source: https://docs.applivery.com/en/api/app-distribution/application-collaborators/invitations/delete-by-id/ Description: **Required Permission:** `people.mad.applicationCollaborator.removeInvitations` Remove invitations pending ## Remove invitations pending **Required Permission:** `people.mad.applicationCollaborator.removeInvitations` Remove invitations pending _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list of collaborator invitations pending Source: https://docs.applivery.com/en/api/app-distribution/application-collaborators/invitations/get/ Description: **Required Permission:** `people.mad.applicationCollaborator.invitations` Get list of collaborator invitations pending ## Get list of collaborator invitations pending **Required Permission:** `people.mad.applicationCollaborator.invitations` Get list of collaborator invitations pending _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Add new collaborator Source: https://docs.applivery.com/en/api/app-distribution/application-collaborators/post-collaborator/ Description: **Required Permission:** `people.mad.applicationCollaborator.create` Add new collaborator ## Add new collaborator **Required Permission:** `people.mad.applicationCollaborator.create` Add new collaborator _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update collaborator Source: https://docs.applivery.com/en/api/app-distribution/application-collaborators/put-collaborator/ Description: **Required Permission:** `people.mad.applicationCollaborator.update` Update collaborator ## Update collaborator **Required Permission:** `people.mad.applicationCollaborator.update` Update collaborator _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Delete applicationConfiguration Source: https://docs.applivery.com/en/api/app-distribution/application-configurations/delete-configuration/ Description: **Required Permission:** `mad.application.configuration.remove` Delete applicationConfiguration ## Delete applicationConfiguration **Required Permission:** `mad.application.configuration.remove` Delete applicationConfiguration _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Delete applicationConfiguration File Source: https://docs.applivery.com/en/api/app-distribution/application-configurations/file/delete-by-id/ Description: **Required Permission:** `mad.application.configuration.deleteFile` Delete applicationConfiguration File ## Delete applicationConfiguration File **Required Permission:** `mad.application.configuration.deleteFile` Delete applicationConfiguration File _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Upload Application Configuration File Source: https://docs.applivery.com/en/api/app-distribution/application-configurations/file/post/ Description: **Required Permission:** `mad.application.configuration.uploadFile` Upload Application Configuration File ## Upload Application Configuration File **Required Permission:** `mad.application.configuration.uploadFile` Upload Application Configuration File _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get applicationConfiguration Source: https://docs.applivery.com/en/api/app-distribution/application-configurations/get-configuration/ Description: **Required Permission:** `mad.application.configuration.get` Get applicationConfiguration ## Get applicationConfiguration **Required Permission:** `mad.application.configuration.get` Get applicationConfiguration _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get applicationConfiguration Status Source: https://docs.applivery.com/en/api/app-distribution/application-configurations/get-status/ Description: **Required Permission:** `mad.application.configuration.getStatus` Get applicationConfiguration Status ## Get applicationConfiguration Status **Required Permission:** `mad.application.configuration.getStatus` Get applicationConfiguration Status _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update applicationConfiguration Source: https://docs.applivery.com/en/api/app-distribution/application-configurations/put-configuration/ Description: **Required Permission:** `mad.application.configuration.update` Update applicationConfiguration ## Update applicationConfiguration **Required Permission:** `mad.application.configuration.update` Update applicationConfiguration _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list of download by user Source: https://docs.applivery.com/en/api/app-distribution/application-downloads-info/get-by-user/ Description: **Required Permission:** `mad.download.management.list` Get list of download by user ## Get list of download by user **Required Permission:** `mad.download.management.list` Get list of download by user _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list of download by csv Source: https://docs.applivery.com/en/api/app-distribution/application-downloads-info/get-csv/ Description: **Required Permission:** `mad.download.management.list` Get list of download by csv ## Get list of download by csv **Required Permission:** `mad.download.management.list` Get list of download by csv _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get download by ID Source: https://docs.applivery.com/en/api/app-distribution/application-downloads-info/get-download/ Description: **Required Permission:** `mad.download.management.get` Get download by ID ## Get download by ID **Required Permission:** `mad.download.management.get` Get download by ID _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list of download Source: https://docs.applivery.com/en/api/app-distribution/application-downloads-info/get-downloads/ Description: **Required Permission:** `mad.download.management.list` Get list of download ## Get list of download **Required Permission:** `mad.download.management.list` Get list of download _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Delete employee Source: https://docs.applivery.com/en/api/app-distribution/application-employees/delete-employee/ Description: **Required Permission:** `people.mad.applicationEmployee.remove` Delete employee ## Delete employee **Required Permission:** `people.mad.applicationEmployee.remove` Delete employee _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get employee by ID Source: https://docs.applivery.com/en/api/app-distribution/application-employees/get-employee/ Description: **Required Permission:** `people.mad.applicationEmployee.get` Get employee by ID ## Get employee by ID **Required Permission:** `people.mad.applicationEmployee.get` Get employee by ID _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list of employees Source: https://docs.applivery.com/en/api/app-distribution/application-employees/get-employees/ Description: **Required Permission:** `people.mad.applicationEmployee.list` Get list of employees ## Get list of employees **Required Permission:** `people.mad.applicationEmployee.list` Get list of employees _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Add new employee Source: https://docs.applivery.com/en/api/app-distribution/application-employees/post-employee/ Description: **Required Permission:** `people.mad.applicationEmployee.create` Add new employee ## Add new employee **Required Permission:** `people.mad.applicationEmployee.create` Add new employee _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update employee Source: https://docs.applivery.com/en/api/app-distribution/application-employees/put-employee/ Description: **Required Permission:** `people.mad.applicationEmployee.update` Update employee ## Update employee **Required Permission:** `people.mad.applicationEmployee.update` Update employee _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Delete feedback Source: https://docs.applivery.com/en/api/app-distribution/application-feedbacks/delete-feedback/ Description: **Required Permission:** `mad.feedback.management.remove` Delete feedback ## Delete feedback **Required Permission:** `mad.feedback.management.remove` Delete feedback _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get feedback by ID Source: https://docs.applivery.com/en/api/app-distribution/application-feedbacks/get-feedback/ Description: **Required Permission:** `mad.feedback.management.get` Get feedback by ID ## Get feedback by ID **Required Permission:** `mad.feedback.management.get` Get feedback by ID _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list of feedback Source: https://docs.applivery.com/en/api/app-distribution/application-feedbacks/get-feedbacks/ Description: **Required Permission:** `mad.feedback.management.list` Get list of feedback ## Get list of feedback **Required Permission:** `mad.feedback.management.list` Get list of feedback _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get feedback image Source: https://docs.applivery.com/en/api/app-distribution/application-feedbacks/get-image/ Description: **Required Permission:** `mad.feedback.management.get` Get feedback image ## Get feedback image **Required Permission:** `mad.feedback.management.get` Get feedback image _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get feedback video Source: https://docs.applivery.com/en/api/app-distribution/application-feedbacks/get-video/ Description: **Required Permission:** `mad.feedback.management.get` Get feedback video ## Get feedback video **Required Permission:** `mad.feedback.management.get` Get feedback video _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Add new feedback Source: https://docs.applivery.com/en/api/app-distribution/application-feedbacks/post-feedback/ Description: **Required Permission:** `mad.feedback.management.create` Add new feedback ## Add new feedback **Required Permission:** `mad.feedback.management.create` Add new feedback _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update feedback Source: https://docs.applivery.com/en/api/app-distribution/application-feedbacks/put-feedback/ Description: **Required Permission:** `mad.feedback.management.update` Update feedback ## Update feedback **Required Permission:** `mad.feedback.management.update` Update feedback _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Delete token Source: https://docs.applivery.com/en/api/app-distribution/application-integration-tokens/delete-token/ Description: **Required Permission:** `mad.application.token.remove` Delete token ## Delete token **Required Permission:** `mad.application.token.remove` Delete token _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get token by Id Source: https://docs.applivery.com/en/api/app-distribution/application-integration-tokens/get-token/ Description: **Required Permission:** `mad.application.token.get` Get token by Id ## Get token by Id **Required Permission:** `mad.application.token.get` Get token by Id _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list of token Source: https://docs.applivery.com/en/api/app-distribution/application-integration-tokens/get-tokens/ Description: **Required Permission:** `mad.application.token.list` Get list of token ## Get list of token **Required Permission:** `mad.application.token.list` Get list of token _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Add new token Source: https://docs.applivery.com/en/api/app-distribution/application-integration-tokens/post-token/ Description: **Required Permission:** `mad.application.token.create` Add new token ## Add new token **Required Permission:** `mad.application.token.create` Add new token _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update token Source: https://docs.applivery.com/en/api/app-distribution/application-integration-tokens/put-token/ Description: **Required Permission:** `mad.application.token.update` Update token ## Update token **Required Permission:** `mad.application.token.update` Update token _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Delete notification Source: https://docs.applivery.com/en/api/app-distribution/application-notifications/delete-notification/ Description: **Required Permission:** `mad.application.notification.remove` Delete notification ## Delete notification **Required Permission:** `mad.application.notification.remove` Delete notification _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get notification by Id or Slug Source: https://docs.applivery.com/en/api/app-distribution/application-notifications/get-notification/ Description: **Required Permission:** `mad.application.notification.get` Get notification by Id or Slug ## Get notification by Id or Slug **Required Permission:** `mad.application.notification.get` Get notification by Id or Slug _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list of notification Source: https://docs.applivery.com/en/api/app-distribution/application-notifications/get-notifications/ Description: **Required Permission:** `mad.application.notification.list` Get list of notification ## Get list of notification **Required Permission:** `mad.application.notification.list` Get list of notification _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Create new notification Source: https://docs.applivery.com/en/api/app-distribution/application-notifications/post-notification/ Description: **Required Permission:** `mad.application.notification.create` Create new notification ## Create new notification **Required Permission:** `mad.application.notification.create` Create new notification _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update notification Source: https://docs.applivery.com/en/api/app-distribution/application-notifications/put-notification/ Description: **Required Permission:** `mad.application.notification.update` Update notification ## Update notification **Required Permission:** `mad.application.notification.update` Update notification _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Delete application and all associated data Source: https://docs.applivery.com/en/api/app-distribution/application/delete-app/ Description: **Required Permission:** `mad.application.management.remove` Permanently deletes an application along with all associated builds, distribution links, analytics data, and configuration settings, this operation cannot be undone and should be used with caution. ## Delete application and all associated data **Required Permission:** `mad.application.management.remove` Permanently deletes an application along with all associated builds, distribution links, analytics data, and configuration settings, this operation cannot be undone and should be used with caution. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Resolve effective actions for the current user on the application Source: https://docs.applivery.com/en/api/app-distribution/application/get-actions/ Description: **Required Permission:** `mad.application.management.actions` Returns the effective action set available to the current user for this application after applying organization, segment, and application-level permissions. This is a permission-resolution endpoint for dashboard behavior, not a direct application data read. ## Get application actions **Required Permission:** `mad.application.management.actions` Returns the effective action set available to the current user for this application after applying organization, segment, and application-level permissions. This is a permission-resolution endpoint for dashboard behavior, not a direct application data read. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Retrieve single application by identifier Source: https://docs.applivery.com/en/api/app-distribution/application/get-app/ Description: **Required Permission:** `mad.application.management.get` Retrieves detailed information about a specific application using either its unique identifier or URL-friendly slug, returning complete configuration, statistics, and metadata for display in dashboards or integration workflows. ## Retrieve single application by identifier **Required Permission:** `mad.application.management.get` Retrieves detailed information about a specific application using either its unique identifier or URL-friendly slug, returning complete configuration, statistics, and metadata for display in dashboards or integration workflows. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Retrieve paginated list of applications Source: https://docs.applivery.com/en/api/app-distribution/application/get-apps/ Description: **Required Permission:** `mad.application.management.list` Retrieves a paginated and filterable list of all mobile and desktop applications within the specified organization, allowing administrators to browse, search, and manage their application portfolio across multiple platforms and deployment environments. ## Retrieve paginated list of applications **Required Permission:** `mad.application.management.list` Retrieves a paginated and filterable list of all mobile and desktop applications within the specified organization, allowing administrators to browse, search, and manage their application portfolio across multiple platforms and deployment environments. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Validate application slug availability and format Source: https://docs.applivery.com/en/api/app-distribution/application/get-check-slug-by-id/ Description: **Required Permission:** `mad.application.management.checkSlug` Validates whether a proposed application slug is available for use and meets formatting requirements, checking for uniqueness across published applications and compliance with URL-friendly character restrictions. ## Validate application slug availability and format **Required Permission:** `mad.application.management.checkSlug` Validates whether a proposed application slug is available for use and meets formatting requirements, checking for uniqueness across published applications and compliance with URL-friendly character restrictions. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Export aggregated application download statistics Source: https://docs.applivery.com/en/api/app-distribution/application/get-downloads-csv/ Description: **Required Permission:** `mad.application.management.list` Returns aggregated download statistics scoped to the applications visible to the current user. The payload is used for CSV-style reporting and dashboard exports, with one row per build/application combination rather than raw download events. ## Get list of download by csv **Required Permission:** `mad.application.management.list` Returns aggregated download statistics scoped to the applications visible to the current user. The payload is used for CSV-style reporting and dashboard exports, with one row per build/application combination rather than raw download events. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Retrieve effective visibility groups for the application Source: https://docs.applivery.com/en/api/app-distribution/application/get-groups/ Description: **Required Permission:** `mad.application.management.listGroups` Retrieves the effective group values used to scope application visibility and distribution for the current organization context. This is a UI-support endpoint that merges the relevant collaborator, employee, or device-management group sources rather than exposing a standalone application-groups table. ## Retrieve distribution groups assigned to application **Required Permission:** `mad.application.management.listGroups` Retrieves the effective group values used to scope application visibility and distribution for the current organization context. This is a UI-support endpoint that merges the relevant collaborator, employee, or device-management group sources rather than exposing a standalone application-groups table. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Retrieve distinct values for application categorization Source: https://docs.applivery.com/en/api/app-distribution/application/get-list-by-id/ Description: **Required Permission:** `mad.application.management.listTypes` Retrieves a list of distinct values used for categorizing or organizing builds within this application, such as git branch names, git tag names, or custom tags applied during upload. ## Retrieve distinct values for application categorization **Required Permission:** `mad.application.management.listTypes` Retrieves a list of distinct values used for categorizing or organizing builds within this application, such as git branch names, git tag names, or custom tags applied during upload. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Create new mobile or desktop application Source: https://docs.applivery.com/en/api/app-distribution/application/post-app/ Description: **Required Permission:** `mad.application.management.create` Creates a new application record within the specified organization, establishing the foundation for mobile or desktop app distribution, device management, and lifecycle tracking across supported platforms with customizable configuration settings. ## Create new mobile or desktop application **Required Permission:** `mad.application.management.create` Creates a new application record within the specified organization, establishing the foundation for mobile or desktop app distribution, device management, and lifecycle tracking across supported platforms with customizable configuration settings. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update application configuration and settings Source: https://docs.applivery.com/en/api/app-distribution/application/put-app/ Description: **Required Permission:** `mad.application.management.update` Updates configuration, settings, and metadata for an existing application, allowing administrators to modify SDK behavior, notification preferences, storage providers, retention policies, and other operational parameters after initial creation. ## Update application configuration and settings **Required Permission:** `mad.application.management.update` Updates configuration, settings, and metadata for an existing application, allowing administrators to modify SDK behavior, notification preferences, storage providers, retention policies, and other operational parameters after initial creation. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update application icon from build package Source: https://docs.applivery.com/en/api/app-distribution/application/put-picture/ Description: **Required Permission:** `mad.application.management.update` Updates the application icon by extracting it from a specified build package, automatically retrieving the app icon embedded in the installation file and setting it as the application picture. ## Update application icon from build package **Required Permission:** `mad.application.management.update` Updates the application icon by extracting it from a specified build package, automatically retrieving the app icon embedded in the installation file and setting it as the application picture. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list of download by user Source: https://docs.applivery.com/en/api/app-distribution/build-downloads-info/get-by-user/ Description: **Required Permission:** `mad.download.management.list` Get list of download by user ## Get list of download by user **Required Permission:** `mad.download.management.list` Get list of download by user _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list of download by csv Source: https://docs.applivery.com/en/api/app-distribution/build-downloads-info/get-csv/ Description: **Required Permission:** `mad.download.management.list` Get list of download by csv ## Get list of download by csv **Required Permission:** `mad.download.management.list` Get list of download by csv _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get download by ID Source: https://docs.applivery.com/en/api/app-distribution/build-downloads-info/get-download/ Description: **Required Permission:** `mad.download.management.get` Get download by ID ## Get download by ID **Required Permission:** `mad.download.management.get` Get download by ID _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list of download Source: https://docs.applivery.com/en/api/app-distribution/build-downloads-info/get-downloads/ Description: **Required Permission:** `mad.download.management.list` Get list of download ## Get list of download **Required Permission:** `mad.download.management.list` Get list of download _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get build by ID Source: https://docs.applivery.com/en/api/app-distribution/build/get-organizations-organizationid-apps-applicationid-builds-buildid/ Description: **Required Permission:** `mad.build.management.get` Get build by ID ## Get build by ID **Required Permission:** `mad.build.management.get` Get build by ID _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Create build Source: https://docs.applivery.com/en/api/app-distribution/builds/apps-create/ Description: Create build ## Create build Create build _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ --- ## Delete build Source: https://docs.applivery.com/en/api/app-distribution/builds/apps-delete/ Description: **Required Permission:** `mad.build.management.remove` Delete build ## Delete build **Required Permission:** `mad.build.management.remove` Delete build _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get Download Token Source: https://docs.applivery.com/en/api/app-distribution/builds/apps-download-token/ Description: **Required Permission:** `mad.build.management.getDownloadToken` Get Download Token ## Get Download Token **Required Permission:** `mad.build.management.getDownloadToken` Get Download Token _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Add new build (for edge runners) Source: https://docs.applivery.com/en/api/app-distribution/builds/apps-edge-build-create/ Description: **Required Permission:** `mad.build.management.create` Add new build (for edge runners) ## Add new build (for edge runners) **Required Permission:** `mad.build.management.create` Add new build (for edge runners) _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Add new build file (for edge runners) Source: https://docs.applivery.com/en/api/app-distribution/builds/apps-edge-file-create/ Description: **Required Permission:** `mad.build.management.addFile` Add new build file (for edge runners) ## Add new build file (for edge runners) **Required Permission:** `mad.build.management.addFile` Add new build file (for edge runners) _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Prepare new build (for edge runners) Source: https://docs.applivery.com/en/api/app-distribution/builds/apps-edge-prepare/ Description: **Required Permission:** `mad.build.management.create` Prepare new build (for edge runners) ## Prepare new build (for edge runners) **Required Permission:** `mad.build.management.create` Prepare new build (for edge runners) _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get build emm Json by ID Source: https://docs.applivery.com/en/api/app-distribution/builds/apps-emm-json/ Description: **Required Permission:** `mad.build.management.get` Get build emm Json by ID ## Get build emm Json by ID **Required Permission:** `mad.build.management.get` Get build emm Json by ID _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Upload build file Source: https://docs.applivery.com/en/api/app-distribution/builds/apps-files-create/ Description: Upload build file ## Upload build file Upload build file _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ --- ## Delete build file Source: https://docs.applivery.com/en/api/app-distribution/builds/apps-files-delete/ Description: **Required Permission:** `mad.build.management.removeFile` Delete build file ## Delete build file **Required Permission:** `mad.build.management.removeFile` Delete build file _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update build attachment file Source: https://docs.applivery.com/en/api/app-distribution/builds/apps-files-update/ Description: **Required Permission:** `mad.build.management.updateFile` Update build attachment file ## Update build attachment file **Required Permission:** `mad.build.management.updateFile` Update build attachment file _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list of builds Source: https://docs.applivery.com/en/api/app-distribution/builds/apps-list/ Description: **Required Permission:** `mad.build.management.list` Get list of builds ## Get list of builds **Required Permission:** `mad.build.management.list` Get list of builds _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list of build packageNames Source: https://docs.applivery.com/en/api/app-distribution/builds/apps-package-names/ Description: **Required Permission:** `mad.build.management.listPackageNames` Get list of build packageNames ## Get list of build packageNames **Required Permission:** `mad.build.management.listPackageNames` Get list of build packageNames _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get build Source: https://docs.applivery.com/en/api/app-distribution/builds/apps-retrieve/ Description: Get build ## Get build Get build _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ --- ## Update build Source: https://docs.applivery.com/en/api/app-distribution/builds/apps-update/ Description: **Required Permission:** `mad.build.management.update` Update build ## Update build **Required Permission:** `mad.build.management.update` Update build _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list of build versionCodes Source: https://docs.applivery.com/en/api/app-distribution/builds/apps-version-codes/ Description: **Required Permission:** `mad.build.management.listVersionCodes` Get list of build versionCodes ## Get list of build versionCodes **Required Permission:** `mad.build.management.listVersionCodes` Get list of build versionCodes _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list of build versionNames Source: https://docs.applivery.com/en/api/app-distribution/builds/apps-version-names/ Description: **Required Permission:** `mad.build.management.listVersionNames` Get list of build versionNames ## Get list of build versionNames **Required Permission:** `mad.build.management.listVersionNames` Get list of build versionNames _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Integration Create build Source: https://docs.applivery.com/en/api/app-distribution/builds/integrations-create/ Description: Integration Create build ## Integration Create build Integration Create build _[ApiSecurity schema — see canonical URL]_ No parameters. _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ --- ## Integration Upload build file Source: https://docs.applivery.com/en/api/app-distribution/builds/integrations-files-create/ Description: Integration Upload build file ## Integration Upload build file Integration Upload build file _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ --- ## Get download manifest Source: https://docs.applivery.com/en/api/app-distribution/download-asset/get-manifest-plist/ Description: Get download manifest ## Get download manifest Get download manifest _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ --- ## Get download asset file size Source: https://docs.applivery.com/en/api/app-distribution/download-asset/retrieve-head/ Description: Get download asset file size ## Get download asset file size Get download asset file size _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ --- ## Get download Source: https://docs.applivery.com/en/api/app-distribution/download-asset/retrieve/ Description: Get download ## Get download Get download _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ --- ## Get download file size for Android EMM Source: https://docs.applivery.com/en/api/app-distribution/download/emm-retrieve-head/ Description: Get download file size for Android EMM ## Get download file size for Android EMM Get download file size for Android EMM _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ --- ## Get download for Android EMM Source: https://docs.applivery.com/en/api/app-distribution/download/emm-retrieve/ Description: Get download for Android EMM ## Get download for Android EMM Get download for Android EMM _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ --- ## Get download manifest file size Source: https://docs.applivery.com/en/api/app-distribution/download/get-manifest-plist-head/ Description: Get download manifest file size ## Get download manifest file size Get download manifest file size _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ --- ## Get download manifest Source: https://docs.applivery.com/en/api/app-distribution/download/get-manifest-plist/ Description: Get download manifest ## Get download manifest Get download manifest _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ --- ## Get download file size Source: https://docs.applivery.com/en/api/app-distribution/download/retrieve-head/ Description: Get download file size ## Get download file size Get download file size _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ --- ## Get download url Source: https://docs.applivery.com/en/api/app-distribution/download/retrieve/ Description: Get download url ## Get download url Get download url _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ --- ## Delete applicationEmployees Source: https://docs.applivery.com/en/api/app-distribution/integration-employees/delete-employee/ Description: Delete applicationEmployees ## Delete applicationEmployees Delete applicationEmployees _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get employee by ID Source: https://docs.applivery.com/en/api/app-distribution/integration-employees/get-employee/ Description: Get employee by ID ## Get employee by ID Get employee by ID _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list of applicationEmployees Source: https://docs.applivery.com/en/api/app-distribution/integration-employees/get-employees/ Description: Get list of applicationEmployees ## Get list of applicationEmployees Get list of applicationEmployees _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Add new applicationEmployees Source: https://docs.applivery.com/en/api/app-distribution/integration-employees/post-employee/ Description: Add new applicationEmployees ## Add new applicationEmployees Add new applicationEmployees _[ApiSecurity schema — see canonical URL]_ No parameters. _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update employee Source: https://docs.applivery.com/en/api/app-distribution/integration-employees/put-employee/ Description: Update employee ## Update employee Update employee _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Delete publishedApplicationD Source: https://docs.applivery.com/en/api/app-distribution/integration-pubapps/delete-distribution/ Description: Delete publishedApplication ## Delete publishedApplicationD Delete publishedApplication _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get publishedApplication by ID Source: https://docs.applivery.com/en/api/app-distribution/integration-pubapps/get-distribution/ Description: Get publishedApplication by ID ## Get publishedApplication by ID Get publishedApplication by ID _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list of publishedApplications Source: https://docs.applivery.com/en/api/app-distribution/integration-pubapps/get-distributions/ Description: Get list of publishedApplications ## Get list of publishedApplications Get list of publishedApplications _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Add new publishedApplication Source: https://docs.applivery.com/en/api/app-distribution/integration-pubapps/post-distribution/ Description: Add new publishedApplication ## Add new publishedApplication Add new publishedApplication _[ApiSecurity schema — see canonical URL]_ No parameters. _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Notify publishedApplication Source: https://docs.applivery.com/en/api/app-distribution/integration-pubapps/post-notify/ Description: Notify publishedApplication ## Notify publishedApplication Notify publishedApplication _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update publishedApplicationD Source: https://docs.applivery.com/en/api/app-distribution/integration-pubapps/put-distribution/ Description: Update publishedApplication ## Update publishedApplicationD Update publishedApplication _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Delete collaborator Source: https://docs.applivery.com/en/api/app-distribution/organization-collaborators/delete-collaborator/ Description: **Required Permission:** `people.base.organizationCollaborator.remove` Delete collaborator ## Delete collaborator **Required Permission:** `people.base.organizationCollaborator.remove` Delete collaborator _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list all collaborators csv Source: https://docs.applivery.com/en/api/app-distribution/organization-collaborators/get-all-csv/ Description: **Required Permission:** `people.base.organizationCollaborator.listAll` Get list all collaborators csv ## Get list all collaborators csv **Required Permission:** `people.base.organizationCollaborator.listAll` Get list all collaborators csv _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list all collaborators group by user Source: https://docs.applivery.com/en/api/app-distribution/organization-collaborators/get-all/ Description: **Required Permission:** `people.base.organizationCollaborator.listAll` Get list all collaborators group by user ## Get list all collaborators group by user **Required Permission:** `people.base.organizationCollaborator.listAll` Get list all collaborators group by user _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list of organization application collaborators Source: https://docs.applivery.com/en/api/app-distribution/organization-collaborators/get-apps/ Description: **Required Permission:** `people.base.organizationCollaborator.list` Get list of organization application collaborators ## Get list of organization application collaborators **Required Permission:** `people.base.organizationCollaborator.list` Get list of organization application collaborators _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get collaborator by ID Source: https://docs.applivery.com/en/api/app-distribution/organization-collaborators/get-collaborator/ Description: **Required Permission:** `people.base.organizationCollaborator.get` Get collaborator by ID ## Get collaborator by ID **Required Permission:** `people.base.organizationCollaborator.get` Get collaborator by ID _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list of collaborator Source: https://docs.applivery.com/en/api/app-distribution/organization-collaborators/get-collaborators/ Description: **Required Permission:** `people.base.organizationCollaborator.list` Get list of collaborator ## Get list of collaborator **Required Permission:** `people.base.organizationCollaborator.list` Get list of collaborator _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list of organization collaborators groups Source: https://docs.applivery.com/en/api/app-distribution/organization-collaborators/get-groups/ Description: **Required Permission:** `people.base.organizationCollaborator.listGroups` Get list of organization collaborators groups ## Get list of organization collaborators groups **Required Permission:** `people.base.organizationCollaborator.listGroups` Get list of organization collaborators groups _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Remove invitation pending Source: https://docs.applivery.com/en/api/app-distribution/organization-collaborators/invitations/delete-by-id/ Description: **Required Permission:** `people.base.organizationCollaborator.removeInvitations` Remove invitation pending ## Remove invitation pending **Required Permission:** `people.base.organizationCollaborator.removeInvitations` Remove invitation pending _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list of collaborator invitations pending Source: https://docs.applivery.com/en/api/app-distribution/organization-collaborators/invitations/get/ Description: **Required Permission:** `people.base.organizationCollaborator.invitations` Get list of collaborator invitations pending ## Get list of collaborator invitations pending **Required Permission:** `people.base.organizationCollaborator.invitations` Get list of collaborator invitations pending _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Add new collaborator Source: https://docs.applivery.com/en/api/app-distribution/organization-collaborators/post-collaborator/ Description: **Required Permission:** `people.base.organizationCollaborator.create` Add new collaborator ## Add new collaborator **Required Permission:** `people.base.organizationCollaborator.create` Add new collaborator _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update collaborator Source: https://docs.applivery.com/en/api/app-distribution/organization-collaborators/put-collaborator/ Description: **Required Permission:** `people.base.organizationCollaborator.update` Update collaborator ## Update collaborator **Required Permission:** `people.base.organizationCollaborator.update` Update collaborator _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Delete employee Source: https://docs.applivery.com/en/api/app-distribution/organization-employees/delete-employee/ Description: **Required Permission:** `people.mad.organizationEmployee.remove` Delete employee ## Delete employee **Required Permission:** `people.mad.organizationEmployee.remove` Delete employee _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list all employees csv Source: https://docs.applivery.com/en/api/app-distribution/organization-employees/get-all-csv/ Description: **Required Permission:** `people.mad.organizationEmployee.listAll` Get list all employees csv ## Get list all employees csv **Required Permission:** `people.mad.organizationEmployee.listAll` Get list all employees csv _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list all employees group by employee Source: https://docs.applivery.com/en/api/app-distribution/organization-employees/get-all/ Description: **Required Permission:** `people.mad.organizationEmployee.listAll` Get list all employees group by employee ## Get list all employees group by employee **Required Permission:** `people.mad.organizationEmployee.listAll` Get list all employees group by employee _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list of organization application employees Source: https://docs.applivery.com/en/api/app-distribution/organization-employees/get-apps/ Description: **Required Permission:** `people.mad.organizationEmployee.list` Get list of organization application employees ## Get list of organization application employees **Required Permission:** `people.mad.organizationEmployee.list` Get list of organization application employees _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get employee by ID Source: https://docs.applivery.com/en/api/app-distribution/organization-employees/get-employee/ Description: **Required Permission:** `people.mad.organizationEmployee.get` Get employee by ID ## Get employee by ID **Required Permission:** `people.mad.organizationEmployee.get` Get employee by ID _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list of employees Source: https://docs.applivery.com/en/api/app-distribution/organization-employees/get-employees/ Description: **Required Permission:** `people.mad.organizationEmployee.list` Get list of employees ## Get list of employees **Required Permission:** `people.mad.organizationEmployee.list` Get list of employees _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list of organization Employees groups Source: https://docs.applivery.com/en/api/app-distribution/organization-employees/get-groups/ Description: **Required Permission:** `people.mad.organizationEmployee.listGroups` Get list of organization Employees groups ## Get list of organization Employees groups **Required Permission:** `people.mad.organizationEmployee.listGroups` Get list of organization Employees groups _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Add new employees Source: https://docs.applivery.com/en/api/app-distribution/organization-employees/post-employee/ Description: **Required Permission:** `people.mad.organizationEmployee.create` Add new employees ## Add new employees **Required Permission:** `people.mad.organizationEmployee.create` Add new employees _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update employee Source: https://docs.applivery.com/en/api/app-distribution/organization-employees/put-employee/ Description: **Required Permission:** `people.mad.organizationEmployee.update` Update employee ## Update employee **Required Permission:** `people.mad.organizationEmployee.update` Update employee _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Delete published application from store Source: https://docs.applivery.com/en/api/app-distribution/store-published-applications/delete-pub-app/ Description: **Required Permission:** `mad.store.publishedApplication.remove` Removes a published application from the store catalog making it unavailable for distribution, revoking all user access to the publication URL, and cleaning up associated audience targeting and notification configurations with safeguards preventing deletion of the last published application using automatic latest build filter to ensure continuous application availability and prevent accidental complete application removal from distribution. ## Delete published application from store **Required Permission:** `mad.store.publishedApplication.remove` Removes a published application from the store catalog making it unavailable for distribution, revoking all user access to the publication URL, and cleaning up associated audience targeting and notification configurations with safeguards preventing deletion of the last published application using automatic latest build filter to ensure continuous application availability and prevent accidental complete application removal from distribution. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Retrieve published application details Source: https://docs.applivery.com/en/api/app-distribution/store-published-applications/get-pub-app/ Description: **Required Permission:** `mad.store.publishedApplication.get` Retrieves comprehensive details for a single published application identified by its unique identifier including application metadata, distribution URL slug, build filter configuration, security and access control settings, audience targeting rules, custom branding, terms and conditions, geographic restrictions, visibility settings, and distribution statistics for complete publication lifecycle management and configuration review. ## Retrieve published application details **Required Permission:** `mad.store.publishedApplication.get` Retrieves comprehensive details for a single published application identified by its unique identifier including application metadata, distribution URL slug, build filter configuration, security and access control settings, audience targeting rules, custom branding, terms and conditions, geographic restrictions, visibility settings, and distribution statistics for complete publication lifecycle management and configuration review. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## List published applications with filtering and pagination Source: https://docs.applivery.com/en/api/app-distribution/store-published-applications/get-pub-apps/ Description: **Required Permission:** `mad.store.publishedApplication.list` Retrieves a comprehensive paginated list of published applications within a specific store including application metadata, distribution configuration, security settings, audience targeting, and branding customization with support for filtering by application, slug, security type, visibility, filter type, build, and user audience for store catalog management and application discovery. ## List published applications with filtering and pagination **Required Permission:** `mad.store.publishedApplication.list` Retrieves a comprehensive paginated list of published applications within a specific store including application metadata, distribution configuration, security settings, audience targeting, and branding customization with support for filtering by application, slug, security type, visibility, filter type, build, and user audience for store catalog management and application discovery. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Calculate targeted members list based on audience rules Source: https://docs.applivery.com/en/api/app-distribution/store-published-applications/get-target/ Description: **Required Permission:** `mad.store.publishedApplication.target` Calculates and retrieves the complete list of targeted members who have access to this published application based on configured user audiences, group filters, email patterns, and access control rules providing administrators with visibility into actual distribution reach, audience segmentation effectiveness, and user access permissions for compliance verification and distribution planning. ## Calculate targeted members list based on audience rules **Required Permission:** `mad.store.publishedApplication.target` Calculates and retrieves the complete list of targeted members who have access to this published application based on configured user audiences, group filters, email patterns, and access control rules providing administrators with visibility into actual distribution reach, audience segmentation effectiveness, and user access permissions for compliance verification and distribution planning. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Send email notifications about new builds or updates Source: https://docs.applivery.com/en/api/app-distribution/store-published-applications/post-notify/ Description: **Required Permission:** `mad.store.publishedApplication.notify` Sends customized email notifications to selected user groups including collaborators, employees, or specific user audiences informing them about new build availability or updates in the published application with support for custom email subject, message text, language selection, and audience filtering enabling targeted communication for application deployment announcements and update notifications. ## Send email notifications about new builds or updates **Required Permission:** `mad.store.publishedApplication.notify` Sends customized email notifications to selected user groups including collaborators, employees, or specific user audiences informing them about new build availability or updates in the published application with support for custom email subject, message text, language selection, and audience filtering enabling targeted communication for application deployment announcements and update notifications. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Create new published application in store Source: https://docs.applivery.com/en/api/app-distribution/store-published-applications/post-pub-app/ Description: **Required Permission:** `mad.store.publishedApplication.create` Creates a new published application entry in the store catalog with comprehensive configuration including application selection, unique URL slug, build filter criteria, security and access control settings, audience targeting, custom branding, terms and conditions, geographic restrictions, and distribution options enabling administrators to publish applications to specific user groups with tailored presentation and access controls. ## Create new published application in store **Required Permission:** `mad.store.publishedApplication.create` Creates a new published application entry in the store catalog with comprehensive configuration including application selection, unique URL slug, build filter criteria, security and access control settings, audience targeting, custom branding, terms and conditions, geographic restrictions, and distribution options enabling administrators to publish applications to specific user groups with tailored presentation and access controls. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update published application configuration Source: https://docs.applivery.com/en/api/app-distribution/store-published-applications/put-pub-app/ Description: **Required Permission:** `mad.store.publishedApplication.update` Updates modifiable attributes of a published application including distribution URL slug, build filter configuration, security and access control settings, audience targeting rules, custom branding elements, terms and conditions, geographic restrictions with allowed and blocked countries, visibility settings, history display options, developer information visibility, attached files visibility, and expiration date enabling flexible publication configuration management and targeted distribution control. ## Update published application configuration **Required Permission:** `mad.store.publishedApplication.update` Updates modifiable attributes of a published application including distribution URL slug, build filter configuration, security and access control settings, audience targeting rules, custom branding elements, terms and conditions, geographic restrictions with allowed and blocked countries, visibility settings, history display options, developer information visibility, attached files visibility, and expiration date enabling flexible publication configuration management and targeted distribution control. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Upload image file Source: https://docs.applivery.com/en/api/app-distribution/uploads/post-logo/ Description: **Required Permission:** `base.upload.action.uploadLogo` Upload image file to serve as logo for Organizations and Applications ## Upload image file **Required Permission:** `base.upload.action.uploadLogo` Upload image file to serve as logo for Organizations and Applications _[ApiSecurity schema — see canonical URL]_ No parameters. No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Delete Apple enterprise application Source: https://docs.applivery.com/en/api/apple/applications/delete-application/ Description: **Required Permission:** `mdm.apple.application.remove` Permanently removes the Apple application configuration and discontinues its availability for managed devices. ## Delete Apple enterprise application **Required Permission:** `mdm.apple.application.remove` Permanently removes the Apple application configuration and discontinues its availability for managed devices. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Retrieve Apple application details Source: https://docs.applivery.com/en/api/apple/applications/get-application/ Description: **Required Permission:** `mdm.apple.application.get` Retrieves detailed configuration and deployment status for a specific Apple enterprise application by identifier. ## Retrieve Apple application details **Required Permission:** `mdm.apple.application.get` Retrieves detailed configuration and deployment status for a specific Apple enterprise application by identifier. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## List Apple enterprise applications Source: https://docs.applivery.com/en/api/apple/applications/get-applications/ Description: **Required Permission:** `mdm.apple.application.list` Retrieves a paginated list of Apple applications configured for enterprise deployment and management. ## List Apple enterprise applications **Required Permission:** `mdm.apple.application.list` Retrieves a paginated list of Apple applications configured for enterprise deployment and management. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Search Apple App Store applications Source: https://docs.applivery.com/en/api/apple/applications/get-search/ Description: **Required Permission:** `mdm.apple.application.search` Searches for applications in the Apple App Store and returns matching results with metadata. ## Search Apple App Store applications **Required Permission:** `mdm.apple.application.search` Searches for applications in the Apple App Store and returns matching results with metadata. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Create Apple enterprise application Source: https://docs.applivery.com/en/api/apple/applications/post-application/ Description: **Required Permission:** `mdm.apple.application.create` Creates a new Apple application configuration for enterprise deployment and availability on managed devices. ## Create Apple enterprise application **Required Permission:** `mdm.apple.application.create` Creates a new Apple application configuration for enterprise deployment and availability on managed devices. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update Apple application configuration Source: https://docs.applivery.com/en/api/apple/applications/put-application/ Description: **Required Permission:** `mdm.apple.application.update` Updates the configuration, settings, and deployment policies for an existing Apple enterprise application. ## Update Apple application configuration **Required Permission:** `mdm.apple.application.update` Updates the configuration, settings, and deployment policies for an existing Apple enterprise application. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Retrieve command details Source: https://docs.applivery.com/en/api/apple/commands/get-command/ Description: **Required Permission:** `mdm.apple.command.get` Retrieves detailed information and execution status for a specific command by its identifier. ## Retrieve command details **Required Permission:** `mdm.apple.command.get` Retrieves detailed information and execution status for a specific command by its identifier. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## List target commands Source: https://docs.applivery.com/en/api/apple/commands/get-commands/ Description: **Required Permission:** `mdm.apple.command.list` Retrieves a paginated list of commands issued to the specified device, user, or group. ## List target commands **Required Permission:** `mdm.apple.command.list` Retrieves a paginated list of commands issued to the specified device, user, or group. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## List commands grouped by type Source: https://docs.applivery.com/en/api/apple/commands/get-grouped/ Description: **Required Permission:** `mdm.apple.command.list` Retrieves commands for the specified target, grouped by command type for consolidated viewing. ## List commands grouped by type **Required Permission:** `mdm.apple.command.list` Retrieves commands for the specified target, grouped by command type for consolidated viewing. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Create bulk commands Source: https://docs.applivery.com/en/api/apple/commands/post-bulk/ Description: **Required Permission:** `mdm.apple.command.create` Creates and queues management commands for multiple targets simultaneously in a single operation. ## Create bulk commands **Required Permission:** `mdm.apple.command.create` Creates and queues management commands for multiple targets simultaneously in a single operation. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Cancel pending command Source: https://docs.applivery.com/en/api/apple/commands/post-cancel/ Description: **Required Permission:** `mdm.apple.command.cancel` Cancels a pending or retrying command, preventing it from being applied to the target. ## Cancel pending command **Required Permission:** `mdm.apple.command.cancel` Cancels a pending or retrying command, preventing it from being applied to the target. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Create target command Source: https://docs.applivery.com/en/api/apple/commands/post-command/ Description: **Required Permission:** `mdm.apple.command.create` Creates and queues a new management command for execution on the specified target. ## Create target command **Required Permission:** `mdm.apple.command.create` Creates and queues a new management command for execution on the specified target. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Delete admDepProfile Source: https://docs.applivery.com/en/api/apple/default-config/delete-default-config/ Description: **Required Permission:** `mdm.apple.defaultDeviceConfig.remove` Delete admDepProfile ## Delete admDepProfile **Required Permission:** `mdm.apple.defaultDeviceConfig.remove` Delete admDepProfile _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get defaultDeviceConfig by Id Source: https://docs.applivery.com/en/api/apple/default-config/get-default-config-by-id/ Description: **Required Permission:** `mdm.apple.defaultDeviceConfig.get` Get defaultDeviceConfig by Id ## Get defaultDeviceConfig by Id **Required Permission:** `mdm.apple.defaultDeviceConfig.get` Get defaultDeviceConfig by Id _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list of default device configs Source: https://docs.applivery.com/en/api/apple/default-config/get-default-config/ Description: **Required Permission:** `mdm.apple.defaultDeviceConfig.list` Get list of default device configs ## Get list of default device configs **Required Permission:** `mdm.apple.defaultDeviceConfig.list` Get list of default device configs _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Create default device config Source: https://docs.applivery.com/en/api/apple/default-config/post-default-config/ Description: **Required Permission:** `mdm.apple.defaultDeviceConfig.create` Create default device config ## Create default device config **Required Permission:** `mdm.apple.defaultDeviceConfig.create` Create default device config _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update admDepProfile Source: https://docs.applivery.com/en/api/apple/default-config/put-default-config/ Description: **Required Permission:** `mdm.apple.defaultDeviceConfig.update` Update admDepProfile ## Update admDepProfile **Required Permission:** `mdm.apple.defaultDeviceConfig.update` Update admDepProfile _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Remove admDepProfile from admDepDevice Source: https://docs.applivery.com/en/api/apple/dep-devices/delete-remove-profile/ Description: **Required Permission:** `mdm.apple.depDevice.removeProfile` Remove admDepProfile from admDepDevice ## Remove admDepProfile from admDepDevice **Required Permission:** `mdm.apple.depDevice.removeProfile` Remove admDepProfile from admDepDevice _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get admDepDevice by Id or Slug Source: https://docs.applivery.com/en/api/apple/dep-devices/get-device/ Description: **Required Permission:** `mdm.apple.depDevice.get` Get admDepDevice by Id or Slug ## Get admDepDevice by Id or Slug **Required Permission:** `mdm.apple.depDevice.get` Get admDepDevice by Id or Slug _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list of admDepDevice Source: https://docs.applivery.com/en/api/apple/dep-devices/get-devices/ Description: **Required Permission:** `mdm.apple.depDevice.list` Get list of admDepDevice ## Get list of admDepDevice **Required Permission:** `mdm.apple.depDevice.list` Get list of admDepDevice _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Sync all admDepDevices Source: https://docs.applivery.com/en/api/apple/dep-devices/get-sync-all/ Description: **Required Permission:** `mdm.apple.depDevice.sync` Sync all admDepDevices ## Sync all admDepDevices **Required Permission:** `mdm.apple.depDevice.sync` Sync all admDepDevices _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Sync changes admDepDevices Source: https://docs.applivery.com/en/api/apple/dep-devices/get-sync/ Description: **Required Permission:** `mdm.apple.depDevice.sync` Sync changes admDepDevices ## Sync changes admDepDevices **Required Permission:** `mdm.apple.depDevice.sync` Sync changes admDepDevices _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Assign admDepProfile to admDepDevices Source: https://docs.applivery.com/en/api/apple/dep-devices/post-assign-profile/ Description: **Required Permission:** `mdm.apple.depDevice.assignProfile` Assign admDepProfile to admDepDevices ## Assign admDepProfile to admDepDevices **Required Permission:** `mdm.apple.depDevice.assignProfile` Assign admDepProfile to admDepDevices _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Disown admDepDevices Source: https://docs.applivery.com/en/api/apple/dep-devices/post-disown/ Description: **Required Permission:** `mdm.apple.depDevice.disown` Disown admDepDevices ## Disown admDepDevices **Required Permission:** `mdm.apple.depDevice.disown` Disown admDepDevices _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Lock admDepDevices Source: https://docs.applivery.com/en/api/apple/dep-devices/post-lock/ Description: **Required Permission:** `mdm.apple.depDevice.lock` Lock admDepDevices ## Lock admDepDevices **Required Permission:** `mdm.apple.depDevice.lock` Lock admDepDevices _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update admDepDevice Source: https://docs.applivery.com/en/api/apple/dep-devices/put-device/ Description: **Required Permission:** `mdm.apple.depDevice.update` Update admDepDevice ## Update admDepDevice **Required Permission:** `mdm.apple.depDevice.update` Update admDepDevice _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Sync transaction info Source: https://docs.applivery.com/en/api/apple/dep-devices/sync-transaction/get-by-id/ Description: **Required Permission:** `mdm.apple.depDevice.sync` Sync transaction info ## Sync transaction info **Required Permission:** `mdm.apple.depDevice.sync` Sync transaction info _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Sync transaction list Source: https://docs.applivery.com/en/api/apple/dep-devices/sync-transaction/get/ Description: **Required Permission:** `mdm.apple.depDevice.sync` Sync transaction list ## Sync transaction list **Required Permission:** `mdm.apple.depDevice.sync` Sync transaction list _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Delete admDepProfile Source: https://docs.applivery.com/en/api/apple/dep-profiles/delete-profile/ Description: **Required Permission:** `mdm.apple.depProfile.remove` Delete admDepProfile ## Delete admDepProfile **Required Permission:** `mdm.apple.depProfile.remove` Delete admDepProfile _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get admDepProfile by Id Source: https://docs.applivery.com/en/api/apple/dep-profiles/get-profile/ Description: **Required Permission:** `mdm.apple.depProfile.get` Get admDepProfile by Id ## Get admDepProfile by Id **Required Permission:** `mdm.apple.depProfile.get` Get admDepProfile by Id _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list of admDepProfile Source: https://docs.applivery.com/en/api/apple/dep-profiles/get-profiles/ Description: **Required Permission:** `mdm.apple.depProfile.list` Get list of admDepProfile ## Get list of admDepProfile **Required Permission:** `mdm.apple.depProfile.list` Get list of admDepProfile _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Create adm dep profile Source: https://docs.applivery.com/en/api/apple/dep-profiles/post-profile/ Description: **Required Permission:** `mdm.apple.depProfile.create` Create adm dep profile ## Create adm dep profile **Required Permission:** `mdm.apple.depProfile.create` Create adm dep profile _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Delete admDevice Source: https://docs.applivery.com/en/api/apple/devices/delete-device/ Description: **Required Permission:** `mdm.apple.device.remove` Delete admDevice ## Delete admDevice **Required Permission:** `mdm.apple.device.remove` Delete admDevice _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get admDevice activationLockBypassCode by Id Source: https://docs.applivery.com/en/api/apple/devices/get-activation-lock-bypass-code/ Description: **Required Permission:** `mdm.apple.device.getActivationLockBypassCode` Get admDevice activationLockBypassCode by Id ## Get admDevice activationLockBypassCode by Id **Required Permission:** `mdm.apple.device.getActivationLockBypassCode` Get admDevice activationLockBypassCode by Id _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get admDevice agent cleanup by Id Source: https://docs.applivery.com/en/api/apple/devices/get-agent-cleanup/ Description: **Required Permission:** `mdm.apple.device.action` Get admDevice agent cleanup by Id ## Get admDevice agent cleanup by Id **Required Permission:** `mdm.apple.device.action` Get admDevice agent cleanup by Id _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get admDevice agent config assets setup by Id Source: https://docs.applivery.com/en/api/apple/devices/get-agent-config-assets-setup/ Description: **Required Permission:** `mdm.apple.device.get` Get admDevice agent config assets setup by Id ## Get admDevice agent config assets setup by Id **Required Permission:** `mdm.apple.device.get` Get admDevice agent config assets setup by Id _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get admDevice agent config assets by Id Source: https://docs.applivery.com/en/api/apple/devices/get-agent-config-assets/ Description: **Required Permission:** `mdm.apple.device.get` Get admDevice agent config assets by Id ## Get admDevice agent config assets by Id **Required Permission:** `mdm.apple.device.get` Get admDevice agent config assets by Id _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get admDevice agent config by Id Source: https://docs.applivery.com/en/api/apple/devices/get-agent-config/ Description: **Required Permission:** `mdm.apple.device.get` Get admDevice agent config by Id ## Get admDevice agent config by Id **Required Permission:** `mdm.apple.device.get` Get admDevice agent config by Id _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get admDevice agent recovery by Id Source: https://docs.applivery.com/en/api/apple/devices/get-agent-recovery-managed-configuration/ Description: **Required Permission:** `mdm.apple.device.action` Get admDevice agent recovery by Id ## Get admDevice agent recovery by Id **Required Permission:** `mdm.apple.device.action` Get admDevice agent recovery by Id _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get admDevice agent recovery by Id Source: https://docs.applivery.com/en/api/apple/devices/get-agent-recovery/ Description: **Required Permission:** `mdm.apple.device.action` Get admDevice agent recovery by Id ## Get admDevice agent recovery by Id **Required Permission:** `mdm.apple.device.action` Get admDevice agent recovery by Id _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get admDevice agent tokens by Id Source: https://docs.applivery.com/en/api/apple/devices/get-agent-tokens/ Description: **Required Permission:** `mdm.apple.device.get` Get admDevice agent tokens by Id ## Get admDevice agent tokens by Id **Required Permission:** `mdm.apple.device.get` Get admDevice agent tokens by Id _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get admDevice applications by Id Source: https://docs.applivery.com/en/api/apple/devices/get-applications/ Description: **Required Permission:** `mdm.apple.device.get` Get admDevice applications by Id ## Get admDevice applications by Id **Required Permission:** `mdm.apple.device.get` Get admDevice applications by Id _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Check Notify admDevice Source: https://docs.applivery.com/en/api/apple/devices/get-check-notify/ Description: **Required Permission:** `mdm.apple.device.notify` Check Notify admDevice ## Check Notify admDevice **Required Permission:** `mdm.apple.device.notify` Check Notify admDevice _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get admDevice by Id Source: https://docs.applivery.com/en/api/apple/devices/get-device/ Description: **Required Permission:** `mdm.apple.device.get` Get admDevice by Id ## Get admDevice by Id **Required Permission:** `mdm.apple.device.get` Get admDevice by Id _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list of admDevice Source: https://docs.applivery.com/en/api/apple/devices/get-devices/ Description: **Required Permission:** `mdm.apple.device.list` Get list of admDevice ## Get list of admDevice **Required Permission:** `mdm.apple.device.list` Get list of admDevice _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get admDevice fileVaultRecoveryKey by Id Source: https://docs.applivery.com/en/api/apple/devices/get-file-vault-recovery-key/ Description: **Required Permission:** `mdm.apple.device.getFileVaultRecoveryKey` Get admDevice fileVaultRecoveryKey by Id ## Get admDevice fileVaultRecoveryKey by Id **Required Permission:** `mdm.apple.device.getFileVaultRecoveryKey` Get admDevice fileVaultRecoveryKey by Id _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Notify admDevice Source: https://docs.applivery.com/en/api/apple/devices/get-notify/ Description: **Required Permission:** `mdm.apple.device.notify` Notify admDevice ## Notify admDevice **Required Permission:** `mdm.apple.device.notify` Notify admDevice _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Refresh admDevice info Source: https://docs.applivery.com/en/api/apple/devices/get-refresh/ Description: **Required Permission:** `mdm.apple.device.refresh` Refresh admDevice info ## Refresh admDevice info **Required Permission:** `mdm.apple.device.refresh` Refresh admDevice info _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Reinstall admDevice Mdm profile Source: https://docs.applivery.com/en/api/apple/devices/get-reinstall/ Description: **Required Permission:** `mdm.apple.device.reinstall` Reinstall admDevice Mdm profile ## Reinstall admDevice Mdm profile **Required Permission:** `mdm.apple.device.reinstall` Reinstall admDevice Mdm profile _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get admDevice scheduler scripts by Id Source: https://docs.applivery.com/en/api/apple/devices/get-scheduler-scripts/ Description: **Required Permission:** `mdm.apple.device.get` Get admDevice scheduler scripts by Id ## Get admDevice scheduler scripts by Id **Required Permission:** `mdm.apple.device.get` Get admDevice scheduler scripts by Id _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get admDevice setup assistant recovery by Id Source: https://docs.applivery.com/en/api/apple/devices/get-setup-assistant-recovery-managed-configuration/ Description: **Required Permission:** `mdm.apple.device.action` Get admDevice setup assistant recovery by Id ## Get admDevice setup assistant recovery by Id **Required Permission:** `mdm.apple.device.action` Get admDevice setup assistant recovery by Id _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Notify admDevice Source: https://docs.applivery.com/en/api/apple/devices/get-sync/ Description: **Required Permission:** `mdm.apple.device.sync` Notify admDevice ## Notify admDevice **Required Permission:** `mdm.apple.device.sync` Notify admDevice _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Unlock admDevice Source: https://docs.applivery.com/en/api/apple/devices/get-unlock/ Description: **Required Permission:** `mdm.apple.device.unlock` Unlock admDevice ## Unlock admDevice **Required Permission:** `mdm.apple.device.unlock` Unlock admDevice _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list of deviceInfoHistory by deviceId Source: https://docs.applivery.com/en/api/apple/devices/info-history/get-device-info-history/ Description: Get list of deviceInfoHistory by deviceId ## Get list of deviceInfoHistory by deviceId Get list of deviceInfoHistory by deviceId _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Notify admDevice Source: https://docs.applivery.com/en/api/apple/devices/notifications/post-notification/ Description: **Required Permission:** `mdm.apple.deviceNotification.action` Notify admDevice ## Notify admDevice **Required Permission:** `mdm.apple.deviceNotification.action` Notify admDevice _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Send admDevice action Source: https://docs.applivery.com/en/api/apple/devices/post-action/ Description: **Required Permission:** `mdm.apple.device.action` Send admDevice action ## Send admDevice action **Required Permission:** `mdm.apple.device.action` Send admDevice action _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update admDevice Source: https://docs.applivery.com/en/api/apple/devices/put-device/ Description: **Required Permission:** `mdm.apple.device.update` Update admDevice ## Update admDevice **Required Permission:** `mdm.apple.device.update` Update admDevice _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Move admDevice to segment Source: https://docs.applivery.com/en/api/apple/devices/put-move/ Description: **Required Permission:** `mdm.apple.device.move` Move admDevice to segment ## Move admDevice to segment **Required Permission:** `mdm.apple.device.move` Move admDevice to segment _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get mdmScriptLog by Id Source: https://docs.applivery.com/en/api/apple/devices/script-logs/get-script-log/ Description: **Required Permission:** `mdm.apple.deviceScriptLog.get` Get mdmScriptLog by Id ## Get mdmScriptLog by Id **Required Permission:** `mdm.apple.deviceScriptLog.get` Get mdmScriptLog by Id _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list of admDeviceScriptLog Source: https://docs.applivery.com/en/api/apple/devices/script-logs/get-script-logs/ Description: **Required Permission:** `mdm.apple.deviceScriptLog.list` Get list of admDeviceScriptLog ## Get list of admDeviceScriptLog **Required Permission:** `mdm.apple.deviceScriptLog.list` Get list of admDeviceScriptLog _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list of admDeviceScriptLog Source: https://docs.applivery.com/en/api/apple/devices/script-logs/get-summary/ Description: **Required Permission:** `mdm.apple.deviceScriptLog.list` Get list of admDeviceScriptLog ## Get list of admDeviceScriptLog **Required Permission:** `mdm.apple.deviceScriptLog.list` Get list of admDeviceScriptLog _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Invalidate script (once) Source: https://docs.applivery.com/en/api/apple/devices/script-logs/post-invalidate-once/ Description: **Required Permission:** `mdm.apple.deviceScriptLog.invalidate` Invalidate script (once) ## Invalidate script (once) **Required Permission:** `mdm.apple.deviceScriptLog.invalidate` Invalidate script (once) _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Invalidate script Source: https://docs.applivery.com/en/api/apple/devices/script-logs/post-invalidate/ Description: **Required Permission:** `mdm.apple.deviceScriptLog.invalidate` Invalidate script ## Invalidate script **Required Permission:** `mdm.apple.deviceScriptLog.invalidate` Invalidate script _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get device system info Source: https://docs.applivery.com/en/api/apple/devices/system-info/get-device-system-info/ Description: Get device system info ## Get device system info Get device system info _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get admDeviceUser applications by Id Source: https://docs.applivery.com/en/api/apple/devices/users/get-applications/ Description: **Required Permission:** `mdm.apple.deviceUser.get` Get admDeviceUser applications by Id ## Get admDeviceUser applications by Id **Required Permission:** `mdm.apple.deviceUser.get` Get admDeviceUser applications by Id _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Notify admDeviceUser Source: https://docs.applivery.com/en/api/apple/devices/users/get-notify/ Description: **Required Permission:** `mdm.apple.deviceUser.notify` Notify admDeviceUser ## Notify admDeviceUser **Required Permission:** `mdm.apple.deviceUser.notify` Notify admDeviceUser _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Refresh admDeviceUser info Source: https://docs.applivery.com/en/api/apple/devices/users/get-refresh/ Description: **Required Permission:** `mdm.apple.deviceUser.refresh` Refresh admDeviceUser info ## Refresh admDeviceUser info **Required Permission:** `mdm.apple.deviceUser.refresh` Refresh admDeviceUser info _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Notify admDeviceUser Source: https://docs.applivery.com/en/api/apple/devices/users/get-sync/ Description: **Required Permission:** `mdm.apple.deviceUser.sync` Notify admDeviceUser ## Notify admDeviceUser **Required Permission:** `mdm.apple.deviceUser.sync` Notify admDeviceUser _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get admDeviceUser by Id Source: https://docs.applivery.com/en/api/apple/devices/users/get-user/ Description: **Required Permission:** `mdm.apple.deviceUser.get` Get admDeviceUser by Id ## Get admDeviceUser by Id **Required Permission:** `mdm.apple.deviceUser.get` Get admDeviceUser by Id _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list of admDeviceUser Source: https://docs.applivery.com/en/api/apple/devices/users/get-users/ Description: **Required Permission:** `mdm.apple.deviceUser.list` Get list of admDeviceUser ## Get list of admDeviceUser **Required Permission:** `mdm.apple.deviceUser.list` Get list of admDeviceUser _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update admDeviceUser Source: https://docs.applivery.com/en/api/apple/devices/users/put-user/ Description: **Required Permission:** `mdm.apple.deviceUser.update` Update admDeviceUser ## Update admDeviceUser **Required Permission:** `mdm.apple.deviceUser.update` Update admDeviceUser _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Delete enrollment template Source: https://docs.applivery.com/en/api/apple/enrollment-templates/delete-enrollment-template/ Description: **Required Permission:** `mdm.apple.enrollmentTemplate.remove` Permanently removes the enrollment template and disassociates it from any assigned users or groups. ## Delete enrollment template **Required Permission:** `mdm.apple.enrollmentTemplate.remove` Permanently removes the enrollment template and disassociates it from any assigned users or groups. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Check template assignations Source: https://docs.applivery.com/en/api/apple/enrollment-templates/get-assignations/ Description: **Required Permission:** `mdm.apple.enrollmentTemplate.get` Retrieves assignation information showing which users, groups, or devices use this enrollment template. ## Check template assignations **Required Permission:** `mdm.apple.enrollmentTemplate.get` Retrieves assignation information showing which users, groups, or devices use this enrollment template. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Retrieve enrollment template details Source: https://docs.applivery.com/en/api/apple/enrollment-templates/get-enrollment-template/ Description: **Required Permission:** `mdm.apple.enrollmentTemplate.get` Retrieves detailed configuration, policies, and profile information for a specific enrollment template. ## Retrieve enrollment template details **Required Permission:** `mdm.apple.enrollmentTemplate.get` Retrieves detailed configuration, policies, and profile information for a specific enrollment template. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## List Apple enrollment templates Source: https://docs.applivery.com/en/api/apple/enrollment-templates/get-enrollment-templates/ Description: **Required Permission:** `mdm.apple.enrollmentTemplate.list` Retrieves a paginated list of Apple device enrollment templates configured for the organization. ## List Apple enrollment templates **Required Permission:** `mdm.apple.enrollmentTemplate.list` Retrieves a paginated list of Apple device enrollment templates configured for the organization. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Create enrollment template Source: https://docs.applivery.com/en/api/apple/enrollment-templates/post-enrollment-template/ Description: **Required Permission:** `mdm.apple.enrollmentTemplate.create` Creates a new enrollment template with specified policies, profiles, and configuration settings. ## Create enrollment template **Required Permission:** `mdm.apple.enrollmentTemplate.create` Creates a new enrollment template with specified policies, profiles, and configuration settings. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update enrollment template Source: https://docs.applivery.com/en/api/apple/enrollment-templates/put-enrollment-template/ Description: **Required Permission:** `mdm.apple.enrollmentTemplate.update` Updates the configuration, policies, and profile settings for an existing enrollment template. ## Update enrollment template **Required Permission:** `mdm.apple.enrollmentTemplate.update` Updates the configuration, policies, and profile settings for an existing enrollment template. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Delete enrollment token Source: https://docs.applivery.com/en/api/apple/enrollment-tokens/delete-enrollment-token/ Description: **Required Permission:** `mdm.apple.enrollmentToken.remove` Permanently removes the enrollment token and invalidates its use for device enrollment. ## Delete enrollment token **Required Permission:** `mdm.apple.enrollmentToken.remove` Permanently removes the enrollment token and invalidates its use for device enrollment. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Retrieve enrollment token details Source: https://docs.applivery.com/en/api/apple/enrollment-tokens/get-enrollment-token/ Description: **Required Permission:** `mdm.apple.enrollmentToken.get` Retrieves detailed configuration and status information for a specific enrollment token by identifier. ## Retrieve enrollment token details **Required Permission:** `mdm.apple.enrollmentToken.get` Retrieves detailed configuration and status information for a specific enrollment token by identifier. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## List Apple enrollment tokens Source: https://docs.applivery.com/en/api/apple/enrollment-tokens/get-enrollment-tokens/ Description: **Required Permission:** `mdm.apple.enrollmentToken.list` Retrieves a paginated list of Apple device enrollment tokens configured for the organization. ## List Apple enrollment tokens **Required Permission:** `mdm.apple.enrollmentToken.list` Retrieves a paginated list of Apple device enrollment tokens configured for the organization. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Create bulk enrollment tokens Source: https://docs.applivery.com/en/api/apple/enrollment-tokens/post-bulk/ Description: **Required Permission:** `mdm.apple.enrollmentToken.create` Creates multiple enrollment tokens simultaneously for streamlined distribution to end users or groups. ## Create bulk enrollment tokens **Required Permission:** `mdm.apple.enrollmentToken.create` Creates multiple enrollment tokens simultaneously for streamlined distribution to end users or groups. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Create enrollment token Source: https://docs.applivery.com/en/api/apple/enrollment-tokens/post-enrollment-token/ Description: **Required Permission:** `mdm.apple.enrollmentToken.create` Creates a new enrollment token with specified configuration for device registration and management. ## Create enrollment token **Required Permission:** `mdm.apple.enrollmentToken.create` Creates a new enrollment token with specified configuration for device registration and management. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update enrollment token Source: https://docs.applivery.com/en/api/apple/enrollment-tokens/put-enrollment-token/ Description: **Required Permission:** `mdm.apple.enrollmentToken.update` Updates the configuration and settings for an existing enrollment token. ## Update enrollment token **Required Permission:** `mdm.apple.enrollmentToken.update` Updates the configuration and settings for an existing enrollment token. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get adm enterprise ApplePush CSR Source: https://docs.applivery.com/en/api/apple/enterprise/get-applepush.csr/ Description: Get adm enterprise ApplePush CSR ## Get adm enterprise ApplePush CSR Get adm enterprise ApplePush CSR _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get adm enterprise DEP certificate Source: https://docs.applivery.com/en/api/apple/enterprise/get-dep-public.cer/ Description: Get adm enterprise DEP certificate ## Get adm enterprise DEP certificate Get adm enterprise DEP certificate _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get adm enterprise info Source: https://docs.applivery.com/en/api/apple/enterprise/get-enterprise/ Description: **Required Permission:** `mdm.apple.enterprise.get` Get adm enterprise info ## Get adm enterprise info **Required Permission:** `mdm.apple.enterprise.get` Get adm enterprise info _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Reinstall admEnterprise devices Mdm Profile Source: https://docs.applivery.com/en/api/apple/enterprise/get-reinstall-devices/ Description: **Required Permission:** `mdm.apple.enterprise.reinstallDevices` Reinstall admEnterprise devices Mdm Profile ## Reinstall admEnterprise devices Mdm Profile **Required Permission:** `mdm.apple.enterprise.reinstallDevices` Reinstall admEnterprise devices Mdm Profile _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Search store applications by entity Source: https://docs.applivery.com/en/api/apple/enterprise/get-search/ Description: **Required Permission:** `mdm.apple.enterprise.search` Search store applications by entity ## Search store applications by entity **Required Permission:** `mdm.apple.enterprise.search` Search store applications by entity _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Create adm enterprise Source: https://docs.applivery.com/en/api/apple/enterprise/post-enterprise/ Description: **Required Permission:** `mdm.apple.enterprise.create` Create adm enterprise ## Create adm enterprise **Required Permission:** `mdm.apple.enterprise.create` Create adm enterprise _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Search store applications by entity Source: https://docs.applivery.com/en/api/apple/enterprise/post-search-bundle-ids/ Description: **Required Permission:** `mdm.apple.enterprise.search` Search store applications by entity ## Search store applications by entity **Required Permission:** `mdm.apple.enterprise.search` Search store applications by entity _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update adm enterprise send dep token Source: https://docs.applivery.com/en/api/apple/enterprise/put-dep/ Description: **Required Permission:** `mdm.apple.enterprise.update` Update adm enterprise send dep token ## Update adm enterprise send dep token **Required Permission:** `mdm.apple.enterprise.update` Update adm enterprise send dep token _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update adm enterprise info Source: https://docs.applivery.com/en/api/apple/enterprise/put-enterprise/ Description: **Required Permission:** `mdm.apple.enterprise.update` Update adm enterprise info ## Update adm enterprise info **Required Permission:** `mdm.apple.enterprise.update` Update adm enterprise info _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Check admVppEvent Source: https://docs.applivery.com/en/api/apple/event-check/get-check/ Description: **Required Permission:** `mdm.apple.vppEvent.check` Check admVppEvent ## Check admVppEvent **Required Permission:** `mdm.apple.vppEvent.check` Check admVppEvent _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Assignments admVppAsset Source: https://docs.applivery.com/en/api/apple/locations/assets/get-assignments/ Description: **Required Permission:** `mdm.apple.vppAsset.assignments` Assignments admVppAsset ## Assignments admVppAsset **Required Permission:** `mdm.apple.vppAsset.assignments` Assignments admVppAsset _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list of admVppAsset Source: https://docs.applivery.com/en/api/apple/locations/assets/get/ Description: **Required Permission:** `mdm.apple.vppAsset.list` Get list of admVppAsset ## Get list of admVppAsset **Required Permission:** `mdm.apple.vppAsset.list` Get list of admVppAsset _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Associate admVppAsset Source: https://docs.applivery.com/en/api/apple/locations/assets/post-associate/ Description: **Required Permission:** `mdm.apple.vppAsset.associate` Associate admVppAsset ## Associate admVppAsset **Required Permission:** `mdm.apple.vppAsset.associate` Associate admVppAsset _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Disassociate admVppAsset Source: https://docs.applivery.com/en/api/apple/locations/assets/post-disassociate/ Description: **Required Permission:** `mdm.apple.vppAsset.disassociate` Disassociate admVppAsset ## Disassociate admVppAsset **Required Permission:** `mdm.apple.vppAsset.disassociate` Disassociate admVppAsset _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Revoke admVppAsset Source: https://docs.applivery.com/en/api/apple/locations/assets/post-revoke/ Description: **Required Permission:** `mdm.apple.vppAsset.revoke` Revoke admVppAsset ## Revoke admVppAsset **Required Permission:** `mdm.apple.vppAsset.revoke` Revoke admVppAsset _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Delete admVppLocation Source: https://docs.applivery.com/en/api/apple/locations/delete-location/ Description: **Required Permission:** `mdm.apple.vppLocation.remove` Delete admVppLocation ## Delete admVppLocation **Required Permission:** `mdm.apple.vppLocation.remove` Delete admVppLocation _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get admVppLocation by Id or Slug Source: https://docs.applivery.com/en/api/apple/locations/get-location/ Description: **Required Permission:** `mdm.apple.vppLocation.get` Get admVppLocation by Id or Slug ## Get admVppLocation by Id or Slug **Required Permission:** `mdm.apple.vppLocation.get` Get admVppLocation by Id or Slug _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list of admVppLocation Source: https://docs.applivery.com/en/api/apple/locations/get-locations/ Description: **Required Permission:** `mdm.apple.vppLocation.list` Get list of admVppLocation ## Get list of admVppLocation **Required Permission:** `mdm.apple.vppLocation.list` Get list of admVppLocation _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Create or update admVppLocation Source: https://docs.applivery.com/en/api/apple/locations/post-location/ Description: **Required Permission:** `mdm.apple.vppLocation.create` Create or update admVppLocation based on token uId obtained from Apple ## Create or update admVppLocation **Required Permission:** `mdm.apple.vppLocation.create` Create or update admVppLocation based on token uId obtained from Apple _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Retire admVppUser Source: https://docs.applivery.com/en/api/apple/locations/users/delete-by-id/ Description: **Required Permission:** `mdm.apple.vppUser.retire` Retire admVppUser ## Retire admVppUser **Required Permission:** `mdm.apple.vppUser.retire` Retire admVppUser _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list all of admVppUser Source: https://docs.applivery.com/en/api/apple/locations/users/get-all/ Description: **Required Permission:** `mdm.apple.vppUser.list` Get list all of admVppUser ## Get list all of admVppUser **Required Permission:** `mdm.apple.vppUser.list` Get list all of admVppUser _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list of admVppUser Source: https://docs.applivery.com/en/api/apple/locations/users/get/ Description: **Required Permission:** `mdm.apple.vppUser.list` Get list of admVppUser ## Get list of admVppUser **Required Permission:** `mdm.apple.vppUser.list` Get list of admVppUser _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Create admVppUser Source: https://docs.applivery.com/en/api/apple/locations/users/post/ Description: **Required Permission:** `mdm.apple.vppUser.create` Create admVppUser ## Create admVppUser **Required Permission:** `mdm.apple.vppUser.create` Create admVppUser _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Delete device policy Source: https://docs.applivery.com/en/api/apple/policies/delete-policy/ Description: **Required Permission:** `mdm.apple.policy.remove` Permanently removes the policy and disassociates it from any assigned users, groups, or devices. ## Delete device policy **Required Permission:** `mdm.apple.policy.remove` Permanently removes the policy and disassociates it from any assigned users, groups, or devices. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Retrieve agent configuration Source: https://docs.applivery.com/en/api/apple/policies/get-agent-config/ Description: **Required Permission:** `mdm.apple.policy.get` Retrieves the MDM agent configuration settings derived from the policy for device deployment. ## Retrieve agent configuration **Required Permission:** `mdm.apple.policy.get` Retrieves the MDM agent configuration settings derived from the policy for device deployment. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Check policy assignations Source: https://docs.applivery.com/en/api/apple/policies/get-assignations/ Description: **Required Permission:** `mdm.apple.policy.get` Retrieves assignation information showing which users, groups, or devices use this policy. ## Check policy assignations **Required Permission:** `mdm.apple.policy.get` Retrieves assignation information showing which users, groups, or devices use this policy. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## List Apple device policies Source: https://docs.applivery.com/en/api/apple/policies/get-policies/ Description: **Required Permission:** `mdm.apple.policy.list` Retrieves a paginated list of Apple device policies configured for the organization. ## List Apple device policies **Required Permission:** `mdm.apple.policy.list` Retrieves a paginated list of Apple device policies configured for the organization. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Retrieve policy details Source: https://docs.applivery.com/en/api/apple/policies/get-policy/ Description: **Required Permission:** `mdm.apple.policy.get` Retrieves detailed configuration, restrictions, and assignation information for a specific policy. ## Retrieve policy details **Required Permission:** `mdm.apple.policy.get` Retrieves detailed configuration, restrictions, and assignation information for a specific policy. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Validate policy composition Source: https://docs.applivery.com/en/api/apple/policies/post-composition/ Description: **Required Permission:** `mdm.apple.policy.composition` Validates policy configuration structure and checks for conflicts or incompatible settings. ## Validate policy composition **Required Permission:** `mdm.apple.policy.composition` Validates policy configuration structure and checks for conflicts or incompatible settings. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Create device policy Source: https://docs.applivery.com/en/api/apple/policies/post-policy/ Description: **Required Permission:** `mdm.apple.policy.create` Creates a new policy with specified configurations, restrictions, and security settings. ## Create device policy **Required Permission:** `mdm.apple.policy.create` Creates a new policy with specified configurations, restrictions, and security settings. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update device policy Source: https://docs.applivery.com/en/api/apple/policies/put-policy/ Description: **Required Permission:** `mdm.apple.policy.update` Updates the configuration, restrictions, and security settings for an existing policy. ## Update device policy **Required Permission:** `mdm.apple.policy.update` Updates the configuration, restrictions, and security settings for an existing policy. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Retrieve policy template details Source: https://docs.applivery.com/en/api/apple/policies/templates/get-by-id/ Description: **Required Permission:** `mdm.apple.policy.templates` Retrieves detailed configuration and settings for a specific policy template by identifier. ## Retrieve policy template details **Required Permission:** `mdm.apple.policy.templates` Retrieves detailed configuration and settings for a specific policy template by identifier. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## List policy templates Source: https://docs.applivery.com/en/api/apple/policies/templates/get/ Description: **Required Permission:** `mdm.apple.policy.templates` Retrieves available policy templates with predefined configurations for common device management scenarios. ## List policy templates **Required Permission:** `mdm.apple.policy.templates` Retrieves available policy templates with predefined configurations for common device management scenarios. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Delete admProfile Source: https://docs.applivery.com/en/api/apple/profiles/delete-profile/ Description: **Required Permission:** `mdm.apple.profile.remove` Delete admProfile ## Delete admProfile **Required Permission:** `mdm.apple.profile.remove` Delete admProfile _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get admProfile by Id or Slug Source: https://docs.applivery.com/en/api/apple/profiles/get-profile/ Description: **Required Permission:** `mdm.apple.profile.get` Get admProfile by Id or Slug ## Get admProfile by Id or Slug **Required Permission:** `mdm.apple.profile.get` Get admProfile by Id or Slug _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list of admProfile Source: https://docs.applivery.com/en/api/apple/profiles/get-profiles/ Description: **Required Permission:** `mdm.apple.profile.list` Get list of admProfile ## Get list of admProfile **Required Permission:** `mdm.apple.profile.list` Get list of admProfile _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Create admProfile Source: https://docs.applivery.com/en/api/apple/profiles/post-profile/ Description: **Required Permission:** `mdm.apple.profile.create` Create admProfile ## Create admProfile **Required Permission:** `mdm.apple.profile.create` Create admProfile _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update admProfile Source: https://docs.applivery.com/en/api/apple/profiles/put-profile/ Description: **Required Permission:** `mdm.apple.profile.update` Update admProfile ## Update admProfile **Required Permission:** `mdm.apple.profile.update` Update admProfile _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get admRouter by Id Source: https://docs.applivery.com/en/api/apple/router/get-router-by-id/ Description: **Required Permission:** `mdm.apple.router.get` Get admRouter by Id ## Get admRouter by Id **Required Permission:** `mdm.apple.router.get` Get admRouter by Id _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list of admRouter Source: https://docs.applivery.com/en/api/apple/router/get-router/ Description: **Required Permission:** `mdm.apple.router.list` Get list of admRouter ## Get list of admRouter **Required Permission:** `mdm.apple.router.list` Get list of admRouter _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list of admSyncHistory Source: https://docs.applivery.com/en/api/apple/sync-history/get-sync-history/ Description: **Required Permission:** `mdm.apple.syncHistory.list` Get list of admSyncHistory ## Get list of admSyncHistory **Required Permission:** `mdm.apple.syncHistory.list` Get list of admSyncHistory _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Assist Source: https://docs.applivery.com/en/api/platform/assistant/post-assistant-by-id/ Description: **Required Permission:** `base.organization.assistant.action` Assist ## Assist **Required Permission:** `base.organization.assistant.action` Assist _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get audit by Id Source: https://docs.applivery.com/en/api/platform/audit/get-audit-by-id/ Description: **Required Permission:** `base.organization.audit.get` Get audit by Id ## Get audit by Id **Required Permission:** `base.organization.audit.get` Get audit by Id _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list of audit Source: https://docs.applivery.com/en/api/platform/audit/get-audit/ Description: **Required Permission:** `base.organization.audit.list` Get list of audit ## Get list of audit **Required Permission:** `base.organization.audit.list` Get list of audit _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Prepare new bulkTask (for edge runners) Source: https://docs.applivery.com/en/api/platform/bulk-tasks/edge/get-prepare/ Description: **Required Permission:** `base.bulk.management.get` Prepare new bulkTask (for edge runners) ## Prepare new bulkTask (for edge runners) **Required Permission:** `base.bulk.management.get` Prepare new bulkTask (for edge runners) _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Add new bulkTask (for edge runners) Source: https://docs.applivery.com/en/api/platform/bulk-tasks/edge/post-create/ Description: **Required Permission:** `base.bulk.management.create` Add new bulkTask (for edge runners) ## Add new bulkTask (for edge runners) **Required Permission:** `base.bulk.management.create` Add new bulkTask (for edge runners) _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get bulkTask by ID Source: https://docs.applivery.com/en/api/platform/bulk-tasks/get-bulk-task/ Description: **Required Permission:** `base.bulk.management.get` Get bulkTask by ID ## Get bulkTask by ID **Required Permission:** `base.bulk.management.get` Get bulkTask by ID _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list of bulkTask Source: https://docs.applivery.com/en/api/platform/bulk-tasks/get-bulk-tasks/ Description: **Required Permission:** `base.bulk.management.list` Get list of bulkTask ## Get list of bulkTask **Required Permission:** `base.bulk.management.list` Get list of bulkTask _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Check bulkTask Source: https://docs.applivery.com/en/api/platform/bulk-tasks/post-check/ Description: **Required Permission:** `base.bulk.management.check` Check bulkTask ## Check bulkTask **Required Permission:** `base.bulk.management.check` Check bulkTask _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Upload file and call bulk tasks create Source: https://docs.applivery.com/en/api/platform/bulktaskingestor/post-action/ Description: Upload file and call bulk tasks create ## Upload file and call bulk tasks create Upload file and call bulk tasks create _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ --- ## Delete certificateProvider Source: https://docs.applivery.com/en/api/platform/certificate-provider/delete-certificate-provider/ Description: **Required Permission:** `base.organization.certificateProvider.remove` Delete certificateProvider ## Delete certificateProvider **Required Permission:** `base.organization.certificateProvider.remove` Delete certificateProvider _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Check certificateProvider assignation Source: https://docs.applivery.com/en/api/platform/certificate-provider/get-assignations/ Description: **Required Permission:** `base.organization.certificateProvider.assignations` Check certificateProvider assignation ## Check certificateProvider assignation **Required Permission:** `base.organization.certificateProvider.assignations` Check certificateProvider assignation _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get certificateProvider by Id or Slug Source: https://docs.applivery.com/en/api/platform/certificate-provider/get-certificate-provider/ Description: **Required Permission:** `base.organization.certificateProvider.get` Get certificateProvider by Id or Slug ## Get certificateProvider by Id or Slug **Required Permission:** `base.organization.certificateProvider.get` Get certificateProvider by Id or Slug _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list of certificateProvider Source: https://docs.applivery.com/en/api/platform/certificate-provider/get-certificate-providers/ Description: **Required Permission:** `base.organization.certificateProvider.list` Get list of certificateProvider ## Get list of certificateProvider **Required Permission:** `base.organization.certificateProvider.list` Get list of certificateProvider _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Add new certificateProvider Source: https://docs.applivery.com/en/api/platform/certificate-provider/post-certificate-provider/ Description: **Required Permission:** `base.organization.certificateProvider.create` Add new certificateProvider ## Add new certificateProvider **Required Permission:** `base.organization.certificateProvider.create` Add new certificateProvider _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update certificateProvider Source: https://docs.applivery.com/en/api/platform/certificate-provider/put-certificate-provider/ Description: **Required Permission:** `base.organization.certificateProvider.update` Update certificateProvider ## Update certificateProvider **Required Permission:** `base.organization.certificateProvider.update` Update certificateProvider _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Purge challenges Source: https://docs.applivery.com/en/api/platform/certificateprovider/delete-organizations-organizationid-certificate-providers-certificateproviderid-purge/ Description: **Required Permission:** `base.organization.certificateProvider.purge` Purge challenges ## Purge challenges **Required Permission:** `base.organization.certificateProvider.purge` Purge challenges _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## List available countries Source: https://docs.applivery.com/en/api/platform/countries/get-countries/ Description: Retrieves all country entities for use in regional configuration. ## List available countries Retrieves all country entities for use in regional configuration. _[ApiSecurity schema — see canonical URL]_ No parameters. No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Delete device audience Source: https://docs.applivery.com/en/api/platform/device-audiences/delete-device-audience/ Description: **Required Permission:** `mdm.global.deviceAudience.remove` Delete device audience ## Delete device audience **Required Permission:** `mdm.global.deviceAudience.remove` Delete device audience _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get device audience by ID Source: https://docs.applivery.com/en/api/platform/device-audiences/get-device-audience/ Description: **Required Permission:** `mdm.global.deviceAudience.get` Get device audience by ID ## Get device audience by ID **Required Permission:** `mdm.global.deviceAudience.get` Get device audience by ID _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list of device audiences Source: https://docs.applivery.com/en/api/platform/device-audiences/get-device-audiences/ Description: **Required Permission:** `mdm.global.deviceAudience.list` Get list of device audiences ## Get list of device audiences **Required Permission:** `mdm.global.deviceAudience.list` Get list of device audiences _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Add new device audience Source: https://docs.applivery.com/en/api/platform/device-audiences/post-device-audience/ Description: **Required Permission:** `mdm.global.deviceAudience.create` Add new device audience ## Add new device audience **Required Permission:** `mdm.global.deviceAudience.create` Add new device audience _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Preview device audience members Source: https://docs.applivery.com/en/api/platform/device-audiences/post-preview-multiple/ Description: **Required Permission:** `mdm.global.deviceAudience.preview` Preview device audience members ## Preview device audience members **Required Permission:** `mdm.global.deviceAudience.preview` Preview device audience members _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get device audience members Source: https://docs.applivery.com/en/api/platform/device-audiences/preview/get/ Description: **Required Permission:** `mdm.global.deviceAudience.view` Get device audience members ## Get device audience members **Required Permission:** `mdm.global.deviceAudience.view` Get device audience members _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Preview device audience members Source: https://docs.applivery.com/en/api/platform/device-audiences/preview/post/ Description: **Required Permission:** `mdm.global.deviceAudience.preview` Preview device audience members ## Preview device audience members **Required Permission:** `mdm.global.deviceAudience.preview` Preview device audience members _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update device audience Source: https://docs.applivery.com/en/api/platform/device-audiences/put-device-audience/ Description: **Required Permission:** `mdm.global.deviceAudience.update` Update device audience ## Update device audience **Required Permission:** `mdm.global.deviceAudience.update` Update device audience _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Return hi Source: https://docs.applivery.com/en/api/platform/general/list/ Description: Return Hi ## Return hi Return Hi _[ApiSecurity schema — see canonical URL]_ No parameters. No request body. _[ApiResponse schema — see canonical URL]_ --- ## Return status Source: https://docs.applivery.com/en/api/platform/general/status-list/ Description: Return Status ## Return status Return Status _[ApiSecurity schema — see canonical URL]_ No parameters. No request body. _[ApiResponse schema — see canonical URL]_ --- ## Delete build Source: https://docs.applivery.com/en/api/platform/integration-builds/delete-build/ Description: Delete build ## Delete build Delete build _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Prepare new build (for edge runners) Source: https://docs.applivery.com/en/api/platform/integration-builds/edge/get-prepare/ Description: Prepare new build (for edge runners) ## Prepare new build (for edge runners) Prepare new build (for edge runners) _[ApiSecurity schema — see canonical URL]_ No parameters. No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Add new build (for edge runners) Source: https://docs.applivery.com/en/api/platform/integration-builds/edge/post-build/ Description: Add new build (for edge runners) ## Add new build (for edge runners) Add new build (for edge runners) _[ApiSecurity schema — see canonical URL]_ No parameters. _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Add new build file (for edge runners) Source: https://docs.applivery.com/en/api/platform/integration-builds/edge/post-file/ Description: Add new build file (for edge runners) ## Add new build file (for edge runners) Add new build file (for edge runners) _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Delete build file Source: https://docs.applivery.com/en/api/platform/integration-builds/files/delete-by-id/ Description: Delete build file ## Delete build file Delete build file _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update build attachment file Source: https://docs.applivery.com/en/api/platform/integration-builds/files/put-by-id/ Description: Update build attachment file ## Update build attachment file Update build attachment file _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get build by ID Source: https://docs.applivery.com/en/api/platform/integration-builds/get-build/ Description: Get build by ID ## Get build by ID Get build by ID _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list of builds Source: https://docs.applivery.com/en/api/platform/integration-builds/get-builds/ Description: Get list of builds ## Get list of builds Get list of builds _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update build Source: https://docs.applivery.com/en/api/platform/integration-builds/put-build/ Description: Update build ## Update build Update build _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get sample inventory items csv Source: https://docs.applivery.com/en/api/platform/inventory-item/csv/get-sample/ Description: **Required Permission:** `inventory.item.management.list` Get sample inventory items csv ## Get sample inventory items csv **Required Permission:** `inventory.item.management.list` Get sample inventory items csv _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list of inventory items as csv Source: https://docs.applivery.com/en/api/platform/inventory-item/csv/get/ Description: **Required Permission:** `inventory.item.management.list` Get list of inventory items as csv ## Get list of inventory items as csv **Required Permission:** `inventory.item.management.list` Get list of inventory items as csv _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Delete inventory items Source: https://docs.applivery.com/en/api/platform/inventory-item/delete-inventory-item/ Description: **Required Permission:** `inventory.item.management.remove` Delete inventory items ## Delete inventory items **Required Permission:** `inventory.item.management.remove` Delete inventory items _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get inventory items by Id or Slug Source: https://docs.applivery.com/en/api/platform/inventory-item/get-inventory-item/ Description: **Required Permission:** `inventory.item.management.get` Get inventory items by Id or Slug ## Get inventory items by Id or Slug **Required Permission:** `inventory.item.management.get` Get inventory items by Id or Slug _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list of inventory items Source: https://docs.applivery.com/en/api/platform/inventory-item/get-inventory-items/ Description: **Required Permission:** `inventory.item.management.list` Get list of inventory items ## Get list of inventory items **Required Permission:** `inventory.item.management.list` Get list of inventory items _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## get storageProvider for uploading files Source: https://docs.applivery.com/en/api/platform/inventory-item/get-transactions-edge-prepare/ Description: get storageProvider for uploading files ## get storageProvider for uploading files get storageProvider for uploading files _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Remove note from inventory item Source: https://docs.applivery.com/en/api/platform/inventory-item/notes/delete-by-id/ Description: **Required Permission:** `inventory.item.management.update` Remove note from inventory item ## Remove note from inventory item **Required Permission:** `inventory.item.management.update` Remove note from inventory item _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Add note to inventory item Source: https://docs.applivery.com/en/api/platform/inventory-item/notes/post/ Description: **Required Permission:** `inventory.item.management.update` Add note to inventory item ## Add note to inventory item **Required Permission:** `inventory.item.management.update` Add note to inventory item _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Create inventory items Source: https://docs.applivery.com/en/api/platform/inventory-item/post-inventory-item/ Description: **Required Permission:** `inventory.item.management.create` Create inventory items ## Create inventory items **Required Permission:** `inventory.item.management.create` Create inventory items _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update inventory items Source: https://docs.applivery.com/en/api/platform/inventory-item/put-inventory-item/ Description: **Required Permission:** `inventory.item.management.update` Update inventory items ## Update inventory items **Required Permission:** `inventory.item.management.update` Update inventory items _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Delete key store Source: https://docs.applivery.com/en/api/platform/key-store/delete-key-store-by-id/ Description: Permanently removes a key store and invalidates associated references. ## Delete key store Permanently removes a key store and invalidates associated references. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Retrieve key store details Source: https://docs.applivery.com/en/api/platform/key-store/get-key-store-by-id/ Description: Retrieves a specific key store using its unique identifier. ## Retrieve key store details Retrieves a specific key store using its unique identifier. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Create key store Source: https://docs.applivery.com/en/api/platform/key-store/post-key-store/ Description: Creates a new key store and registers it for secure operations. ## Create key store Creates a new key store and registers it for secure operations. _[ApiSecurity schema — see canonical URL]_ No parameters. _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update key store Source: https://docs.applivery.com/en/api/platform/key-store/put-key-store-by-id/ Description: Updates an existing key store with new configuration or metadata. ## Update key store Updates an existing key store with new configuration or metadata. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## GCP Marketplace signup callback Source: https://docs.applivery.com/en/api/platform/marketplace/post-sign-up/ Description: GCP Marketplace signup callback ## GCP Marketplace signup callback GCP Marketplace signup callback _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get members audit Source: https://docs.applivery.com/en/api/platform/members/get-audit/ Description: **Required Permission:** `people.base.audit.audit` Get members audit ## Get members audit **Required Permission:** `people.base.audit.audit` Get members audit _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Audit Merge member Source: https://docs.applivery.com/en/api/platform/members/post-merge/ Description: **Required Permission:** `people.base.audit.merge` Audit Merge member ## Audit Merge member **Required Permission:** `people.base.audit.merge` Audit Merge member _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get organizations providers Source: https://docs.applivery.com/en/api/platform/open-info/get-provider/ Description: Get organizations providers ## Get organizations providers Get organizations providers _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list of emails Source: https://docs.applivery.com/en/api/platform/organization-emails/get-email/ Description: **Required Permission:** `base.organization.emails.list` Get list of emails ## Get list of emails **Required Permission:** `base.organization.emails.list` Get list of emails _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Reset the password and clean all other fields except from "username" of the HarmonyMobile integration Source: https://docs.applivery.com/en/api/platform/organization-integrations-harmony-mobile/delete-harmony-mobile/ Description: **Required Permission:** `mdm.integration.harmonyMobile.reset` Reset the password and clean all other fields except from "username" of the HarmonyMobile integration ## Reset the password and clean all other fields except from "username" of the HarmonyMobile integration **Required Permission:** `mdm.integration.harmonyMobile.reset` Reset the password and clean all other fields except from "username" of the HarmonyMobile integration _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get the credentials for harmonyMobile integration Source: https://docs.applivery.com/en/api/platform/organization-integrations-harmony-mobile/get-harmony-mobile/ Description: **Required Permission:** `mdm.integration.harmonyMobile.get` Get the credentials for harmonyMobile integration ## Get the credentials for harmonyMobile integration **Required Permission:** `mdm.integration.harmonyMobile.get` Get the credentials for harmonyMobile integration _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update the credentials of the HarmonyMobile integration Source: https://docs.applivery.com/en/api/platform/organization-integrations-harmony-mobile/put-harmony-mobile/ Description: **Required Permission:** `mdm.integration.harmonyMobile.update` Update the credentials of the HarmonyMobile integration ## Update the credentials of the HarmonyMobile integration **Required Permission:** `mdm.integration.harmonyMobile.update` Update the credentials of the HarmonyMobile integration _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Delete notification Source: https://docs.applivery.com/en/api/platform/organization-notifications/delete-notification/ Description: **Required Permission:** `base.organization.notification.remove` Delete notification ## Delete notification **Required Permission:** `base.organization.notification.remove` Delete notification _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get notification by Id or Slug Source: https://docs.applivery.com/en/api/platform/organization-notifications/get-notification/ Description: **Required Permission:** `base.organization.notification.get` Get notification by Id or Slug ## Get notification by Id or Slug **Required Permission:** `base.organization.notification.get` Get notification by Id or Slug _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list of notification Source: https://docs.applivery.com/en/api/platform/organization-notifications/get-notifications/ Description: **Required Permission:** `base.organization.notification.list` Get list of notification ## Get list of notification **Required Permission:** `base.organization.notification.list` Get list of notification _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Create new notification Source: https://docs.applivery.com/en/api/platform/organization-notifications/post-notification/ Description: **Required Permission:** `base.organization.notification.create` Create new notification ## Create new notification **Required Permission:** `base.organization.notification.create` Create new notification _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update notification Source: https://docs.applivery.com/en/api/platform/organization-notifications/put-notification/ Description: **Required Permission:** `base.organization.notification.update` Update notification ## Update notification **Required Permission:** `base.organization.notification.update` Update notification _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get current OEM user profile Source: https://docs.applivery.com/en/api/platform/organization-oem-users/get-profile/ Description: Returns the profile for the currently authenticated OEM workspace user. ## Get current OEM user profile Returns the profile for the currently authenticated OEM workspace user. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Create OEM-provisioned user Source: https://docs.applivery.com/en/api/platform/organization-oem-users/post-user/ Description: Create a new OEM-provisioned user for the organization. Returns the new collaborator. ## Create OEM-provisioned user Create a new OEM-provisioned user for the organization. Returns the new collaborator. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Delete providerScim Source: https://docs.applivery.com/en/api/platform/organization-providers-scim/delete-scim/ Description: **Required Permission:** `base.organization.scim.remove` Delete providerScim ## Delete providerScim **Required Permission:** `base.organization.scim.remove` Delete providerScim _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get providerScim by providerId Source: https://docs.applivery.com/en/api/platform/organization-providers-scim/get-scim/ Description: **Required Permission:** `base.organization.scim.get` Get providerScim by providerId ## Get providerScim by providerId **Required Permission:** `base.organization.scim.get` Get providerScim by providerId _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Add new providerScim Source: https://docs.applivery.com/en/api/platform/organization-providers-scim/post-scim/ Description: **Required Permission:** `base.organization.scim.create` Add new providerScim ## Add new providerScim **Required Permission:** `base.organization.scim.create` Add new providerScim _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update providerScim Source: https://docs.applivery.com/en/api/platform/organization-providers-scim/put-scim/ Description: **Required Permission:** `base.organization.scim.update` Update providerScim ## Update providerScim **Required Permission:** `base.organization.scim.update` Update providerScim _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Delete provider Source: https://docs.applivery.com/en/api/platform/organization-providers/delete-provider/ Description: **Required Permission:** `base.organization.loginProvider.remove` Delete provider ## Delete provider **Required Permission:** `base.organization.loginProvider.remove` Delete provider _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get provider by ID Source: https://docs.applivery.com/en/api/platform/organization-providers/get-provider/ Description: **Required Permission:** `base.organization.loginProvider.get` Get provider by ID ## Get provider by ID **Required Permission:** `base.organization.loginProvider.get` Get provider by ID _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list of providers Source: https://docs.applivery.com/en/api/platform/organization-providers/get-providers/ Description: **Required Permission:** `base.organization.loginProvider.list` Get list of providers ## Get list of providers **Required Permission:** `base.organization.loginProvider.list` Get list of providers _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Add new provider Source: https://docs.applivery.com/en/api/platform/organization-providers/post-provider/ Description: **Required Permission:** `base.organization.loginProvider.create` Add new provider ## Add new provider **Required Permission:** `base.organization.loginProvider.create` Add new provider _[ApiSecurity schema — see canonical URL]_ No parameters. _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update provider Source: https://docs.applivery.com/en/api/platform/organization-providers/put-provider/ Description: **Required Permission:** `base.organization.loginProvider.update` Update provider ## Update provider **Required Permission:** `base.organization.loginProvider.update` Update provider _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update provider saml URIs Source: https://docs.applivery.com/en/api/platform/organization-providers/put-saml-uris/ Description: **Required Permission:** `base.organization.loginProvider.updateSamlUris` Update provider saml URIs ## Update provider saml URIs **Required Permission:** `base.organization.loginProvider.updateSamlUris` Update provider saml URIs _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Remove service account by Id Source: https://docs.applivery.com/en/api/platform/organization-service-accounts/delete-service-account/ Description: **Required Permission:** `people.base.serviceAccount.remove` Remove service account by Id ## Remove service account by Id **Required Permission:** `people.base.serviceAccount.remove` Remove service account by Id _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get service account by Id Source: https://docs.applivery.com/en/api/platform/organization-service-accounts/get-service-account/ Description: **Required Permission:** `people.base.serviceAccount.get` Get service account by Id ## Get service account by Id **Required Permission:** `people.base.serviceAccount.get` Get service account by Id _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list of service accounts Source: https://docs.applivery.com/en/api/platform/organization-service-accounts/get-service-accounts/ Description: **Required Permission:** `people.base.serviceAccount.list` Get list of service accounts ## Get list of service accounts **Required Permission:** `people.base.serviceAccount.list` Get list of service accounts _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Add new serviceAccount Source: https://docs.applivery.com/en/api/platform/organization-service-accounts/post-service-account/ Description: **Required Permission:** `people.base.serviceAccount.create` Add new serviceAccount ## Add new serviceAccount **Required Permission:** `people.base.serviceAccount.create` Add new serviceAccount _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Regenerate serviceAccount session Source: https://docs.applivery.com/en/api/platform/organization-service-accounts/put-session/ Description: **Required Permission:** `people.base.serviceAccount.regenerate` Regenerate serviceAccount session ## Regenerate serviceAccount session **Required Permission:** `people.base.serviceAccount.regenerate` Regenerate serviceAccount session _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get organization stats by day Source: https://docs.applivery.com/en/api/platform/organization-stats/get-by-day/ Description: **Required Permission:** `base.organization.stats.get` Get organization stats by day ## Get organization stats by day **Required Permission:** `base.organization.stats.get` Get organization stats by day _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get organization stats Source: https://docs.applivery.com/en/api/platform/organization-stats/get-stats/ Description: **Required Permission:** `base.organization.stats.get` Get organization stats ## Get organization stats **Required Permission:** `base.organization.stats.get` Get organization stats _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Delete storageProvider Source: https://docs.applivery.com/en/api/platform/organization-storage-providers/delete-storage-provider/ Description: **Required Permission:** `base.organization.storageProvider.delete` Delete storageProvider ## Delete storageProvider **Required Permission:** `base.organization.storageProvider.delete` Delete storageProvider _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## list storageProviders supported Source: https://docs.applivery.com/en/api/platform/organization-storage-providers/get-storage-providers/ Description: **Required Permission:** `base.organization.storageProvider.list` list storageProviders supported ## list storageProviders supported **Required Permission:** `base.organization.storageProvider.list` list storageProviders supported _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Test storageProvider by ID Source: https://docs.applivery.com/en/api/platform/organization-storage-providers/get-test/ Description: **Required Permission:** `base.organization.storageProvider.test` Test storageProvider by ID ## Test storageProvider by ID **Required Permission:** `base.organization.storageProvider.test` Test storageProvider by ID _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Add new storageProvider Source: https://docs.applivery.com/en/api/platform/organization-storage-providers/post-storage-provider/ Description: **Required Permission:** `base.organization.storageProvider.create` Add new storageProvider ## Add new storageProvider **Required Permission:** `base.organization.storageProvider.create` Add new storageProvider _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update storageProvider Source: https://docs.applivery.com/en/api/platform/organization-storage-providers/put-storage-provider/ Description: **Required Permission:** `base.organization.storageProvider.update` Update storageProvider ## Update storageProvider **Required Permission:** `base.organization.storageProvider.update` Update storageProvider _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Delete organization store Source: https://docs.applivery.com/en/api/platform/organization-store/delete-store/ Description: **Required Permission:** `mad.store.management.remove` Deletes a store from the organization and removes its configuration. ## Delete organization store **Required Permission:** `mad.store.management.remove` Deletes a store from the organization and removes its configuration. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Retrieve store by ID Source: https://docs.applivery.com/en/api/platform/organization-store/get-store/ Description: **Required Permission:** `mad.store.management.get` Retrieves details of a specific store using its unique identifier. ## Retrieve store by ID **Required Permission:** `mad.store.management.get` Retrieves details of a specific store using its unique identifier. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## List organization stores Source: https://docs.applivery.com/en/api/platform/organization-store/get-stores/ Description: **Required Permission:** `mad.store.management.list` Retrieves a paginated list of stores belonging to the organization. ## List organization stores **Required Permission:** `mad.store.management.list` Retrieves a paginated list of stores belonging to the organization. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Run store test operation Source: https://docs.applivery.com/en/api/platform/organization-store/get-test/ Description: Executes a test operation for the store and returns the result. ## Run store test operation Executes a test operation for the store and returns the result. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update organization store Source: https://docs.applivery.com/en/api/platform/organization-store/put-store/ Description: **Required Permission:** `mad.store.management.update` Updates the properties and configuration of an existing store. ## Update organization store **Required Permission:** `mad.store.management.update` Updates the properties and configuration of an existing store. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Delete organization workspace permanently Source: https://docs.applivery.com/en/api/platform/organization/delete-organization/ Description: **Required Permission:** `owner.organization.management.remove` Permanently deletes organization workspace and all associated resources including applications, device enrollments, user assignments, and historical data requiring subscription cancellation. ## Delete organization workspace permanently **Required Permission:** `owner.organization.management.remove` Permanently deletes organization workspace and all associated resources including applications, device enrollments, user assignments, and historical data requiring subscription cancellation. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get organization actions Source: https://docs.applivery.com/en/api/platform/organization/get-actions/ Description: **Required Permission:** `base.organization.management.get` Get organization actions ## Get organization actions **Required Permission:** `base.organization.management.get` Get organization actions _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Validate organization slug availability Source: https://docs.applivery.com/en/api/platform/organization/get-check-slug-by-id/ Description: **Required Permission:** `base.organization.management.checkSlug` Validates whether proposed organization slug identifier is available for use, not reserved by system, and conforms to naming conventions before creation. ## Validate organization slug availability **Required Permission:** `base.organization.management.checkSlug` Validates whether proposed organization slug identifier is available for use, not reserved by system, and conforms to naming conventions before creation. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## List organization access control groups Source: https://docs.applivery.com/en/api/platform/organization/get-groups/ Description: **Required Permission:** `base.organization.management.listGroups` Retrieves access control groups within organization scope enabling role-based permissions management, team segmentation, and streamlined assignment of users to applications. ## List organization access control groups **Required Permission:** `base.organization.management.listGroups` Retrieves access control groups within organization scope enabling role-based permissions management, team segmentation, and streamlined assignment of users to applications. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Retrieve organization workspace details Source: https://docs.applivery.com/en/api/platform/organization/get-organization/ Description: **Required Permission:** `base.organization.management.get` Retrieves complete organization information including subscription status, feature entitlements, branding configuration, and security settings using unique identifier or workspace slug. ## Retrieve organization workspace details **Required Permission:** `base.organization.management.get` Retrieves complete organization information including subscription status, feature entitlements, branding configuration, and security settings using unique identifier or workspace slug. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## List accessible organization workspaces Source: https://docs.applivery.com/en/api/platform/organization/get-organizations/ Description: **Required Permission:** `base.organization.management.list` Retrieves a paginated list of workspaces accessible to the authenticated user. This includes filtering and sorting options to enable efficient navigation and management across multiple workspaces ## List accessible organization workspaces **Required Permission:** `base.organization.management.list` Retrieves a paginated list of workspaces accessible to the authenticated user. This includes filtering and sorting options to enable efficient navigation and management across multiple workspaces _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Send organization support email notification Source: https://docs.applivery.com/en/api/platform/organization/get-support-email-by-id/ Description: **Required Permission:** `base.organization.management.sendSupportEmail` Initiates automated email notifications to designated support contacts for organization events such as subscription changes, security alerts, or administrative actions. ## Send organization support email notification **Required Permission:** `base.organization.management.sendSupportEmail` Initiates automated email notifications to designated support contacts for organization events such as subscription changes, security alerts, or administrative actions. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Retrieve workspace context for initialization Source: https://docs.applivery.com/en/api/platform/organization/get-workspace/ Description: **Required Permission:** `base.organization.management.get` Retrieves complete workspace context including organization details, application store configuration, enterprise mobility management settings, and device enrollment for dashboard initialization. ## Retrieve workspace context for initialization **Required Permission:** `base.organization.management.get` Retrieves complete workspace context including organization details, application store configuration, enterprise mobility management settings, and device enrollment for dashboard initialization. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Transfer organization ownership to user Source: https://docs.applivery.com/en/api/platform/organization/post-change-owner/ Description: **Required Permission:** `owner.organization.management.ownerChange` Transfers primary ownership and administrative control of organization workspace to different user including billing responsibilities, access privileges, and legal accountability. ## Transfer organization ownership to user **Required Permission:** `owner.organization.management.ownerChange` Transfers primary ownership and administrative control of organization workspace to different user including billing responsibilities, access privileges, and legal accountability. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Create new organization workspace Source: https://docs.applivery.com/en/api/platform/organization/post-organization/ Description: **Required Permission:** `base.organization.management.create` Creates new organization workspace serving as primary container for managing mobile applications, device fleets, user access, billing settings, and collaborative team workflows. ## Create new organization workspace **Required Permission:** `base.organization.management.create` Creates new organization workspace serving as primary container for managing mobile applications, device fleets, user access, billing settings, and collaborative team workflows. _[ApiSecurity schema — see canonical URL]_ No parameters. _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update organization workspace settings Source: https://docs.applivery.com/en/api/platform/organization/put-organization/ Description: **Required Permission:** `base.organization.management.update` Updates organization settings including branding elements, authentication providers, contact information, security policies, and feature configurations to customize workspace per requirements. ## Update organization workspace settings **Required Permission:** `base.organization.management.update` Updates organization settings including branding elements, authentication providers, contact information, security policies, and feature configurations to customize workspace per requirements. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Delete an OTP user from the store Source: https://docs.applivery.com/en/api/platform/otp-users/delete-otp-user/ Description: **Required Permission:** `mad.store.otpUsers.remove` Permanently removes an OTP user and revokes their download access. ## Delete an OTP user from the store **Required Permission:** `mad.store.otpUsers.remove` Permanently removes an OTP user and revokes their download access. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Retrieve a single OTP user by identifier Source: https://docs.applivery.com/en/api/platform/otp-users/get-otp-user/ Description: **Required Permission:** `mad.store.otpUsers.get` Returns the full details of an OTP user including download and login activity. ## Retrieve a single OTP user by identifier **Required Permission:** `mad.store.otpUsers.get` Returns the full details of an OTP user including download and login activity. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## List OTP users with optional filtering Source: https://docs.applivery.com/en/api/platform/otp-users/get-otp-users/ Description: **Required Permission:** `mad.store.otpUsers.list` Returns a paginated collection of OTP users scoped to the specified store. ## List OTP users with optional filtering **Required Permission:** `mad.store.otpUsers.list` Returns a paginated collection of OTP users scoped to the specified store. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Create one or more OTP users Source: https://docs.applivery.com/en/api/platform/otp-users/post-otp-user/ Description: **Required Permission:** `mad.store.otpUsers.create` Provisions OTP user accounts and associates them with a published application. ## Create one or more OTP users **Required Permission:** `mad.store.otpUsers.create` Provisions OTP user accounts and associates them with a published application. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update an existing OTP user configuration Source: https://docs.applivery.com/en/api/platform/otp-users/put-otp-user/ Description: **Required Permission:** `mad.store.otpUsers.update` Modifies the download allowance settings for a specific OTP user. ## Update an existing OTP user configuration **Required Permission:** `mad.store.otpUsers.update` Modifies the download allowance settings for a specific OTP user. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Retrieve package information by name Source: https://docs.applivery.com/en/api/platform/package-information/get-package/ Description: **Required Permission:** `mdm.android.package.get` Retrieves Android Enterprise package metadata and version details from the managed catalog. ## Retrieve package information by name **Required Permission:** `mdm.android.package.get` Retrieves Android Enterprise package metadata and version details from the managed catalog. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list of people paginated Source: https://docs.applivery.com/en/api/platform/people/get-people/ Description: **Required Permission:** `people.base.management.list` Get list of people paginated ## Get list of people paginated **Required Permission:** `people.base.management.list` Get list of people paginated _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get search data Source: https://docs.applivery.com/en/api/platform/search-feature/get-search/ Description: Get search data ## Get search data Get search data _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Delete segment permission Source: https://docs.applivery.com/en/api/platform/segment-permission/delete-segment-permission/ Description: **Required Permission:** `base.organization.segmentPermission.remove` Delete segment permission. Only the organization owner may delete a permission that grants billing.* actions, directly or through its roles. ## Delete segment permission **Required Permission:** `base.organization.segmentPermission.remove` Delete segment permission. Only the organization owner may delete a permission that grants billing.* actions, directly or through its roles. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get segment permission Source: https://docs.applivery.com/en/api/platform/segment-permission/get-segment-permission/ Description: **Required Permission:** `base.organization.segmentPermission.get` Get segment permission ## Get segment permission **Required Permission:** `base.organization.segmentPermission.get` Get segment permission _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## List segment permissions Source: https://docs.applivery.com/en/api/platform/segment-permission/get-segment-permissions/ Description: **Required Permission:** `base.organization.segmentPermission.list` List segment permissions ## List segment permissions **Required Permission:** `base.organization.segmentPermission.list` List segment permissions _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get user segment permissions Source: https://docs.applivery.com/en/api/platform/segment-permission/get-users/ Description: **Required Permission:** `base.organization.segmentPermission.userList` Get user segment permissions ## Get user segment permissions **Required Permission:** `base.organization.segmentPermission.userList` Get user segment permissions _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Preview segment permission Source: https://docs.applivery.com/en/api/platform/segment-permission/post-preview/ Description: **Required Permission:** `base.organization.segmentPermission.preview` Preview segment permission ## Preview segment permission **Required Permission:** `base.organization.segmentPermission.preview` Preview segment permission _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Create segment permission Source: https://docs.applivery.com/en/api/platform/segment-permission/post-segment-permission/ Description: **Required Permission:** `base.organization.segmentPermission.create` Create segment permission. Only the organization owner may grant billing.* actions, directly or through its roles (including the reserved owner role). people.mad.* and owner.* actions are rejected. ## Create segment permission **Required Permission:** `base.organization.segmentPermission.create` Create segment permission. Only the organization owner may grant billing.* actions, directly or through its roles (including the reserved owner role). people.mad.* and owner.* actions are rejected. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update segment permission Source: https://docs.applivery.com/en/api/platform/segment-permission/put-segment-permission/ Description: **Required Permission:** `base.organization.segmentPermission.update` Update segment permission. Only the organization owner may add or remove billing.* actions, directly or through its roles, or change the users or segment of a permission that grants them. Other changes stay open, even when the unchanged values are sent again. people.mad.* and owner.* actions are rejected. ## Update segment permission **Required Permission:** `base.organization.segmentPermission.update` Update segment permission. Only the organization owner may add or remove billing.* actions, directly or through its roles, or change the users or segment of a permission that grants them. Other changes stay open, even when the unchanged values are sent again. people.mad.* and owner.* actions are rejected. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Delete segment role Source: https://docs.applivery.com/en/api/platform/segment-role/delete-segment-role/ Description: **Required Permission:** `base.organization.segmentRole.remove` Deletes a segment role and revokes it from every collaborator holding it. ## Delete segment role **Required Permission:** `base.organization.segmentRole.remove` Deletes a segment role and revokes it from every collaborator holding it. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get segment role Source: https://docs.applivery.com/en/api/platform/segment-role/get-segment-role/ Description: **Required Permission:** `base.organization.segmentRole.get` Returns a single segment role with its granted actions. ## Get segment role **Required Permission:** `base.organization.segmentRole.get` Returns a single segment role with its granted actions. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## List segment roles Source: https://docs.applivery.com/en/api/platform/segment-role/get-segment-roles/ Description: **Required Permission:** `base.organization.segmentRole.list` Returns every segment role defined in the organization. ## List segment roles **Required Permission:** `base.organization.segmentRole.list` Returns every segment role defined in the organization. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Create segment role Source: https://docs.applivery.com/en/api/platform/segment-role/post-segment-role/ Description: **Required Permission:** `base.organization.segmentRole.create` Creates a segment role with the given name and granted actions. ## Create segment role **Required Permission:** `base.organization.segmentRole.create` Creates a segment role with the given name and granted actions. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update segment role Source: https://docs.applivery.com/en/api/platform/segment-role/put-segment-role/ Description: **Required Permission:** `base.organization.segmentRole.update` Updates the name, description or granted actions of a segment role. ## Update segment role **Required Permission:** `base.organization.segmentRole.update` Updates the name, description or granted actions of a segment role. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Delete segment Source: https://docs.applivery.com/en/api/platform/segment/delete-segment/ Description: **Required Permission:** `base.organization.segment.remove` Delete segment ## Delete segment **Required Permission:** `base.organization.segment.remove` Delete segment _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get segment actions Source: https://docs.applivery.com/en/api/platform/segment/get-actions/ Description: **Required Permission:** `base.organization.segment.actions` Get segment actions ## Get segment actions **Required Permission:** `base.organization.segment.actions` Get segment actions _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get segments visible to user Source: https://docs.applivery.com/en/api/platform/segment/get-by-user/ Description: Get segments visible to user ## Get segments visible to user Get segments visible to user _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get segment counts by entity Source: https://docs.applivery.com/en/api/platform/segment/get-counts-by-entity-by-id/ Description: **Required Permission:** `base.organization.segment.counts` Get segment counts by entity ## Get segment counts by entity **Required Permission:** `base.organization.segment.counts` Get segment counts by entity _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get segment counts Source: https://docs.applivery.com/en/api/platform/segment/get-counts/ Description: **Required Permission:** `base.organization.segment.counts` Get segment counts ## Get segment counts **Required Permission:** `base.organization.segment.counts` Get segment counts _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get visible segment tree for user Source: https://docs.applivery.com/en/api/platform/segment/get-segment-tree/ Description: Get visible segment tree for user ## Get visible segment tree for user Get visible segment tree for user _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get segment by ID Source: https://docs.applivery.com/en/api/platform/segment/get-segment/ Description: **Required Permission:** `base.organization.segment.get` Get segment by ID ## Get segment by ID **Required Permission:** `base.organization.segment.get` Get segment by ID _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list of segments Source: https://docs.applivery.com/en/api/platform/segment/get-segments/ Description: **Required Permission:** `base.organization.segment.list` Get list of segments ## Get list of segments **Required Permission:** `base.organization.segment.list` Get list of segments _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Create segment Source: https://docs.applivery.com/en/api/platform/segment/post-segment/ Description: **Required Permission:** `base.organization.segment.create` Create segment ## Create segment **Required Permission:** `base.organization.segment.create` Create segment _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update segment Source: https://docs.applivery.com/en/api/platform/segment/put-segment/ Description: **Required Permission:** `base.organization.segment.update` Update segment ## Update segment **Required Permission:** `base.organization.segment.update` Update segment _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Remove a smart attribute Source: https://docs.applivery.com/en/api/platform/smart-attributes/delete-smart-attribute/ Description: **Required Permission:** `mdm.global.smartAttribute.remove` Deletes an existing smart attribute ## Remove a smart attribute **Required Permission:** `mdm.global.smartAttribute.remove` Deletes an existing smart attribute _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Check the assignments for a smart attribute Source: https://docs.applivery.com/en/api/platform/smart-attributes/get-assignments/ Description: **Required Permission:** `mdm.global.smartAttribute.get` ## Check the assignments for a smart attribute **Required Permission:** `mdm.global.smartAttribute.get` _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Retrieve a smart attribute by its ID Source: https://docs.applivery.com/en/api/platform/smart-attributes/get-smart-attribute/ Description: **Required Permission:** `mdm.global.smartAttribute.get` Returns the details of a specific smart attribute using its ID as search parameter ## Retrieve a smart attribute by its ID **Required Permission:** `mdm.global.smartAttribute.get` Returns the details of a specific smart attribute using its ID as search parameter _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Retrieve a paginated list of available smart attributes Source: https://docs.applivery.com/en/api/platform/smart-attributes/get-smart-attributes/ Description: **Required Permission:** `mdm.global.smartAttribute.list` Returns a paginated collection of smart attributes ## Retrieve a paginated list of available smart attributes **Required Permission:** `mdm.global.smartAttribute.list` Returns a paginated collection of smart attributes _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Create a smart attribute Source: https://docs.applivery.com/en/api/platform/smart-attributes/post-smart-attribute/ Description: **Required Permission:** `mdm.global.smartAttribute.create` Creates a new smart attribute and persists it for use across supported resources ## Create a smart attribute **Required Permission:** `mdm.global.smartAttribute.create` Creates a new smart attribute and persists it for use across supported resources _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update a smart attribute Source: https://docs.applivery.com/en/api/platform/smart-attributes/put-smart-attribute/ Description: **Required Permission:** `mdm.global.smartAttribute.update` Applies partial updates to an existing smart attribute ## Update a smart attribute **Required Permission:** `mdm.global.smartAttribute.update` Applies partial updates to an existing smart attribute _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Delete User Audience Source: https://docs.applivery.com/en/api/platform/user-audience/apps/delete-user-audience/ Description: **Required Permission:** `mad.userAudience.application.remove` Delete User Audience ## Delete User Audience **Required Permission:** `mad.userAudience.application.remove` Delete User Audience _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get User Audience target Source: https://docs.applivery.com/en/api/platform/user-audience/apps/get-target/ Description: **Required Permission:** `mad.userAudience.application.target` Get User Audience target ## Get User Audience target **Required Permission:** `mad.userAudience.application.target` Get User Audience target _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get User Audience Source: https://docs.applivery.com/en/api/platform/user-audience/apps/get-user-audience/ Description: **Required Permission:** `mad.userAudience.application.get` Get User Audience ## Get User Audience **Required Permission:** `mad.userAudience.application.get` Get User Audience _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## List Audiences Source: https://docs.applivery.com/en/api/platform/user-audience/apps/get-user-audiences/ Description: **Required Permission:** `mad.userAudience.application.list` List Audiences ## List Audiences **Required Permission:** `mad.userAudience.application.list` List Audiences _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get User Audience preview Source: https://docs.applivery.com/en/api/platform/user-audience/apps/post-preview/ Description: **Required Permission:** `mad.userAudience.application.preview` Get User Audience preview ## Get User Audience preview **Required Permission:** `mad.userAudience.application.preview` Get User Audience preview _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Create User Audience Source: https://docs.applivery.com/en/api/platform/user-audience/apps/post-user-audience/ Description: **Required Permission:** `mad.userAudience.application.create` Create User Audience ## Create User Audience **Required Permission:** `mad.userAudience.application.create` Create User Audience _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update User Audience Source: https://docs.applivery.com/en/api/platform/user-audience/apps/put-user-audience/ Description: **Required Permission:** `mad.userAudience.application.update` Update User Audience ## Update User Audience **Required Permission:** `mad.userAudience.application.update` Update User Audience _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Delete User Audience Source: https://docs.applivery.com/en/api/platform/user-audience/delete-user-audience/ Description: **Required Permission:** `mad.userAudience.organization.remove` Delete User Audience ## Delete User Audience **Required Permission:** `mad.userAudience.organization.remove` Delete User Audience _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get User Audience target Source: https://docs.applivery.com/en/api/platform/user-audience/get-target/ Description: **Required Permission:** `mad.userAudience.organization.target` Get User Audience target ## Get User Audience target **Required Permission:** `mad.userAudience.organization.target` Get User Audience target _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get User Audience Source: https://docs.applivery.com/en/api/platform/user-audience/get-user-audience/ Description: **Required Permission:** `mad.userAudience.organization.get` Get User Audience ## Get User Audience **Required Permission:** `mad.userAudience.organization.get` Get User Audience _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## List Audiences Source: https://docs.applivery.com/en/api/platform/user-audience/get-user-audiences/ Description: **Required Permission:** `mad.userAudience.organization.list` List Audiences ## List Audiences **Required Permission:** `mad.userAudience.organization.list` List Audiences _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get User Audience preview Source: https://docs.applivery.com/en/api/platform/user-audience/post-preview/ Description: **Required Permission:** `mad.userAudience.organization.preview` Get User Audience preview ## Get User Audience preview **Required Permission:** `mad.userAudience.organization.preview` Get User Audience preview _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Create User Audience Source: https://docs.applivery.com/en/api/platform/user-audience/post-user-audience/ Description: **Required Permission:** `mad.userAudience.organization.create` Create User Audience ## Create User Audience **Required Permission:** `mad.userAudience.organization.create` Create User Audience _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update User Audience Source: https://docs.applivery.com/en/api/platform/user-audience/put-user-audience/ Description: **Required Permission:** `mad.userAudience.organization.update` Update User Audience ## Update User Audience **Required Permission:** `mad.userAudience.organization.update` Update User Audience _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Deactivate two factor Source: https://docs.applivery.com/en/api/platform/user-authentication/delete-two-factor/ Description: Deactivate two factor ## Deactivate two factor Deactivate two factor _[ApiSecurity schema — see canonical URL]_ No parameters. _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Logout user Source: https://docs.applivery.com/en/api/platform/user-authentication/get-logout/ Description: Logout user ## Logout user Logout user _[ApiSecurity schema — see canonical URL]_ No parameters. No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Generate two factor secret Source: https://docs.applivery.com/en/api/platform/user-authentication/get-two-factor/ Description: Generate two factor secret ## Generate two factor secret Generate two factor secret _[ApiSecurity schema — see canonical URL]_ No parameters. No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Change Password with forgot password token Source: https://docs.applivery.com/en/api/platform/user-authentication/post-change-password/ Description: Change Password with forgot password token ## Change Password with forgot password token Change Password with forgot password token _[ApiSecurity schema — see canonical URL]_ No parameters. _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Forgot password Source: https://docs.applivery.com/en/api/platform/user-authentication/post-forgot-password/ Description: Forgot password ## Forgot password Forgot password _[ApiSecurity schema — see canonical URL]_ No parameters. _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Login user Source: https://docs.applivery.com/en/api/platform/user-authentication/post-login/ Description: Login user ## Login user Login user _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Token from RefreshToken Source: https://docs.applivery.com/en/api/platform/user-authentication/post-refresh/ Description: RegenerateToken from RefreshToken ## Token from RefreshToken RegenerateToken from RefreshToken _[ApiSecurity schema — see canonical URL]_ No parameters. _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Register user Source: https://docs.applivery.com/en/api/platform/user-authentication/post-register/ Description: Register user ## Register user Register user _[ApiSecurity schema — see canonical URL]_ No parameters. _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Activate two factor Source: https://docs.applivery.com/en/api/platform/user-authentication/post-two-factor/ Description: Activate two factor ## Activate two factor Activate two factor _[ApiSecurity schema — see canonical URL]_ No parameters. _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update Password from profile Source: https://docs.applivery.com/en/api/platform/user-authentication/post-update-password/ Description: Update Password from profile ## Update Password from profile Update Password from profile _[ApiSecurity schema — see canonical URL]_ No parameters. _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Send Verify Email Source: https://docs.applivery.com/en/api/platform/user-authentication/post-verify-resend/ Description: Send Verify Email ## Send Verify Email Send Verify Email _[ApiSecurity schema — see canonical URL]_ No parameters. _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Verify email Source: https://docs.applivery.com/en/api/platform/user-authentication/post-verify/ Description: Verify email ## Verify email Verify email _[ApiSecurity schema — see canonical URL]_ No parameters. _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## SSO Logout Source: https://docs.applivery.com/en/api/platform/user-authentication/sso/get-logout/ Description: SSO Logout ## SSO Logout SSO Logout _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get SSO Metadata Source: https://docs.applivery.com/en/api/platform/user-authentication/sso/get-metadata/ Description: Get SSO Metadata ## Get SSO Metadata Get SSO Metadata _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get SSO Type Source: https://docs.applivery.com/en/api/platform/user-authentication/sso/get-type/ Description: Get SSO Type ## Get SSO Type Get SSO Type _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## SSO Callback Source: https://docs.applivery.com/en/api/platform/user-authentication/sso/post-callback/ Description: SSO Callback ## SSO Callback SSO Callback _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get SSO Test Source: https://docs.applivery.com/en/api/platform/user-authentication/sso/post-test/ Description: Get SSO Test ## Get SSO Test Get SSO Test _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Delete notificationFilter Source: https://docs.applivery.com/en/api/platform/users-notifications/delete-notification-filter/ Description: Delete notificationFilter ## Delete notificationFilter Delete notificationFilter _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get notificationFilter Source: https://docs.applivery.com/en/api/platform/users-notifications/get-notification-filter/ Description: Get notificationFilter ## Get notificationFilter Get notificationFilter _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get notificationFilters Source: https://docs.applivery.com/en/api/platform/users-notifications/get-notification-filters/ Description: Get notificationFilters ## Get notificationFilters Get notificationFilters _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Add new notificationFilter Source: https://docs.applivery.com/en/api/platform/users-notifications/post-notification-filter/ Description: Add new notificationFilter ## Add new notificationFilter Add new notificationFilter _[ApiSecurity schema — see canonical URL]_ No parameters. _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update NotificationFilter Source: https://docs.applivery.com/en/api/platform/users-notifications/put-notification-filter/ Description: Update NotificationFilter ## Update NotificationFilter Update NotificationFilter _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Retrieve the requesting user’s profile information Source: https://docs.applivery.com/en/api/platform/users/get-profile/ Description: Retrieves complete profile information for the currently authenticated user, including personal details, organization memberships, activity history, and account settings used to populate dashboard navigation and personalization features. ## Retrieve the requesting user’s profile information Retrieves complete profile information for the currently authenticated user, including personal details, organization memberships, activity history, and account settings used to populate dashboard navigation and personalization features. _[ApiSecurity schema — see canonical URL]_ No parameters. No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update the requesting user’s account password Source: https://docs.applivery.com/en/api/platform/users/post-change-password/ Description: Allows the currently authenticated user to change their account password by providing their existing password for verification and a new password that meets security requirements for enhanced account protection. ## Update the requesting user’s account password Allows the currently authenticated user to change their account password by providing their existing password for verification and a new password that meets security requirements for enhanced account protection. _[ApiSecurity schema — see canonical URL]_ No parameters. _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Remove mdmAgentLogs Source: https://docs.applivery.com/en/api/uem/agent-logs/delete-agent-log/ Description: **Required Permission:** `mdm.global.agentLog.remove` Remove mdmAgentLogs ## Remove mdmAgentLogs **Required Permission:** `mdm.global.agentLog.remove` Remove mdmAgentLogs _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get mdmAgentLogs by Id Source: https://docs.applivery.com/en/api/uem/agent-logs/get-agent-log/ Description: **Required Permission:** `mdm.global.agentLog.get` Get mdmAgentLogs by Id ## Get mdmAgentLogs by Id **Required Permission:** `mdm.global.agentLog.get` Get mdmAgentLogs by Id _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list of mdmAgentLogs Source: https://docs.applivery.com/en/api/uem/agent-logs/get-agent-logs/ Description: **Required Permission:** `mdm.global.agentLog.list` Get list of mdmAgentLogs ## Get list of mdmAgentLogs **Required Permission:** `mdm.global.agentLog.list` Get list of mdmAgentLogs _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Delete a MDM agent trace record Source: https://docs.applivery.com/en/api/uem/agent-trace/delete-agent-trace-by-id/ Description: Permanently removes a specific MDM agent trace from the system. ## Delete a MDM agent trace record Permanently removes a specific MDM agent trace from the system. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get MDM agent trace details Source: https://docs.applivery.com/en/api/uem/agent-trace/get-agent-trace-by-id/ Description: Retrieves the details for a specific MDM agent trace ## Get MDM agent trace details Retrieves the details for a specific MDM agent trace _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Retrieve MDM agent traces Source: https://docs.applivery.com/en/api/uem/agent-trace/get-agent-trace/ Description: Returns a paginated list of MDM agent traces ## Retrieve MDM agent traces Returns a paginated list of MDM agent traces _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Generate QR image Source: https://docs.applivery.com/en/api/uem/assets/get-qr/ Description: Generate QR image ## Generate QR image Generate QR image _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list of mdmAutomationRuleLogs Source: https://docs.applivery.com/en/api/uem/automation-rules-logs/get-automation-rules-logs/ Description: **Required Permission:** `mdm.global.automationRuleLog.list` Get list of mdmAutomationRuleLogs ## Get list of mdmAutomationRuleLogs **Required Permission:** `mdm.global.automationRuleLog.list` Get list of mdmAutomationRuleLogs _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Delete mdmAutomationRule Source: https://docs.applivery.com/en/api/uem/automation-rules/delete-automation-rule/ Description: **Required Permission:** `mdm.global.automationRule.remove` Delete mdmAutomationRule ## Delete mdmAutomationRule **Required Permission:** `mdm.global.automationRule.remove` Delete mdmAutomationRule _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get mdmAutomationRule by id Source: https://docs.applivery.com/en/api/uem/automation-rules/get-automation-rule/ Description: **Required Permission:** `mdm.global.automationRule.get` Get mdmAutomationRule by id ## Get mdmAutomationRule by id **Required Permission:** `mdm.global.automationRule.get` Get mdmAutomationRule by id _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list of mdmAutomationRule Source: https://docs.applivery.com/en/api/uem/automation-rules/get-automation-rules/ Description: **Required Permission:** `mdm.global.automationRule.list` Get list of mdmAutomationRule ## Get list of mdmAutomationRule **Required Permission:** `mdm.global.automationRule.list` Get list of mdmAutomationRule _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Create mdmAutomationRule Source: https://docs.applivery.com/en/api/uem/automation-rules/post-automation-rule/ Description: **Required Permission:** `mdm.global.automationRule.create` Create mdmAutomationRule ## Create mdmAutomationRule **Required Permission:** `mdm.global.automationRule.create` Create mdmAutomationRule _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update mdmAutomationRule Source: https://docs.applivery.com/en/api/uem/automation-rules/put-automation-rule/ Description: **Required Permission:** `mdm.global.automationRule.update` Update mdmAutomationRule ## Update mdmAutomationRule **Required Permission:** `mdm.global.automationRule.update` Update mdmAutomationRule _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Retrieve MDM configurations Source: https://docs.applivery.com/en/api/uem/configurations/get-organizations-organizationid-mdm-configurations/ Description: **Required Permission:** `mdm.global.configurations.get` Returns the MDM integration credentials and settings for the organization. ## Retrieve MDM configurations **Required Permission:** `mdm.global.configurations.get` Returns the MDM integration credentials and settings for the organization. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update MDM configurations Source: https://docs.applivery.com/en/api/uem/configurations/put-organizations-organizationid-mdm-configurations/ Description: **Required Permission:** `mdm.global.configurations.update` Creates or replaces the MDM integration credentials for the organization. ## Update MDM configurations **Required Permission:** `mdm.global.configurations.update` Creates or replaces the MDM integration credentials for the organization. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get device message Source: https://docs.applivery.com/en/api/uem/device-message/get-device-message/ Description: **Required Permission:** `mdm.global.deviceMessage.get` Retrieves the details for a specific device message ## Get device message **Required Permission:** `mdm.global.deviceMessage.get` Retrieves the details for a specific device message _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ --- ## Retrieve device messages Source: https://docs.applivery.com/en/api/uem/device-message/get-device-messages/ Description: **Required Permission:** `mdm.global.deviceMessage.list` Returns a paginated list of device messages ## Retrieve device messages **Required Permission:** `mdm.global.deviceMessage.list` Returns a paginated list of device messages _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ --- ## Get device message Source: https://docs.applivery.com/en/api/uem/device-message/get-organizations-organizationid-mdm-device-messages-devicemessageid/ Description: **Required Permission:** `mdm.global.deviceMessage.get` Retrieves the details for a specific device message ## Get device message **Required Permission:** `mdm.global.deviceMessage.get` Retrieves the details for a specific device message _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ --- ## Retrieve device messages Source: https://docs.applivery.com/en/api/uem/device-message/get-organizations-organizationid-mdm-device-messages/ Description: **Required Permission:** `mdm.global.deviceMessage.list` Returns a paginated list of device messages ## Retrieve device messages **Required Permission:** `mdm.global.deviceMessage.list` Returns a paginated list of device messages _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ --- ## List available OS updates across fleet Source: https://docs.applivery.com/en/api/uem/devices/get-available-updates/ Description: **Required Permission:** `mdm.global.device.list` Retrieves aggregated list of pending operating system updates available for managed devices with distribution counts, enabling coordinated update campaigns and security patch management. ## List available OS updates across fleet **Required Permission:** `mdm.global.device.list` Retrieves aggregated list of pending operating system updates available for managed devices with distribution counts, enabling coordinated update campaigns and security patch management. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Export device list to CSV format Source: https://docs.applivery.com/en/api/uem/devices/get-csv/ Description: **Required Permission:** `mdm.global.device.list` Generates CSV export of complete device list with all filter options applied, including policies, compliance states, and metadata for offline analysis and reporting. ## Export device list to CSV format **Required Permission:** `mdm.global.device.list` Generates CSV export of complete device list with all filter options applied, including policies, compliance states, and metadata for offline analysis and reporting. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Retrieve unified cross-platform device list Source: https://docs.applivery.com/en/api/uem/devices/get-devices/ Description: **Required Permission:** `mdm.global.device.list` Retrieves paginated list of all managed endpoints across Android Enterprise, AOSP non-GMS Android, iOS, macOS, and Windows with extensive filtering, compliance tracking, and policy assignment visibility for comprehensive fleet management. ## Retrieve unified cross-platform device list **Required Permission:** `mdm.global.device.list` Retrieves paginated list of all managed endpoints across Android Enterprise, AOSP non-GMS Android, iOS, macOS, and Windows with extensive filtering, compliance tracking, and policy assignment visibility for comprehensive fleet management. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Retrieve OS version distribution statistics Source: https://docs.applivery.com/en/api/uem/devices/get-os-versions/ Description: **Required Permission:** `mdm.global.device.list` Retrieves aggregated operating system version distribution across managed fleet with device counts per version, essential for update planning and security compliance auditing. ## Retrieve OS version distribution statistics **Required Permission:** `mdm.global.device.list` Retrieves aggregated operating system version distribution across managed fleet with device counts per version, essential for update planning and security compliance auditing. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Identify devices with synchronization failures Source: https://docs.applivery.com/en/api/uem/devices/get-sync-errors/ Description: **Required Permission:** `mdm.global.device.list` Retrieves list of managed devices experiencing communication failures with management servers, enabling IT teams to quickly diagnose and resolve connectivity or authentication issues. ## Identify devices with synchronization failures **Required Permission:** `mdm.global.device.list` Retrieves list of managed devices experiencing communication failures with management servers, enabling IT teams to quickly diagnose and resolve connectivity or authentication issues. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Fetch all unique device organizational tags Source: https://docs.applivery.com/en/api/uem/devices/get-tags/ Description: **Required Permission:** `mdm.global.device.list` Retrieves complete list of unique tags assigned across all managed devices, enabling administrators to build dynamic filters and discover organizational grouping patterns for reporting. ## Fetch all unique device organizational tags **Required Permission:** `mdm.global.device.list` Retrieves complete list of unique tags assigned across all managed devices, enabling administrators to build dynamic filters and discover organizational grouping patterns for reporting. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Delete mdmLocation Source: https://docs.applivery.com/en/api/uem/locations/delete-location/ Description: **Required Permission:** `mdm.global.location.remove` Delete mdmLocation ## Delete mdmLocation **Required Permission:** `mdm.global.location.remove` Delete mdmLocation _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get mdmLocation by ID Source: https://docs.applivery.com/en/api/uem/locations/get-location/ Description: **Required Permission:** `mdm.global.location.get` Get mdmLocation by ID ## Get mdmLocation by ID **Required Permission:** `mdm.global.location.get` Get mdmLocation by ID _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list of mdmLocation Source: https://docs.applivery.com/en/api/uem/locations/get-locations/ Description: **Required Permission:** `mdm.global.location.list` Get list of mdmLocation ## Get list of mdmLocation **Required Permission:** `mdm.global.location.list` Get list of mdmLocation _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Create asset Source: https://docs.applivery.com/en/api/uem/managed-assets/create/ Description: Create asset ## Create asset Create asset _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ --- ## Delete mdmAsset Source: https://docs.applivery.com/en/api/uem/managed-assets/delete-asset/ Description: **Required Permission:** `mdm.global.asset.remove` Delete mdmAsset ## Delete mdmAsset **Required Permission:** `mdm.global.asset.remove` Delete mdmAsset _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Prepare new asset (for edge runners) Source: https://docs.applivery.com/en/api/uem/managed-assets/edge/get-prepare/ Description: **Required Permission:** `mdm.global.asset.create` Prepare new asset (for edge runners) ## Prepare new asset (for edge runners) **Required Permission:** `mdm.global.asset.create` Prepare new asset (for edge runners) _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Add new asset (for edge runners) Source: https://docs.applivery.com/en/api/uem/managed-assets/edge/post-asset/ Description: **Required Permission:** `mdm.global.asset.create` Add new asset (for edge runners) ## Add new asset (for edge runners) **Required Permission:** `mdm.global.asset.create` Add new asset (for edge runners) _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get mdmAsset by ID Source: https://docs.applivery.com/en/api/uem/managed-assets/get-asset/ Description: **Required Permission:** `mdm.global.asset.get` Get mdmAsset by ID ## Get mdmAsset by ID **Required Permission:** `mdm.global.asset.get` Get mdmAsset by ID _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list of mdmAsset Source: https://docs.applivery.com/en/api/uem/managed-assets/get-assets/ Description: **Required Permission:** `mdm.global.asset.list` Get list of mdmAsset ## Get list of mdmAsset **Required Permission:** `mdm.global.asset.list` Get list of mdmAsset _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Check mdmAsset assignation Source: https://docs.applivery.com/en/api/uem/managed-assets/get-assignations/ Description: **Required Permission:** `mdm.global.asset.get` Check mdmAsset assignation ## Check mdmAsset assignation **Required Permission:** `mdm.global.asset.get` Check mdmAsset assignation _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Download mdmAsset Source: https://docs.applivery.com/en/api/uem/managed-assets/get-download/ Description: **Required Permission:** `mdm.global.asset.download` Download mdmAsset ## Download mdmAsset **Required Permission:** `mdm.global.asset.download` Download mdmAsset _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## View mdmAsset content Source: https://docs.applivery.com/en/api/uem/managed-assets/get-view/ Description: **Required Permission:** `mdm.global.asset.view` View mdmAsset content ## View mdmAsset content **Required Permission:** `mdm.global.asset.view` View mdmAsset content _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update mdmAsset Source: https://docs.applivery.com/en/api/uem/managed-assets/put-asset/ Description: **Required Permission:** `mdm.global.asset.update` Update mdmAsset ## Update mdmAsset **Required Permission:** `mdm.global.asset.update` Update mdmAsset _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get asset Source: https://docs.applivery.com/en/api/uem/managed-assets/retrieve/ Description: Get asset ## Get asset Get asset _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ --- ## Delete mdmNetworkStatus Source: https://docs.applivery.com/en/api/uem/network-status/delete-network-status/ Description: **Required Permission:** `mdm.global.networkStatus.remove` Delete mdmNetworkStatus ## Delete mdmNetworkStatus **Required Permission:** `mdm.global.networkStatus.remove` Delete mdmNetworkStatus _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get mdmNetworkStatus by ID Source: https://docs.applivery.com/en/api/uem/network-status/get-network-status/ Description: **Required Permission:** `mdm.global.networkStatus.get` Get mdmNetworkStatus by ID ## Get mdmNetworkStatus by ID **Required Permission:** `mdm.global.networkStatus.get` Get mdmNetworkStatus by ID _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list of mdmNetworkStatus Source: https://docs.applivery.com/en/api/uem/network-status/get-network-statuses/ Description: **Required Permission:** `mdm.global.networkStatus.list` Get list of mdmNetworkStatus ## Get list of mdmNetworkStatus **Required Permission:** `mdm.global.networkStatus.list` Get list of mdmNetworkStatus _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Delete mdmPackageTime Source: https://docs.applivery.com/en/api/uem/package-times/delete-package-time/ Description: **Required Permission:** `mdm.global.packageTime.remove` Delete mdmPackageTime ## Delete mdmPackageTime **Required Permission:** `mdm.global.packageTime.remove` Delete mdmPackageTime _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get mdmPackageTime by ID Source: https://docs.applivery.com/en/api/uem/package-times/get-package-time/ Description: **Required Permission:** `mdm.global.packageTime.get` Get mdmPackageTime by ID ## Get mdmPackageTime by ID **Required Permission:** `mdm.global.packageTime.get` Get mdmPackageTime by ID _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list of mdmPackageTime Source: https://docs.applivery.com/en/api/uem/package-times/get-package-times/ Description: **Required Permission:** `mdm.global.packageTime.list` Get list of mdmPackageTime ## Get list of mdmPackageTime **Required Permission:** `mdm.global.packageTime.list` Get list of mdmPackageTime _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Delete mdmPackageTransfer Source: https://docs.applivery.com/en/api/uem/package-transfers/delete-package-transfer/ Description: **Required Permission:** `mdm.global.packageTransfer.remove` Delete mdmPackageTransfer ## Delete mdmPackageTransfer **Required Permission:** `mdm.global.packageTransfer.remove` Delete mdmPackageTransfer _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get mdmPackageTransfer by ID Source: https://docs.applivery.com/en/api/uem/package-transfers/get-package-transfer/ Description: **Required Permission:** `mdm.global.packageTransfer.get` Get mdmPackageTransfer by ID ## Get mdmPackageTransfer by ID **Required Permission:** `mdm.global.packageTransfer.get` Get mdmPackageTransfer by ID _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list of mdmPackageTransfer Source: https://docs.applivery.com/en/api/uem/package-transfers/get-package-transfers/ Description: **Required Permission:** `mdm.global.packageTransfer.list` Get list of mdmPackageTransfer ## Get list of mdmPackageTransfer **Required Permission:** `mdm.global.packageTransfer.list` Get list of mdmPackageTransfer _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## List device management policies Source: https://docs.applivery.com/en/api/uem/policies/get-policies/ Description: **Required Permission:** `mdm.global.policy.list` Returns a paginated list of policies from Android, Apple, and Windows platforms accessible within the organization context. ## List device management policies **Required Permission:** `mdm.global.policy.list` Returns a paginated list of policies from Android, Apple, and Windows platforms accessible within the organization context. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Retrieve a paginated list of mdmPolicySync records Source: https://docs.applivery.com/en/api/uem/policy-sync/get-policy-sync/ Description: **Required Permission:** `mdm.global.policySync.list` Retrieves a paginated list of MDM policy sync operations ## Retrieve a paginated list of mdmPolicySync records **Required Permission:** `mdm.global.policySync.list` Retrieves a paginated list of MDM policy sync operations _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get mdmPolicyTemplate by id Source: https://docs.applivery.com/en/api/uem/policy-templates/get-mdm-policy-template/ Description: Get mdmPolicyTemplate by id ## Get mdmPolicyTemplate by id Get mdmPolicyTemplate by id _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get Policy Templates Source: https://docs.applivery.com/en/api/uem/policy-templates/get-mdm-policy-templates/ Description: Get Policy Templates ## Get Policy Templates Get Policy Templates _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update mdmSmartAttribute by it"s id Source: https://docs.applivery.com/en/api/uem/policy-templates/put-smart-attributes/ Description: Update mdmSmartAttribute by it"s id ## Update mdmSmartAttribute by it"s id Update mdmSmartAttribute by it"s id _[ApiSecurity schema — see canonical URL]_ No parameters. _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Send push notification Source: https://docs.applivery.com/en/api/uem/push-notifications/post-send/ Description: **Required Permission:** `mdm.global.pushNotification.send` Send push notification ## Send push notification **Required Permission:** `mdm.global.pushNotification.send` Send push notification _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get mdm status Source: https://docs.applivery.com/en/api/uem/status/get-mdm/ Description: **Required Permission:** `mdm.global.status.get` Get mdm status ## Get mdm status **Required Permission:** `mdm.global.status.get` Get mdm status _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Remove MDM user account Source: https://docs.applivery.com/en/api/uem/users/delete-user/ Description: **Required Permission:** `mdm.global.mdmUser.remove` Remove device management user account permanently from organization if no active devices or pending enrollment tokens are associated. ## Remove MDM user account **Required Permission:** `mdm.global.mdmUser.remove` Remove device management user account permanently from organization if no active devices or pending enrollment tokens are associated. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Download sample CSV template Source: https://docs.applivery.com/en/api/uem/users/get-csv-sample/ Description: **Required Permission:** `mdm.global.mdmUser.list` Download template CSV file demonstrating correct format and required fields for bulk importing device management users into system. ## Download sample CSV template **Required Permission:** `mdm.global.mdmUser.list` Download template CSV file demonstrating correct format and required fields for bulk importing device management users into system. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Retrieve single MDM user details Source: https://docs.applivery.com/en/api/uem/users/get-user/ Description: **Required Permission:** `mdm.global.mdmUser.get` Retrieve complete details for a specific device management user including device counts, enrollment status, and metadata information. ## Retrieve single MDM user details **Required Permission:** `mdm.global.mdmUser.get` Retrieve complete details for a specific device management user including device counts, enrollment status, and metadata information. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Retrieve paginated list of MDM users Source: https://docs.applivery.com/en/api/uem/users/get-users/ Description: **Required Permission:** `mdm.global.mdmUser.list` Retrieve paginated list of device management users within the organization with filtering options for search and tag criteria. ## Retrieve paginated list of MDM users **Required Permission:** `mdm.global.mdmUser.list` Retrieve paginated list of device management users within the organization with filtering options for search and tag criteria. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Create new MDM user account Source: https://docs.applivery.com/en/api/uem/users/post-user/ Description: **Required Permission:** `mdm.global.mdmUser.create` Create new device management user account with contact information, tags, and language preferences for enrollment and device assignments. ## Create new MDM user account **Required Permission:** `mdm.global.mdmUser.create` Create new device management user account with contact information, tags, and language preferences for enrollment and device assignments. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update existing MDM user Source: https://docs.applivery.com/en/api/uem/users/put-user/ Description: **Required Permission:** `mdm.global.mdmUser.update` Update device management user information including name, tags, language preference, and custom metadata while preserving email address. ## Update existing MDM user **Required Permission:** `mdm.global.mdmUser.update` Update device management user information including name, tags, language preference, and custom metadata while preserving email address. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Delete winAdmxConfig Source: https://docs.applivery.com/en/api/windows/admx-configs/delete-admx-config/ Description: **Required Permission:** `mdm.windows.admxConfig.remove` Delete winAdmxConfig ## Delete winAdmxConfig **Required Permission:** `mdm.windows.admxConfig.remove` Delete winAdmxConfig _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get winAdmxConfig by Id or Slug Source: https://docs.applivery.com/en/api/windows/admx-configs/get-admx-config/ Description: **Required Permission:** `mdm.windows.admxConfig.get` Get winAdmxConfig by Id or Slug ## Get winAdmxConfig by Id or Slug **Required Permission:** `mdm.windows.admxConfig.get` Get winAdmxConfig by Id or Slug _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list of winAdmxConfig Source: https://docs.applivery.com/en/api/windows/admx-configs/get-admx-configs/ Description: **Required Permission:** `mdm.windows.admxConfig.list` Get list of winAdmxConfig ## Get list of winAdmxConfig **Required Permission:** `mdm.windows.admxConfig.list` Get list of winAdmxConfig _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Check winAdmxConfig assignation Source: https://docs.applivery.com/en/api/windows/admx-configs/get-assignations/ Description: **Required Permission:** `mdm.windows.admxConfig.get` Check winAdmxConfig assignation ## Check winAdmxConfig assignation **Required Permission:** `mdm.windows.admxConfig.get` Check winAdmxConfig assignation _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Regenerate settings from winAdmxConfig by Id or Slug Source: https://docs.applivery.com/en/api/windows/admx-configs/get-regenerate/ Description: **Required Permission:** `mdm.windows.admxConfig.regenerate` Regenerate settings from winAdmxConfig by Id or Slug ## Regenerate settings from winAdmxConfig by Id or Slug **Required Permission:** `mdm.windows.admxConfig.regenerate` Regenerate settings from winAdmxConfig by Id or Slug _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Create winAdmxConfig Source: https://docs.applivery.com/en/api/windows/admx-configs/post-admx-config/ Description: **Required Permission:** `mdm.windows.admxConfig.create` Create winAdmxConfig ## Create winAdmxConfig **Required Permission:** `mdm.windows.admxConfig.create` Create winAdmxConfig _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Remove Windows application configuration Source: https://docs.applivery.com/en/api/windows/applications/delete-application/ Description: **Required Permission:** `mdm.windows.application.remove` Remove Windows application configuration permanently from organization preventing further deployments to devices and cleaning up deployment references. ## Remove Windows application configuration **Required Permission:** `mdm.windows.application.remove` Remove Windows application configuration permanently from organization preventing further deployments to devices and cleaning up deployment references. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Retrieve single Windows application details Source: https://docs.applivery.com/en/api/windows/applications/get-application/ Description: **Required Permission:** `mdm.windows.application.get` Retrieve complete details for specific Windows application including configuration, source information, and deployment settings for device management. ## Retrieve single Windows application details **Required Permission:** `mdm.windows.application.get` Retrieve complete details for specific Windows application including configuration, source information, and deployment settings for device management. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Retrieve paginated list of Windows applications Source: https://docs.applivery.com/en/api/windows/applications/get-applications/ Description: **Required Permission:** `mdm.windows.application.list` Retrieve paginated list of Windows applications configured for device deployment with filtering options by type, source, and identifier. ## Retrieve paginated list of Windows applications **Required Permission:** `mdm.windows.application.list` Retrieve paginated list of Windows applications configured for device deployment with filtering options by type, source, and identifier. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Search Microsoft Store applications Source: https://docs.applivery.com/en/api/windows/applications/get-search/ Description: **Required Permission:** `mdm.windows.application.search` Search Microsoft Store catalog for available Windows applications by name or keyword filtered by country for deployment configuration. ## Search Microsoft Store applications **Required Permission:** `mdm.windows.application.search` Search Microsoft Store catalog for available Windows applications by name or keyword filtered by country for deployment configuration. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Register new Windows application Source: https://docs.applivery.com/en/api/windows/applications/post-application/ Description: **Required Permission:** `mdm.windows.application.create` Register new Windows application for device deployment by configuring source type and linking to store, build, or asset. ## Register new Windows application **Required Permission:** `mdm.windows.application.create` Register new Windows application for device deployment by configuring source type and linking to store, build, or asset. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update Windows application configuration Source: https://docs.applivery.com/en/api/windows/applications/put-application/ Description: **Required Permission:** `mdm.windows.application.update` Update Windows application configuration modifying source type and linked references for store, build, or asset deployment strategies. ## Update Windows application configuration **Required Permission:** `mdm.windows.application.update` Update Windows application configuration modifying source type and linked references for store, build, or asset deployment strategies. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Retrieve individual command action results Source: https://docs.applivery.com/en/api/windows/commands/get-actions/ Description: **Required Permission:** `mdm.windows.command.get` Retrieve paginated list of individual command actions within batch showing processing status, responses, and error details per operation. ## Retrieve individual command action results **Required Permission:** `mdm.windows.command.get` Retrieve paginated list of individual command actions within batch showing processing status, responses, and error details per operation. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Retrieve command processing details Source: https://docs.applivery.com/en/api/windows/commands/get-command/ Description: **Required Permission:** `mdm.windows.command.get` Retrieve complete processing details for specific command batch including status summary and timestamps for monitoring and troubleshooting. ## Retrieve command processing details **Required Permission:** `mdm.windows.command.get` Retrieve complete processing details for specific command batch including status summary and timestamps for monitoring and troubleshooting. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Retrieve device command history Source: https://docs.applivery.com/en/api/windows/commands/get-commands/ Description: **Required Permission:** `mdm.windows.command.list` Retrieve list of issued configuration commands for specific Windows device showing processing status and summary of operations. ## Retrieve device command history **Required Permission:** `mdm.windows.command.list` Retrieve list of issued configuration commands for specific Windows device showing processing status and summary of operations. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Cancel pending command processing Source: https://docs.applivery.com/en/api/windows/commands/post-cancel/ Description: **Required Permission:** `mdm.windows.command.cancel` Cancel pending command in batch preventing further processing on device and marking operation as canceled for audit tracking. ## Cancel pending command processing **Required Permission:** `mdm.windows.command.cancel` Cancel pending command in batch preventing further processing on device and marking operation as canceled for audit tracking. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Send configuration commands to device Source: https://docs.applivery.com/en/api/windows/commands/post-command/ Description: **Required Permission:** `mdm.windows.command.create` Send one or more configuration commands to Windows device enabling policy enforcement, settings modification, and registry operations. ## Send configuration commands to device **Required Permission:** `mdm.windows.command.create` Send one or more configuration commands to Windows device enabling policy enforcement, settings modification, and registry operations. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Delete winDepProfile Source: https://docs.applivery.com/en/api/windows/default-config/delete-default-config-by-id/ Description: **Required Permission:** `mdm.windows.defaultDeviceConfig.remove` Delete winDepProfile ## Delete winDepProfile **Required Permission:** `mdm.windows.defaultDeviceConfig.remove` Delete winDepProfile _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get defaultDeviceConfig by Id Source: https://docs.applivery.com/en/api/windows/default-config/get-default-config-by-id/ Description: **Required Permission:** `mdm.windows.defaultDeviceConfig.get` Get defaultDeviceConfig by Id ## Get defaultDeviceConfig by Id **Required Permission:** `mdm.windows.defaultDeviceConfig.get` Get defaultDeviceConfig by Id _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list of default device configs Source: https://docs.applivery.com/en/api/windows/default-config/get-default-config/ Description: **Required Permission:** `mdm.windows.defaultDeviceConfig.list` Get list of default device configs ## Get list of default device configs **Required Permission:** `mdm.windows.defaultDeviceConfig.list` Get list of default device configs _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Create default device config Source: https://docs.applivery.com/en/api/windows/default-config/post-default-config/ Description: **Required Permission:** `mdm.windows.defaultDeviceConfig.create` Create default device config ## Create default device config **Required Permission:** `mdm.windows.defaultDeviceConfig.create` Create default device config _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update winDepProfile Source: https://docs.applivery.com/en/api/windows/default-config/put-default-config-by-id/ Description: **Required Permission:** `mdm.windows.defaultDeviceConfig.update` Update winDepProfile ## Update winDepProfile **Required Permission:** `mdm.windows.defaultDeviceConfig.update` Update winDepProfile _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## List installed application management history. Source: https://docs.applivery.com/en/api/windows/devices/applications/get-history/ Description: **Required Permission:** `mdm.windows.device.get` Retrieves chronological management events per application including install commands and status reports with device-reported data. ## List installed application management history. **Required Permission:** `mdm.windows.device.get` Retrieves chronological management events per application including install commands and status reports with device-reported data. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## List installed applications on a Windows device. Source: https://docs.applivery.com/en/api/windows/devices/applications/get/ Description: **Required Permission:** `mdm.windows.device.get` Retrieves a complete inventory of applications installed on the device, including version details and installation dates for compliance analysis, purposes. ## List installed applications on a Windows device. **Required Permission:** `mdm.windows.device.get` Retrieves a complete inventory of applications installed on the device, including version details and installation dates for compliance analysis, purposes. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Remove Windows device from MDM system. Source: https://docs.applivery.com/en/api/windows/devices/delete-device/ Description: **Required Permission:** `mdm.windows.device.remove` Marks the device as deleted in the system, revoking access and preventing future management or communication with platform servers completely. ## Remove Windows device from MDM system. **Required Permission:** `mdm.windows.device.remove` Marks the device as deleted in the system, revoking access and preventing future management or communication with platform servers completely. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Retrieve agent configuration assets and certificates. Source: https://docs.applivery.com/en/api/windows/devices/get-agent-config-assets/ Description: **Required Permission:** `mdm.windows.device.get` Provides access to necessary configuration files and certificates required by the agent to establish secure communication with platform servers successfully. ## Retrieve agent configuration assets and certificates. **Required Permission:** `mdm.windows.device.get` Provides access to necessary configuration files and certificates required by the agent to establish secure communication with platform servers successfully. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Retrieve MDM agent configuration settings. Source: https://docs.applivery.com/en/api/windows/devices/get-agent-config/ Description: **Required Permission:** `mdm.windows.device.get` Fetches current configuration settings for the device agent including server endpoints, polling intervals, and operational parameters for effective management, purposes. ## Retrieve MDM agent configuration settings. **Required Permission:** `mdm.windows.device.get` Fetches current configuration settings for the device agent including server endpoints, polling intervals, and operational parameters for effective management, purposes. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Retrieve device agent authentication tokens. Source: https://docs.applivery.com/en/api/windows/devices/get-agent-tokens/ Description: **Required Permission:** `mdm.windows.device.get` Fetches current authentication credentials and tokens used by the device agent to maintain secure connectivity with management services communication endpoints. ## Retrieve device agent authentication tokens. **Required Permission:** `mdm.windows.device.get` Fetches current authentication credentials and tokens used by the device agent to maintain secure connectivity with management services communication endpoints. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Retrieve detailed Windows device configuration and status. Source: https://docs.applivery.com/en/api/windows/devices/get-device/ Description: **Required Permission:** `mdm.windows.device.get` Retrieves comprehensive details for a specific Windows device including operating system information, enrollment status, applied policies, and compliance state metrics. ## Retrieve detailed Windows device configuration and status. **Required Permission:** `mdm.windows.device.get` Retrieves comprehensive details for a specific Windows device including operating system information, enrollment status, applied policies, and compliance state metrics. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## List enrolled Windows devices with filtering options. Source: https://docs.applivery.com/en/api/windows/devices/get-devices/ Description: **Required Permission:** `mdm.windows.device.list` Retrieves a comprehensive list of enrolled Windows devices including status, configuration, and assignments with specific options for filtering and pagination. ## List enrolled Windows devices with filtering options. **Required Permission:** `mdm.windows.device.list` Retrieves a comprehensive list of enrolled Windows devices including status, configuration, and assignments with specific options for filtering and pagination. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## List scheduled automation scripts for device. Source: https://docs.applivery.com/en/api/windows/devices/get-scheduler-scripts/ Description: **Required Permission:** `mdm.windows.device.get` Retrieves details of scripts configured to run periodically on the device, including execution schedules and parameter configuration settings definitions list. ## List scheduled automation scripts for device. **Required Permission:** `mdm.windows.device.get` Retrieves details of scripts configured to run periodically on the device, including execution schedules and parameter configuration settings definitions list. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Execute remote application management actions. Source: https://docs.applivery.com/en/api/windows/devices/post-action/ Description: **Required Permission:** `mdm.windows.device.action` Sends a remote command to the device to install or uninstall specific applications from the organization's software catalog, inventory list. ## Execute remote application management actions. **Required Permission:** `mdm.windows.device.action` Sends a remote command to the device to install or uninstall specific applications from the organization's software catalog, inventory list. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Clear device cache and force refresh. Source: https://docs.applivery.com/en/api/windows/devices/post-clean-cache/ Description: **Required Permission:** `mdm.windows.device.cleanCache` Triggers a process to clear server-side cache and requests a full update of device details from the agent immediately afterwards. ## Clear device cache and force refresh. **Required Permission:** `mdm.windows.device.cleanCache` Triggers a process to clear server-side cache and requests a full update of device details from the agent immediately afterwards. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Request selective device information refresh. Source: https://docs.applivery.com/en/api/windows/devices/post-info/ Description: **Required Permission:** `mdm.windows.device.info` Commands the device to update specific data categories such as hardware or applications without performing a full synchronization cycle, execution. ## Request selective device information refresh. **Required Permission:** `mdm.windows.device.info` Commands the device to update specific data categories such as hardware or applications without performing a full synchronization cycle, execution. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update Windows device configuration and assignments. Source: https://docs.applivery.com/en/api/windows/devices/put-device/ Description: **Required Permission:** `mdm.windows.device.update` Modifies the device properties including display names, tags, and policy assignments to maintain accurate inventory and apply security configurations consistently. ## Update Windows device configuration and assignments. **Required Permission:** `mdm.windows.device.update` Modifies the device properties including display names, tags, and policy assignments to maintain accurate inventory and apply security configurations consistently. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Move winDevice to segment Source: https://docs.applivery.com/en/api/windows/devices/put-move/ Description: **Required Permission:** `mdm.windows.device.move` Move winDevice to segment ## Move winDevice to segment **Required Permission:** `mdm.windows.device.move` Move winDevice to segment _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get mdmScriptLog by Id Source: https://docs.applivery.com/en/api/windows/devices/script-logs/get-script-log/ Description: **Required Permission:** `mdm.windows.deviceScriptLog.get` Get mdmScriptLog by Id ## Get mdmScriptLog by Id **Required Permission:** `mdm.windows.deviceScriptLog.get` Get mdmScriptLog by Id _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list of winDeviceScriptLog Source: https://docs.applivery.com/en/api/windows/devices/script-logs/get-script-logs/ Description: **Required Permission:** `mdm.windows.deviceScriptLog.list` Get list of winDeviceScriptLog ## Get list of winDeviceScriptLog **Required Permission:** `mdm.windows.deviceScriptLog.list` Get list of winDeviceScriptLog _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list of winDeviceScriptLog Source: https://docs.applivery.com/en/api/windows/devices/script-logs/get-summary/ Description: **Required Permission:** `mdm.windows.deviceScriptLog.list` Get list of winDeviceScriptLog ## Get list of winDeviceScriptLog **Required Permission:** `mdm.windows.deviceScriptLog.list` Get list of winDeviceScriptLog _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Invalidate script (once) Source: https://docs.applivery.com/en/api/windows/devices/script-logs/post-invalidate-once/ Description: **Required Permission:** `mdm.windows.deviceScriptLog.invalidate` Invalidate script (once) ## Invalidate script (once) **Required Permission:** `mdm.windows.deviceScriptLog.invalidate` Invalidate script (once) _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Invalidate script Source: https://docs.applivery.com/en/api/windows/devices/script-logs/post-invalidate/ Description: **Required Permission:** `mdm.windows.deviceScriptLog.invalidate` Invalidate script ## Invalidate script **Required Permission:** `mdm.windows.deviceScriptLog.invalidate` Invalidate script _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Delete winDirectProvisioning Source: https://docs.applivery.com/en/api/windows/direct-provisionings/delete-direct-provisioning/ Description: **Required Permission:** `mdm.windows.directProvisioning.remove` Delete winDirectProvisioning ## Delete winDirectProvisioning **Required Permission:** `mdm.windows.directProvisioning.remove` Delete winDirectProvisioning _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get winDirectProvisioning by Id Source: https://docs.applivery.com/en/api/windows/direct-provisionings/get-direct-provisioning/ Description: **Required Permission:** `mdm.windows.directProvisioning.get` Get winDirectProvisioning by Id ## Get winDirectProvisioning by Id **Required Permission:** `mdm.windows.directProvisioning.get` Get winDirectProvisioning by Id _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Get list of winDirectProvisioning Source: https://docs.applivery.com/en/api/windows/direct-provisionings/get-direct-provisionings/ Description: **Required Permission:** `mdm.windows.directProvisioning.list` Get list of winDirectProvisioning ## Get list of winDirectProvisioning **Required Permission:** `mdm.windows.directProvisioning.list` Get list of winDirectProvisioning _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Add new winDirectProvisioning Source: https://docs.applivery.com/en/api/windows/direct-provisionings/post-direct-provisioning/ Description: **Required Permission:** `mdm.windows.directProvisioning.create` Add new winDirectProvisioning ## Add new winDirectProvisioning **Required Permission:** `mdm.windows.directProvisioning.create` Add new winDirectProvisioning _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update winDirectProvisioning Source: https://docs.applivery.com/en/api/windows/direct-provisionings/put-direct-provisioning/ Description: **Required Permission:** `mdm.windows.directProvisioning.update` Update winDirectProvisioning ## Update winDirectProvisioning **Required Permission:** `mdm.windows.directProvisioning.update` Update winDirectProvisioning _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Remove Windows enrollment template Source: https://docs.applivery.com/en/api/windows/enrollment-templates/delete-enrollment-template/ Description: **Required Permission:** `mdm.windows.enrollmentTemplate.remove` Permanently delete Windows enrollment template from organization configuration. Does not affect devices already enrolled using this template, only prevents future usage. ## Remove Windows enrollment template **Required Permission:** `mdm.windows.enrollmentTemplate.remove` Permanently delete Windows enrollment template from organization configuration. Does not affect devices already enrolled using this template, only prevents future usage. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Retrieve Windows enrollment template Source: https://docs.applivery.com/en/api/windows/enrollment-templates/get-enrollment-template/ Description: **Required Permission:** `mdm.windows.enrollmentTemplate.get` Fetch complete Windows enrollment template details including authentication configuration, auto-enrollment rules, auxiliary fields, and Microsoft Entra ID integration settings. ## Retrieve Windows enrollment template **Required Permission:** `mdm.windows.enrollmentTemplate.get` Fetch complete Windows enrollment template details including authentication configuration, auto-enrollment rules, auxiliary fields, and Microsoft Entra ID integration settings. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## List Windows enrollment templates Source: https://docs.applivery.com/en/api/windows/enrollment-templates/get-enrollment-templates/ Description: **Required Permission:** `mdm.windows.enrollmentTemplate.list` Retrieve paginated list of Windows enrollment templates configured for your organization, with optional filtering by template name for management. ## List Windows enrollment templates **Required Permission:** `mdm.windows.enrollmentTemplate.list` Retrieve paginated list of Windows enrollment templates configured for your organization, with optional filtering by template name for management. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Create Windows enrollment template Source: https://docs.applivery.com/en/api/windows/enrollment-templates/post-enrollment-template/ Description: **Required Permission:** `mdm.windows.enrollmentTemplate.create` Create new Windows enrollment template defining device registration workflow with authentication requirements, auto-enrollment rules, and policy assignment for onboarding. ## Create Windows enrollment template **Required Permission:** `mdm.windows.enrollmentTemplate.create` Create new Windows enrollment template defining device registration workflow with authentication requirements, auto-enrollment rules, and policy assignment for onboarding. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Modify Windows enrollment template Source: https://docs.applivery.com/en/api/windows/enrollment-templates/put-enrollment-template/ Description: **Required Permission:** `mdm.windows.enrollmentTemplate.update` Update existing Windows enrollment template configuration including name, rules, authentication providers, auxiliary fields, and Entra ID integration. Affects future enrollments only. ## Modify Windows enrollment template **Required Permission:** `mdm.windows.enrollmentTemplate.update` Update existing Windows enrollment template configuration including name, rules, authentication providers, auxiliary fields, and Entra ID integration. Affects future enrollments only. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Remove enrollment token Source: https://docs.applivery.com/en/api/windows/enrollment-tokens/delete-enrollment-token/ Description: **Required Permission:** `mdm.windows.enrollmentToken.remove` Permanently revoke an enrollment token, preventing any future device registrations using this credential and invalidating any undelivered enrollment links or codes. ## Remove enrollment token **Required Permission:** `mdm.windows.enrollmentToken.remove` Permanently revoke an enrollment token, preventing any future device registrations using this credential and invalidating any undelivered enrollment links or codes. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Retrieve enrollment token details Source: https://docs.applivery.com/en/api/windows/enrollment-tokens/get-enrollment-token/ Description: **Required Permission:** `mdm.windows.enrollmentToken.get` Fetch complete information for a specific enrollment token including current status, assigned user, policy configuration, expiration date, and enrollment link details. ## Retrieve enrollment token details **Required Permission:** `mdm.windows.enrollmentToken.get` Fetch complete information for a specific enrollment token including current status, assigned user, policy configuration, expiration date, and enrollment link details. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## List all Windows enrollment tokens Source: https://docs.applivery.com/en/api/windows/enrollment-tokens/get-enrollment-tokens/ Description: **Required Permission:** `mdm.windows.enrollmentToken.list` Retrieve paginated collection of enrollment tokens with optional filtering by assigned user, policy, or deletion status for organization management. ## List all Windows enrollment tokens **Required Permission:** `mdm.windows.enrollmentToken.list` Retrieve paginated collection of enrollment tokens with optional filtering by assigned user, policy, or deletion status for organization management. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Create enrollment tokens for multiple users Source: https://docs.applivery.com/en/api/windows/enrollment-tokens/post-bulk/ Description: **Required Permission:** `mdm.windows.enrollmentToken.create` Generate enrollment credentials for multiple users simultaneously, distributing personalized enrollment links and instructions to each specified email address with shared policy settings. ## Create enrollment tokens for multiple users **Required Permission:** `mdm.windows.enrollmentToken.create` Generate enrollment credentials for multiple users simultaneously, distributing personalized enrollment links and instructions to each specified email address with shared policy settings. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Create enrollment token for single user Source: https://docs.applivery.com/en/api/windows/enrollment-tokens/post-enrollment-token/ Description: **Required Permission:** `mdm.windows.enrollmentToken.create` Generate a new enrollment credential assigned to a specific user, optionally sending enrollment instructions via email with custom messaging and policy configuration. ## Create enrollment token for single user **Required Permission:** `mdm.windows.enrollmentToken.create` Generate a new enrollment credential assigned to a specific user, optionally sending enrollment instructions via email with custom messaging and policy configuration. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update enrollment token configuration Source: https://docs.applivery.com/en/api/windows/enrollment-tokens/put-enrollment-token/ Description: **Required Permission:** `mdm.windows.enrollmentToken.update` Modify the display name, assigned security policies, or organizational tags for an existing enrollment token before it is used for device registration. ## Update enrollment token configuration **Required Permission:** `mdm.windows.enrollmentToken.update` Modify the display name, assigned security policies, or organizational tags for an existing enrollment token before it is used for device registration. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Retrieve Windows enterprise configuration Source: https://docs.applivery.com/en/api/windows/enterprise/get-enterprise/ Description: **Required Permission:** `mdm.windows.enterprise.get` Retrieve current Windows device management enterprise configuration including domain settings and branding customization for organizational enrollment. ## Retrieve Windows enterprise configuration **Required Permission:** `mdm.windows.enterprise.get` Retrieve current Windows device management enterprise configuration including domain settings and branding customization for organizational enrollment. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Initialize Windows enterprise configuration Source: https://docs.applivery.com/en/api/windows/enterprise/post-enterprise/ Description: **Required Permission:** `mdm.windows.enterprise.create` Initialize Windows device management enterprise configuration with domain settings and branding customization for organizational enrollment processes. ## Initialize Windows enterprise configuration **Required Permission:** `mdm.windows.enterprise.create` Initialize Windows device management enterprise configuration with domain settings and branding customization for organizational enrollment processes. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update Windows enterprise configuration Source: https://docs.applivery.com/en/api/windows/enterprise/put-enterprise/ Description: **Required Permission:** `mdm.windows.enterprise.update` Update Windows device management enterprise configuration modifying domain settings and branding customization while regenerating enrollment certificates if needed. ## Update Windows enterprise configuration **Required Permission:** `mdm.windows.enterprise.update` Update Windows device management enterprise configuration modifying domain settings and branding customization while regenerating enrollment certificates if needed. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Remove Windows policy configuration Source: https://docs.applivery.com/en/api/windows/policies/delete-policy/ Description: **Required Permission:** `mdm.windows.policy.remove` Remove Windows policy permanently from organization if not currently assigned to any devices or groups for cleanup. ## Remove Windows policy configuration **Required Permission:** `mdm.windows.policy.remove` Remove Windows policy permanently from organization if not currently assigned to any devices or groups for cleanup. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Check policy assignment status Source: https://docs.applivery.com/en/api/windows/policies/get-assignations/ Description: **Required Permission:** `mdm.windows.policy.get` Check if Windows policy is currently assigned to any devices or groups providing deployment status for deletion validation. ## Check policy assignment status **Required Permission:** `mdm.windows.policy.get` Check if Windows policy is currently assigned to any devices or groups providing deployment status for deletion validation. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Retrieve default policy configuration template Source: https://docs.applivery.com/en/api/windows/policies/get-default/ Description: **Required Permission:** `mdm.windows.policy.default` Retrieve default configuration template for Windows policies providing baseline settings and recommended values for new policy creation. ## Retrieve default policy configuration template **Required Permission:** `mdm.windows.policy.default` Retrieve default configuration template for Windows policies providing baseline settings and recommended values for new policy creation. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Retrieve paginated list of Windows policies Source: https://docs.applivery.com/en/api/windows/policies/get-policies/ Description: **Required Permission:** `mdm.windows.policy.list` Retrieve paginated list of Windows device policies configured for organization with filtering options by name and target type. ## Retrieve paginated list of Windows policies **Required Permission:** `mdm.windows.policy.list` Retrieve paginated list of Windows device policies configured for organization with filtering options by name and target type. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Retrieve single Windows policy details Source: https://docs.applivery.com/en/api/windows/policies/get-policy/ Description: **Required Permission:** `mdm.windows.policy.get` Retrieve complete details for specific Windows policy including configurations, application assignments, scripts, and deployment information for management. ## Retrieve single Windows policy details **Required Permission:** `mdm.windows.policy.get` Retrieve complete details for specific Windows policy including configurations, application assignments, scripts, and deployment information for management. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Analyze combined policy composition Source: https://docs.applivery.com/en/api/windows/policies/post-composition/ Description: **Required Permission:** `mdm.windows.policy.composition` Analyze combined effect of multiple Windows policies applied to target detecting conflicts and showing final configuration state. ## Analyze combined policy composition **Required Permission:** `mdm.windows.policy.composition` Analyze combined effect of multiple Windows policies applied to target detecting conflicts and showing final configuration state. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Create new Windows policy configuration Source: https://docs.applivery.com/en/api/windows/policies/post-policy/ Description: **Required Permission:** `mdm.windows.policy.create` Create new Windows device policy bundling applications, scripts, configurations, and agent settings for deployment to managed devices. ## Create new Windows policy configuration **Required Permission:** `mdm.windows.policy.create` Create new Windows device policy bundling applications, scripts, configurations, and agent settings for deployment to managed devices. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## Update Windows policy configuration Source: https://docs.applivery.com/en/api/windows/policies/put-policy/ Description: **Required Permission:** `mdm.windows.policy.update` Update Windows policy modifying name, configurations, application assignments, scripts, or agent settings affecting deployed devices on next sync. ## Update Windows policy configuration **Required Permission:** `mdm.windows.policy.update` Update Windows policy modifying name, configurations, application assignments, scripts, or agent settings affecting deployed devices on next sync. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ _[ApiEndpoint schema — see canonical URL]_ --- ## App Distribution Source: https://docs.applivery.com/en/app-distribution/ Description: Explore Applivery's app distribution solution for managing and deploying apps across mobile, desktop, web, and console platforms. Learn more! TL;DR: Applivery's App Distribution provides a centralized solution for managing and deploying applications across multiple platforms, streamlining the entire process. Key topics: App Distribution, Cross-Platform Deployment, Applivery Features, Mobile App Management, Applivery Applivery's App Distribution module gives you everything you need to upload, manage, and distribute applications to your team — from internal enterprise apps and beta testing programs to production releases through the Enterprise Store. It supports iOS, Android, macOS, Windows, and custom platforms, covering the full delivery lifecycle from the first upload to the final user install. --- ## API Source: https://docs.applivery.com/en/app-distribution/api/ Description: App Distribution API reference: upload Builds, manage Publications, retrieve details, handle download tokens, and manage files. TL;DR: The App Distribution API allows developers to programmatically manage builds and publications, enabling automation of app distribution workflows. Key topics: Build Upload API, Publication Management API, Download Token Handling, File Management API, API, Builds, Publications The Applivery API lets you interact programmatically with Builds and Publications, enabling you to integrate app distribution into your own tools and automation pipelines. Authentication is handled via Service Accounts. Use the API to upload, update, query, and remove Builds and Publications. --- ## App API Token Source: https://docs.applivery.com/en/app-distribution/api/app-api-token/ Description: Create, use, and manage Applivery API tokens for secure integration with CI/CD pipelines and other services. TL;DR: Use Applivery API tokens to securely integrate your apps with CI/CD pipelines and other services by creating, managing, and securely storing these per-app Bearer tokens. Key topics: API token creation, API token usage, API token revocation, API token security, Best practices for API token management, Applivery, Bitrise, Fastlane, Azure DevOps, API, Bearer token The Applivery Apps API (Integrations API) uses **Bearer token authentication**. To interact with the API programmatically — whether to upload Builds, query build details, integrate with a CI/CD pipeline, or embed the Applivery SDK in your App — you need an **App API Token** scoped to the specific App you want to work with. Each App in Applivery can have multiple tokens, which makes it easy to issue separate credentials for different integrations (e.g., one token for Bitrise, another for Fastlane, another for a local script) and revoke them independently without affecting other workflows. * * * ### How App API Tokens Work - Tokens are **per-app** — a token created for one App cannot be used to access a different app. - Each App can have **multiple tokens** simultaneously, with no enforced limit. - Tokens are **Bearer tokens** — they must be included in the `Authorization` header of every API request. - Tokens do **not expire** automatically. They remain valid until explicitly deleted. - Deleting a token **immediately and permanently** invalidates it. There is no way to restore a deleted token. * * * ### Creating an App API Token **Open the App Settings** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), select the App you want to generate a token for. Navigate to the **Settings** tab, then select **API Tokens** from the left-hand menu. **Create the token** Click **\+ Create API token**. Enter a descriptive name that clearly identifies the integration or system that will use this token — for example: - `Bitrise CI` - `Fastlane release` - `Azure DevOps pipeline` - `Local upload script` A meaningful name makes it much easier to identify and revoke the right token later, especially when managing multiple integrations. ![create api token](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/251bb37e-a2e0-467d-b4e2-e42710d7c113.png) Click **Save**. The token will appear in the list. **Copy the token** Click the copy icon next to the newly created token to copy the Bearer token string to your clipboard. :::warning Store the token securely. Treat it like a password — do not commit it to version control, embed it in client-side code, or share it in plain text. Use environment variables or a secrets manager in your CI/CD pipeline to inject the token at runtime. ::: * * * ### Using the Token in API Requests Include the token in the `Authorization` header of every request using the `Bearer` scheme: ``` Authorization: Bearer YOUR_APP_TOKEN ``` **Example — uploading a Build with curl:** ```bash curl -X POST https://upload.applivery.io/v1/integrations/builds \ -H "Authorization: Bearer YOUR_APP_TOKEN" \ -F "file=@/path/to/your/app.ipa" ``` **Example — listing Builds:** ```bash curl -X GET https://api.applivery.io/v1/integrations/builds/ \ -H "Authorization: Bearer YOUR_APP_TOKEN" ``` For the full list of available endpoints and request parameters, see the [API Reference](https://docs.applivery.com/en/app-distribution/api/). * * * ### Revoking a Token You can revoke a token at any time by deleting it. This immediately invalidates the token — any system or integration using it will stop working instantly. :::danger Deleting a token is permanent and cannot be undone. Once deleted, the token cannot be restored. Any integration relying on it must be updated with a new token before it can function again. ::: To delete a token: 1. Go to **Settings > API Tokens** for the relevant app. 2. Click the **three vertical dots** next to the token you want to remove, then select **Delete** from the menu. 3. Confirm the action when prompted. * * * ### Best Practices - **One token per integration.** Issue a separate token for each system or pipeline that needs API access. This means you can revoke a single integration's access without disrupting others. - **Use descriptive names.** Name tokens after the system or workflow that uses them (`Fastlane release`, `Bitrise staging`) so you can immediately identify what a token is used for when you need to revoke it. - **Store tokens as secrets.** Never hardcode tokens in source code or configuration files committed to version control. Use your CI/CD platform's secrets management (e.g. Bitrise Secrets, GitHub Actions Secrets, Azure Key Vault) to inject tokens at runtime. - **Rotate tokens periodically.** Even though tokens do not expire automatically, it is good practice to rotate them periodically — especially after team member changes or security incidents. Create the new token, update your integrations, then delete the old one. - **Audit your token list regularly.** Remove tokens that are no longer in use to reduce your attack surface. If you are unsure whether a token is still active, create a replacement, migrate the integration, and then delete the old one. --- ## Builds Source: https://docs.applivery.com/en/app-distribution/api/builds/ Description: Programmatically manage application Builds via the Applivery API. Upload, retrieve, update, and delete Builds with ease. TL;DR: Manage your application builds programmatically using our API for full control over the build lifecycle. Key topics: API, Build Management, Automation The Builds API gives you full programmatic control over the Build lifecycle — uploading new Builds, retrieving lists and details, updating metadata, generating download tokens, and attaching additional files. Use these endpoints to integrate Build management into your CI/CD pipeline or internal tooling. --- ## Attach Files to Build Source: https://docs.applivery.com/en/app-distribution/api/builds/attached-files/ Description: Attach supplementary files (dSYMs, test reports, release notes) to Applivery Builds using the Integrations or Workspace API. TL;DR: Attach supplementary files to Applivery builds using the Integrations API (per-app) or the Workspace API (workspace-level). Key topics: Attaching files to builds, Integrations API, Workspace API, API authentication, API endpoints, Applivery, App API Token, Service Account, dSYM files, CI/CD pipelines Attaches one or more supplementary files to an existing build. This is useful for associating additional assets with a Build — such as release notes documents, test reports, dSYM files for crash symbolication, mapping files, screenshots, or any other file you want to make available alongside the Build in Applivery. Attached files are separate from the Build binary itself and do not affect the Build's installation or processing. They are displayed in the Build's detail view in the Applivery Dashboard and are accessible via the API. :::info The Build must have a `status` of `processed` before files can be attached. Attempting to attach files to a Build that is still `pending` or `in_progress` will return a `400` error. ::: Applivery provides two separate APIs for attaching files, each requiring a different authentication credential. --- ### Choosing the right API | | Integrations API | Workspace API | |---|---|---| | **Designed for** | CI/CD pipelines attaching artifacts per-app | Workspace-level automation across multiple Apps | | **Authentication** | App API Token (per-app) | Service Account token (Workspace-level) | | **Base URL** | `https://upload.applivery.io` | `https://upload.applivery.io` | | **App context** | Implicit — token is already scoped to an App | Explicit — `organizationId` and `applicationId` required in the path | | **Typical users** | CI scripts attaching test reports or dSYM files after a Build | Platform engineers managing build artifacts across multiple Apps | :::warning Access to the different APIs might not be available in your current plan. Please check availability on our [pricing page](https://www.applivery.com/app-distribution-pricing/). ::: --- ### Integrations API Use this endpoint when attaching files within the scope of a single app. Authentication uses an **App API Token**, scoped to the specific App. To create an App API Token, see [Apps API Authentication](https://docs.applivery.com/en/app-distribution/api/app-api-token/). #### Endpoint ``` POST https://upload.applivery.io/v1/integrations/builds/{buildId}/files ``` #### Authentication ``` Authorization: Bearer ``` #### Request format `multipart/form-data` #### Path parameters | Parameter | Type | Required | Description | |---|---|---|---| | `buildId` | String | Yes | The unique identifier of the Build to attach the file to. E.g. `552ae3cfcb5abfc58d733b81`. Returned by [POST – Upload a Build](https://docs.applivery.com/en/app-distribution/api/builds/upload-build/) and [GET – List of Builds](https://docs.applivery.com/en/app-distribution/api/builds/list-builds/). | #### Body parameters | Parameter | Type | Required | Description | |---|---|---|---| | `file` | File | Yes | The file to attach to the Build. Any file type is accepted. | | `description` | String | No | A human-readable description of the attached file. E.g. `dSYM file for crash symbolication`, `QA test report`, `Release notes PDF`. | #### Example Request ```bash curl 'https://upload.applivery.io/v1/integrations/builds/552ae3cfcb5abfc58d733b81/files' \ -X POST \ -H 'Authorization: Bearer YOUR_APP_TOKEN' \ -F 'file=@/path/to/report.zip' \ -F 'description=Automated test report' ``` #### Responses **✓ 200 OK** File attached successfully. The response returns the full updated build object, including the `files` array, which now contains the newly attached file. ```json { "status": true, "data": { "id": "string", "status": "processed", "tags": ["string"], "versionName": "string", "application": "string", "applicationInfo": { "id": "string", "name": "string", "slug": "string", "picture": "string" }, "changelog": "string", "info": {}, "size": 0, "processTime": 0, "queuedTime": 0, "versionCode": "string", "error": "string", "errorCode": "string", "os": "ios", "buildPlatform": "string", "deployer": {}, "uploadedBy": {}, "originalExtension": "string", "storageProvider": {}, "files": [ { "id": "string", "type": "string", "description": "string", "file": { "originalName": "string", "mimetype": "string", "size": 0, "bucket": "string", "key": "string", "location": "string", "region": "string", "storageProviderId": "string", "checksum": "string", "updatedAt": "string", "createdAt": "string" } } ], "hasEmmJson": true, "updatedAt": "string", "createdAt": "string" } } ``` **✗ 400 Bad Request** Build not yet processed. Files can only be attached to Builds with `status: processed`. Retry after the Build finishes processing. ```json { "status": false, "error": { "code": 5014, "message": "Build Not Processed" } } ``` **✗ 401 Unauthorized** ```json { "status": false, "error": { "code": 3002, "message": "Token Expired" } } ``` **✗ 404 Not Found** ```json { "status": false, "error": { "code": 3001, "message": "Entity not found" } } ``` #### Key fields in the `files` array | Field | Description | |---|---| | `id` | Unique identifier of the attached file record. | | `description` | The description provided at upload time. | | `file.originalName` | The original filename of the uploaded file. | | `file.mimetype` | The detected MIME type of the file. | | `file.size` | File size in bytes. | | `file.location` | The storage URL where the file is hosted. | | `file.checksum` | Checksum for integrity verification. | --- ### Workspace API Use this endpoint when attaching files at the Workspace level — for example, in automation pipelines that operate across multiple Apps using a single credential. Authentication uses a **Service Account** token, which is Workspace-scoped and not tied to any individual app. To create a Service Account, see [Service Accounts](https://docs.applivery.com/en/platform/api/service-accounts/). #### Endpoint ``` POST https://upload.applivery.io/v1/organizations/{organizationId}/apps/{applicationId}/builds/{buildId}/files ``` #### Path parameters | Parameter | Type | Required | Description | |---|---|---|---| | `organizationId` | String | Yes | The unique identifier of your Applivery organization. | | `applicationId` | String | Yes | The unique identifier of the App the Build belongs to. | | `buildId` | String | Yes | The unique identifier of the Build to attach the file to. | #### Authentication ``` Authorization: Bearer ``` #### Example Request ```bash curl 'https://upload.applivery.io/v1/organizations/ORG_ID/apps/APP_ID/builds/BUILD_ID/files' \ -X POST \ -H 'Authorization: Bearer YOUR_SERVICE_ACCOUNT_TOKEN' \ -F 'file=@/path/to/mapping.txt' \ -F 'description=ProGuard mapping file' ``` The response schema is identical to the Integrations API. --- ### Common use cases | File type | Example `description` | |---|---| | iOS dSYM archive | `dSYM file for crash symbolication` | | Android ProGuard mapping | `ProGuard mapping file` | | Automated test report | `XCTest results — regression suite` | | QA sign-off document | `QA approval — v2.4.0` | | Release notes PDF | `Release notes for stakeholders` | | Screenshot set | `App Store screenshots — en-US` | --- ## Build Details Source: https://docs.applivery.com/en/app-distribution/api/builds/build-details/ Description: Retrieve detailed information about your Applivery Builds using the Integrations and Workspace APIs, including endpoints and authentication. TL;DR: Retrieve detailed information about Applivery builds using either the per-app Integrations API or the workspace-level Workspace API, each requiring different authentication methods. Key topics: Applivery API, Build Details, Integrations API, Workspace API, API Authentication, Applivery, App API Token, Service Account Returns the full details of a single build, identified by its `buildId`. This is the primary endpoint for inspecting the processing status, metadata, and platform-specific information of a specific Build — and the recommended endpoint for polling after an upload until the Build reaches a terminal state (`processed` or `error`). Applivery provides two separate APIs for retrieving build details, each requiring a different authentication credential. * * * ### Choosing the Right API | | Integrations API | Workspace API | | --- | --- | --- | | **Designed for** | Per-app integrations, CI/CD pipelines, post-upload status polling | Workspace-level automation across multiple Apps | | **Authentication** | App API Token (per-app) | Service Account token (Workspace-level) | | **App context** | Implicit — token is already scoped to an App | Explicit — `organizationId` and `applicationId` required in the path | | **Typical users** | CI scripts checking if a Build has finished processing | Platform engineers inspecting Builds across multiple Apps | :::warning Access to the different APIs might not be available in your current plan. Please check availability on our [pricing page](https://www.applivery.com/app-distribution-pricing/). ::: * * * ### Integrations API Use this endpoint when retrieving build details within the scope of a single app. Authentication uses an **App API Token**, scoped to the specific App. To create an App API Token, see [Apps API Authentication](https://docs.applivery.com/en/app-distribution/api/app-api-token/). #### Endpoint ``` GET https://api.applivery.io/v1/integrations/builds/{buildId} ``` #### Authentication ``` Authorization: Bearer ``` #### Path Parameters | Parameter | Type | Required | Description | | --- | --- | --- | --- | | `buildId` | String | Yes | The unique identifier of the Build to retrieve. E.g. `552ae3cfcb5abfc58d733b81`. The `buildId` is returned in the response of POST – Upload a Build and GET – List of Builds. | #### Example Request ```bash curl 'https://api.applivery.io/v1/integrations/builds/552ae3cfcb5abfc58d733b81' \ -X GET \ -H 'Authorization: Bearer YOUR_APP_TOKEN' ``` #### Responses **✓ 200 OK** ```json { "status": true, "data": { "id": "string", "status": "processed", "tags": ["string"], "versionName": "string", "application": "string", "applicationInfo": { "id": "string", "name": "string", "slug": "string", "picture": "string" }, "changelog": "string", "info": { "icon": "string", "android": { "targetSdkVersion": "string", "minSDKVersion": "string", "packageName": "string", "platformBuildVersionName": "string", "platformBuildVersionCode": "string", "versionName": "string", "versionCode": "string", "icon": "string" }, "ios": { "plist": { "CFBundleDisplayName": "string", "CFBundleSupportedPlatforms": ["string"], "MinimumOSVersion": "string", "CFBundleIdentifier": "string", "CFBundleShortVersionString": "string", "CFBundleVersion": "string", "CFBundleName": "string", "CFBundleIcons": ["string"], "UIDeviceFamily": ["string"] }, "mobileprovision": { "ExpirationDate": "2019-08-24T14:15:22Z", "TeamIdentifier": "string", "ProvisionsAllDevices": true, "TeamName": "string", "ProvisionedDevices": "string", "signingType": "ad-hoc" } }, "pkg": { "CFBundleDisplayName": "string", "CFBundleIdentifier": "string", "CFBundleShortVersionString": "string", "CFBundleVersion": "string", "CFBundleName": "string" } }, "size": 0, "processTime": 0, "queuedTime": 0, "versionCode": "string", "error": "string", "errorCode": "string", "os": "ios", "deployer": { "name": "string", "info": { "commitMessage": "string", "commit": "string", "branch": "string", "triggerTimestamp": "string", "buildUrl": "string", "ciUrl": "string", "repositoryUrl": "string", "buildNumber": "string", "tag": "string" } }, "uploadedBy": { "id": "string", "email": "user@example.com", "firstName": "string", "lastName": "string", "picture": "string" }, "originalExtension": "string", "storageProvider": { "id": "string", "name": "string", "region": "string" }, "hasEmmJson": true, "updatedAt": "2019-08-24T14:15:22Z", "createdAt": "2019-08-24T14:15:22Z" } } ``` **✗ 400 Bad Request** Build not yet processed. This error is returned when the Build exists but has not yet completed processing. Retry after a short delay. ```json { "status": false, "error": { "code": 5014, "message": "Build Not Processed" } } ``` **✗ 401 Unauthorized** ```json { "status": false, "error": { "code": 3002, "message": "Token Expired" } } ``` **✗ 404 Not Found** ```json { "status": false, "error": { "code": 3001, "message": "Entity not found" } } ``` #### Key response fields | Field | Description | | --- | --- | | `status` | Processing status of the Build: `pending`, `in_progress`, `processed`, or `error`. | | `error` | Human-readable error message, populated only when `status` is `error`. | | `errorCode` | Machine-readable error code for programmatic handling. See Build Processing Codes. | | `info.android` | Extracted Android metadata: package name, version name, version code, SDK targets, and icon. Only present for Android Builds. | | `info.ios.plist` | Extracted iOS `Info.plist` metadata: bundle identifier, version, display name, supported platforms, and device families. Only present for iOS Builds. | | `info.ios.mobileprovision` | iOS provisioning profile details: team, expiration date, signing type, and provisioned Devices. Only present for iOS Builds. | | `info.pkg` | Extracted macOS package metadata. Only present for macOS Builds. | | `deployer` | CI/CD metadata attached at upload time: branch, commit, build number, and platform URLs. | | `size` | Build file size in bytes. | | `processTime` | Time taken to process the Build, in milliseconds. | :::tip After uploading a Build, call this endpoint periodically with the `buildId` returned from the upload response until `status` is `processed` or `error`. A `status` of `pending` or `in_progress` means processing is still ongoing. If the status is `error`, check the `errorCode` field and refer to [Build Processing Codes](https://docs.applivery.com/en/app-distribution/builds/processing-error-codes/) for resolution steps. ::: * * * ### Workspace API Use this endpoint when retrieving build details at the Workspace level — for example, in automation that operates across multiple Apps using a single credential. Authentication uses a **Service Account** token, which is Workspace-scoped and not tied to any individual app. The App and build context are both provided via path parameters. To create a Service Account, see [Service Accounts](https://docs.applivery.com/en/platform/api/service-accounts/). #### Endpoint ``` GET https://api.applivery.io/v1/organizations/{organizationId}/apps/{applicationId}/builds/{buildId} ``` #### Path Parameters | Parameter | Type | Required | Description | | --- | --- | --- | --- | | `organizationId` | String | Yes | The unique identifier of your Applivery organization. | | `applicationId` | String | Yes | The unique identifier of the App the Build belongs to. | | `buildId` | String | Yes | The unique identifier of the Build to retrieve. | #### Authentication ``` Authorization: Bearer ``` #### Example Request ```bash curl 'https://api.applivery.io/v1/organizations/ORG_ID/apps/APP_ID/builds/552ae3cfcb5abfc58d733b81' \ -X GET \ -H 'Authorization: Bearer YOUR_SERVICE_ACCOUNT_TOKEN' ``` The response schema is identical to the Integrations API. --- ## Delete Build Source: https://docs.applivery.com/en/app-distribution/api/builds/delete-build/ Description: Permanently delete Builds from Applivery using the Integrations API or Workspace API. Covers authentication and parameters. TL;DR: Learn how to permanently delete builds from Applivery using either the Integrations API (App API Token) or the Workspace API (Service Account token). Key topics: Deleting builds, Integrations API, Workspace API, API authentication, Error handling, Applivery, App API Token, Service Account, API Permanently deletes a Build from Applivery. This action removes the Build record and its associated file from storage. :::warning This operation is **permanent and irreversible**. Once a Build is deleted, it cannot be recovered. Any Publication pointing exclusively to this Build will no longer be able to serve the App for download. Verify that the Build is not actively used in any Publication before deleting it. ::: Applivery provides two separate APIs for deleting Builds, each requiring a different authentication credential. --- ### Choosing the Right API | | Integrations API | Workspace API | |---|---|---| | **Designed for** | Per-app integrations and CI/CD cleanup pipelines | Workspace-level automation across multiple Apps | | **Authentication** | App API Token (per-app) | Service Account token (Workspace-level) | | **App context** | Implicit — token is already scoped to an App | Explicit — `organizationId` and `applicationId` required in the path | | **Typical users** | CI scripts pruning old or failed Builds automatically | Platform engineers managing build retention across multiple Apps | :::warning Access to the different APIs might not be available in your current plan. Please check availability on our [pricing page](https://www.applivery.com/app-distribution-pricing/). ::: --- ### Integrations API Use this endpoint when deleting Builds within the scope of a single app. Authentication uses an **App API Token**, scoped to the specific App. To create an App API Token, see [Apps API Authentication](https://docs.applivery.com/en/app-distribution/api/app-api-token/). #### Endpoint ``` DELETE https://api.applivery.io/v1/integrations/builds/{buildId} ``` #### Authentication ``` Authorization: Bearer ``` #### Path Parameters | Parameter | Type | Required | Description | |---|---|---|---| | `buildId` | String | Yes | The unique identifier of the Build to delete. E.g. `552ae3cfcb5abfc58d733b81`. The `buildId` is returned in the response of [POST – Upload a Build](https://docs.applivery.com/en/app-distribution/api/builds/upload-build/) and [GET – List of Builds](https://docs.applivery.com/en/app-distribution/api/builds/list-builds/). | #### Example Request ```bash curl 'https://api.applivery.io/v1/integrations/builds/552ae3cfcb5abfc58d733b81' \ -X DELETE \ -H 'Authorization: Bearer YOUR_APP_TOKEN' ``` #### Responses **✓ 200 OK** ```json { "status": true, "data": { "deleted": true } } ``` **✗ 400 Bad Request** Build not yet processed. Builds that are still in a `pending` or `in_progress` state cannot be deleted. Wait for processing to complete before attempting to delete. ```json { "status": false, "error": { "code": 5014, "message": "Build Not Processed" } } ``` **✗ 401 Unauthorized** ```json { "status": false, "error": { "code": 3002, "message": "Token Expired" } } ``` **✗ 404 Not Found** ```json { "status": false, "error": { "code": 3001, "message": "Entity not found" } } ``` --- ### Workspace API Use this endpoint when deleting Builds at the Workspace level — for example, in automated build retention pipelines that operate across multiple Apps using a single credential. Authentication uses a **Service Account** token, which is Workspace-scoped and not tied to any individual app. The App and build context are both provided via path parameters. To create a Service Account, see [Service Accounts](https://docs.applivery.com/en/platform/api/service-accounts/). #### Endpoint ``` DELETE https://api.applivery.io/v1/organizations/{organizationId}/apps/{applicationId}/builds/{buildId} ``` #### Path Parameters | Parameter | Type | Required | Description | |---|---|---|---| | `organizationId` | String | Yes | The unique identifier of your Applivery organization. | | `applicationId` | String | Yes | The unique identifier of the App the Build belongs to. | | `buildId` | String | Yes | The unique identifier of the Build to delete. | #### Authentication ``` Authorization: Bearer ``` #### Example Request ```bash curl 'https://api.applivery.io/v1/organizations/ORG_ID/apps/APP_ID/builds/552ae3cfcb5abfc58d733b81' \ -X DELETE \ -H 'Authorization: Bearer YOUR_SERVICE_ACCOUNT_TOKEN' ``` The response schema is identical to the Integrations API. A successful deletion returns `{ "status": true, "data": { "deleted": true } }`. --- ## Download Attached File Source: https://docs.applivery.com/en/app-distribution/api/builds/download-attached-file/ Description: Programmatically download attached files from Builds via the API. Generate a download token scoped to a specific attachment and resolve its download URL. Downloading an attached file from a Build programmatically uses the same **two-step process** as downloading a Build binary: generate a short-lived download token, then use it to resolve the actual download URL. The key difference is that you must include the `fileId` query parameter to specify which attachment you want to download. :::warning This endpoint is **only available through the Workspace API** and requires a **Service Account token** or a user session token obtained at login. The Integrations API (App API Token) does not support this endpoint. ::: To create a Service Account, see [Service Accounts](https://docs.applivery.com/en/platform/api/service-accounts/). * * * ### Overview: Download flow ``` Step 1: Generate a download token for the attached file GET /v1/organizations/{organizationId}/apps/{applicationId}/builds/{buildId}/downloadToken?fileId={fileId}&type=auto → returns { token, expiresAt } Step 2: Resolve the download URL GET https://download-api.applivery.io/v1/download/{token} → HTTP 302 redirect to the actual file URL ``` * * * ### Before you start: Find the fileId The `fileId` is the `id` of the attachment entry in the build's `files` array, where `type` equals `attachment`. You can retrieve it from the [Build Details](https://docs.applivery.com/en/app-distribution/api/builds/build-details/) endpoint. In the response, look for entries in the `files` array with `"type": "attachment"`: ```json { "files": [ { "id": "2SWkDbddHBNUaVImZINcZzVN", "type": "attachment", "file": { "originalName": "screenshot.png", "mimetype": "image/png", "size": 538300, "location": "https://storage.cloud.google.com/...", "checksum": "b531c0eb..." }, "createdAt": "2024-11-11T11:27:35.446Z", "updatedAt": "2024-11-11T11:27:35.446Z" } ] } ``` The `id` field (`2SWkDbddHBNUaVImZINcZzVN` in this example) is the `fileId` you need for Step 1. :::info Other entries in the `files` array (with `type: "package"`, `type: "icon"`, or `type: "original"`) are internal build files, not user-uploaded attachments. Only entries with `type: "attachment"` are files you attached via the [POST – Build Attached Files](https://docs.applivery.com/en/app-distribution/api/builds/attached-files/) endpoint. ::: * * * **Generate a Download Token** Generates a short-lived, single-use token that authorizes the download of a specific attached file. **Endpoint** ``` GET https://api.applivery.io/v1/organizations/{organizationId}/apps/{applicationId}/builds/{buildId}/downloadToken ``` **Authentication** ``` Authorization: Bearer ``` **Path parameters** | Parameter | Type | Required | Description | | --- | --- | --- | --- | | `organizationId` | String | Yes | The unique identifier (or slug) of your Applivery organization. | | `applicationId` | String | Yes | The unique identifier of the App the Build belongs to. | | `buildId` | String | Yes | The unique identifier of the Build containing the attachment. | **Query parameters** | Parameter | Type | Required | Description | | --- | --- | --- | --- | | `fileId` | String | Yes | The `id` of the attachment entry in the build's `files` array (where `type` is `attachment`). | | `type` | String | Yes | Set to `auto` for attached file downloads. | **Example Request** ```bash curl 'https://api.applivery.io/v1/organizations/ORG_ID/apps/APP_ID/builds/BUILD_ID/downloadToken?fileId=FILE_ID&type=auto' \ -X GET \ -H 'Accept: application/json' \ -H 'Authorization: Bearer YOUR_SERVICE_ACCOUNT_TOKEN' ``` **Responses** **✓ 200 OK** ```json { "status": true, "data": { "token": "string", "expiresAt": "string" } } ``` **✗ 400 Bad Request** Build not yet processed. The Build exists but has not finished processing. Only Builds with `status: processed` can have download tokens generated. ```json { "status": false, "error": { "code": 5014, "message": "Build Not Processed" } } ``` **✗ 401 Unauthorized** ```json { "status": false, "error": { "code": 4002, "message": "No auth token" } } ``` **✗ 404 Not Found** ```json { "status": false, "error": { "code": 3001, "message": "Entity not found" } } ``` | Field | Description | | --- | --- | | `token` | The download token string. Pass this as the path parameter to Step 2 to resolve the download URL. | | `expiresAt` | ISO 8601 timestamp indicating when the token expires. Tokens are short-lived — use them promptly after generation. | **Resolve the Download URL** Uses the token obtained in Step 1 to get the actual file download URL. The API responds with an HTTP `302 Found` redirect to the file's storage location. :::warning **No authentication required**. This endpoint is public — the token itself acts as the credential. Anyone with the token can download the file, so treat tokens as sensitive and do not share them beyond the intended recipient. ::: **Endpoint** ``` GET https://download-api.applivery.io/v1/download/{token} ``` **Path parameters** | Parameter | Type | Required | Description | | --- | --- | --- | --- | | `token` | String | Yes | The download token returned in Step 1. | **Example Request** ```bash curl -L 'https://download-api.applivery.io/v1/download/YOUR_DOWNLOAD_TOKEN' \ -o downloaded_file.png ``` :::info The `-L` flag instructs curl to follow the `302` redirect automatically. Without it, you will receive the redirect response with the `Location` header containing the actual file URL, but the file will not be downloaded. ::: **Responses** **✓ 302 Found** Redirect to the file URL. The response does not have a body. The actual download URL is in the `Location` response header. Follow the redirect to download the file. **✗ 401 Unauthorized** Token expired. Download tokens are short-lived. If the token has expired, generate a new one from Step 1. ```json { "status": false, "error": { "code": 4005, "message": "Token Expired" } } ``` **✗ 404 Not Found** ```json { "status": false, "error": { "code": 3001, "message": "Entity not found" } } ``` * * * ### Complete example: Download an attached file ```bash ## Step 1: Generate the download token for the attached file TOKEN=$(curl -s \ 'https://api.applivery.io/v1/organizations/ORG_ID/apps/APP_ID/builds/BUILD_ID/downloadToken?fileId=FILE_ID&type=auto' \ -H 'Authorization: Bearer YOUR_SERVICE_ACCOUNT_TOKEN' \ | jq -r '.data.token') ## Step 2: Download the file, following the redirect curl -L \ "https://download-api.applivery.io/v1/download/$TOKEN" \ -o downloaded_file ``` --- ## Download Token & URL Source: https://docs.applivery.com/en/app-distribution/api/builds/download-token-url-build/ Description: Programmatically download Builds from Applivery via the API. Generate download tokens and resolve download URLs for .apk, .ipa, and .aab files. TL;DR: Download Applivery builds programmatically by generating a short-lived download token with a Service Account and then resolving the download URL. Key topics: Download Token Generation, Download URL Resolution, Service Account Authentication, API Endpoints, Error Handling, Applivery, API, Service Account, apk, ipa, aab, curl, JSON Downloading a Build programmatically requires a **two-step process**: first, generate a short-lived download token, then use that token to resolve the actual download URL. The download URL is served via a redirect response. :::warning Unlike the other build endpoints, the download token endpoint is **only available through the Workspace API** and requires a **Service Account token** or a user session token obtained at login. The Integrations API (App API Token) does not support this endpoint. ::: To create a Service Account, see [Service Accounts](https://docs.applivery.com/en/platform/api/service-accounts/). * * * ### Overview: Download flow ``` Step 1: Generate a download token GET /v1/organizations/{organizationId}/apps/{applicationId}/builds/{buildId}/downloadToken → returns { token, expiresAt } Step 2: Resolve the download URL GET https://download-api.applivery.io/v1/download/{token} → HTTP 302 redirect to the actual file URL ``` * * * **Generate a Download Token** Generates a short-lived, single-use token that authorizes the download of a specific Build file. **Endpoint** ``` GET https://api.applivery.io/v1/organizations/{organizationId}/apps/{applicationId}/builds/{buildId}/downloadToken ``` **Authentication** ``` Authorization: Bearer ``` **Path parameters** | Parameter | Type | Required | Description | | --- | --- | --- | --- | | `organizationId` | String | Yes | The unique identifier (or slug) of your Applivery organization. | | `applicationId` | String | Yes | The unique identifier of the App the Build belongs to. | | `buildId` | String | Yes | The unique identifier of the Build you want to download. Returned by POST – Upload a Build and GET – List of Builds. | **Query parameters** | Parameter | Type | Required | Description | | --- | --- | --- | --- | | `type` | String | Yes | Specifies which file format to generate the download token for. See values below. | `type` **values** | Value | Description | | --- | --- | | `auto` | Default behavior. Returns a `.apk` for Android Builds, or the manifest (`.plist`) for Apple Builds. This is the standard option for in-app installation flows. | | `file` | Returns the raw binary file. For Apple Builds, this is the `.ipa` or `.pkg` file instead of the manifest. Use this when you need the actual file rather than an OTA install link. | | `aab` | For Android Builds originally uploaded as an `.aab`, this returns the original `.aab` file instead of the Universal `.apk` that Applivery generates from it. | **Example Request** ```bash curl 'https://api.applivery.io/v1/organizations/MY_ORG_SLUG/apps/MY_APP_ID/builds/MY_BUILD_ID/downloadToken?type=file' \ -X GET \ -H 'Accept: application/json' \ -H 'Authorization: Bearer YOUR_SERVICE_ACCOUNT_TOKEN' ``` **Responses** **✓ 200 OK** ```json { "status": true, "data": { "token": "string", "expiresAt": "string" } } ``` **✗ 400 Bad Request** Build not yet processed. The Build exists but has not finished processing. Only Builds with `status: processed` can have download tokens generated. ```json { "status": false, "error": { "code": 5014, "message": "Build Not Processed" } } ``` **✗ 401 Unauthorized** ```json { "status": false, "error": { "code": 4002, "message": "No auth token" } } ``` **✗ 404 Not Found** ```json { "status": false, "error": { "code": 3001, "message": "Entity not found" } } ``` | Field | Description | | --- | --- | | `token` | The download token string. Pass this as the path parameter to Step 2 to resolve the download URL. | | `expiresAt` | ISO 8601 timestamp indicating when the token expires. Tokens are short-lived — use them promptly after generation. | **Resolve the Download URL** Uses the token obtained in Step 1 to get the actual file download URL. The API responds with an HTTP `302 Found` redirect to the file's storage location. :::warning **No authentication required**. This endpoint is public — the token itself acts as the credential. Anyone with the token can download the file, so treat tokens as sensitive and do not share them beyond the intended recipient. ::: **Endpoint** ``` GET https://download-api.applivery.io/v1/download/{token} ``` **Path parameters** | Parameter | Type | Required | Description | | --- | --- | --- | --- | | `token` | String | Yes | The download token returned in Step 1. | **Example Request** ```bash curl -L 'https://download-api.applivery.io/v1/download/YOUR_DOWNLOAD_TOKEN' \ -o downloaded_build.ipa ``` :::info The `-L` flag instructs curl to follow the `302` redirect automatically. Without it, you will receive the redirect response with the `Location` header containing the actual file URL, but no file will be downloaded. ::: **Redirect behavior by platform** The URL in the `Location` redirect header varies depending on the platform and the `type` parameter used in Step 1: | Platform | `type` value | Redirect target | | --- | --- | --- | | **Android** | `auto` | Universal `.apk` file | | **Android** | `aab` | Original `.aab` file | | **Apple** | `auto` | OTA manifest (`.plist`) — for in-app installation via MDM or direct install link | | **Apple** | `file` | Raw binary — `.ipa` for iOS, `.pkg` for macOS | **Responses** **✓ 302 Found** Redirect to the file URL. The response does not have a body. The actual download URL is in the `Location` response header. Follow the redirect to download the file. **✗ 401 Unauthorized** Token expired. Download tokens are short-lived. If the token has expired, generate a new one from Step 1. ```json { "status": false, "error": { "code": 4005, "message": "Token Expired" } } ``` **✗ 404 Not Found** ```json { "status": false, "error": { "code": 3001, "message": "Entity not found" } } ``` * * * ### Complete example: Download a Build file ```bash ## Step 1: Generate the download token TOKEN=$(curl -s \ 'https://api.applivery.io/v1/organizations/MY_ORG/apps/MY_APP/builds/MY_BUILD/downloadToken?type=file' \ -H 'Authorization: Bearer YOUR_SERVICE_ACCOUNT_TOKEN' \ | jq -r '.data.token') ## Step 2: Download the file, following the redirect curl -L \ "https://download-api.applivery.io/v1/download/$TOKEN" \ -o my_build.ipa ``` --- ## List Builds Source: https://docs.applivery.com/en/app-distribution/api/builds/list-builds/ Description: List App Builds using the Applivery API. Covers both the Integrations and Workspace APIs for querying Build history and status. TL;DR: Learn how to list app builds using Applivery's Integrations or Workspace API with appropriate authentication and query parameters. Key topics: Integrations API, Workspace API, API Authentication, Query Parameters, Build Status, Applivery, API, App API Token, Service Account, iOS, Android Returns a paginated list of Builds for a given App. This is useful for querying build history, checking processing status after an upload, or building dashboards and automation scripts that act on specific Builds. Applivery provides two separate APIs for listing Builds, each requiring a different authentication credential. --- ### Choosing the right API | | Integrations API | Workspace API | |---|---|---| | **Designed for** | Per-app integrations, CI/CD pipelines, build tools | Workspace-level automation across multiple Apps | | **Authentication** | App API Token (per-app) | Service Account token (Workspace-level) | | **Base URL** | `https://api.applivery.io` | `https://api.applivery.io` | | **App context** | Implicit — token is already scoped to an App | Explicit — `organizationId` and `applicationId` required in the path | | **Typical users** | Scripts checking build status, post-upload polling | Platform engineers querying Builds across multiple Apps | :::warning Access to the different APIs might not be available in your current plan. Please check availability on our [pricing page](https://www.applivery.com/app-distribution-pricing/). ::: --- ### Integrations API Use this endpoint when querying Builds within the scope of a single app. Authentication uses an **App API Token**, which is scoped to the specific App. To create an App API Token, see [Apps API Authentication](https://docs.applivery.com/en/app-distribution/api/app-api-token/). #### Endpoint ``` GET https://api.applivery.io/v1/integrations/builds ``` #### Authentication ``` Authorization: Bearer ``` #### Query Parameters All parameters are optional. When no filters are applied, the endpoint returns all Builds for the App associated with the token, ordered by creation date descending. | Parameter | Type | Description | |---|---|---| | `versionName` | String | Filter by human-readable version name. E.g., `RC-1`, `v2.4.0-beta`. | | `status` | String | Filter by build processing status. Allowed values: `pending`, `in_progress`, `processed`, `error`. | | `os` | String | Filter by operating system. Allowed values: `ios`, `android`. | | `page` | Integer | Page number for pagination. Starts at `1`. | | `limit` | Integer | Maximum number of Builds to return per page. | #### Example Request ```bash curl 'https://api.applivery.io/v1/integrations/builds?status=processed&os=ios&page=1&limit=20' \ -X GET \ -H 'Authorization: Bearer YOUR_APP_TOKEN' ``` #### Responses **✓ 200 OK** ```json { "status": true, "data": { "items": [ { "id": "string", "status": "processed", "tags": ["string"], "versionName": "string", "application": "string", "applicationInfo": { "id": "string", "name": "string", "slug": "string", "picture": "string" }, "changelog": "string", "info": { "icon": "string", "android": { "targetSdkVersion": "string", "minSDKVersion": "string", "packageName": "string", "platformBuildVersionName": "string", "platformBuildVersionCode": "string", "versionName": "string", "versionCode": "string", "icon": "string" }, "ios": { "plist": { "CFBundleDisplayName": "string", "CFBundleSupportedPlatforms": ["string"], "MinimumOSVersion": "string", "CFBundleIdentifier": "string", "CFBundleShortVersionString": "string", "CFBundleVersion": "string", "CFBundleName": "string", "CFBundleIcons": ["string"], "UIDeviceFamily": ["string"] }, "mobileprovision": { "ExpirationDate": "2019-08-24T14:15:22Z", "TeamIdentifier": "string", "ProvisionsAllDevices": true, "TeamName": "string", "ProvisionedDevices": "string", "signingType": "ad-hoc" } }, "pkg": { "CFBundleDisplayName": "string", "CFBundleIdentifier": "string", "CFBundleShortVersionString": "string", "CFBundleVersion": "string", "CFBundleName": "string" } }, "size": 0, "processTime": 0, "queuedTime": 0, "versionCode": "string", "error": "string", "errorCode": "string", "os": "ios", "deployer": { "name": "string", "info": { "commitMessage": "string", "commit": "string", "branch": "string", "triggerTimestamp": "string", "buildUrl": "string", "ciUrl": "string", "repositoryUrl": "string", "buildNumber": "string", "tag": "string" } }, "uploadedBy": { "id": "string", "email": "user@example.com", "firstName": "string", "lastName": "string", "picture": "string" }, "originalExtension": "string", "storageProvider": { "id": "string", "name": "string", "region": "string" }, "hasEmmJson": true, "updatedAt": "2019-08-24T14:15:22Z", "createdAt": "2019-08-24T14:15:22Z" } ] } } ``` **✗ 401 Unauthorized** ```json { "status": false, "error": { "code": 4002, "message": "No auth token" } } ``` **✗ 404 Not Found** ```json { "status": false, "error": { "code": 3001, "message": "Entity not found" } } ``` :::tip Use `status=pending` or `status=in_progress` to poll for Builds that are still being processed after an upload. Once `status` returns `processed`, the Build is ready. If `status` is `error`, check the `error` and `errorCode` fields for details, and refer to [Build Processing Codes](https://docs.applivery.com/en/app-distribution/builds/processing-error-codes/) for resolution steps. ::: --- ### Workspace API Use this endpoint when querying Builds at the Workspace level — for example, in platform engineering workflows where a single credential needs to list Builds across multiple Apps. Authentication uses a **Service Account** token, which is Workspace-scoped and not tied to any individual app. The App context is provided explicitly via path parameters. To create a Service Account, see [Service Accounts](https://docs.applivery.com/en/platform/api/service-accounts/). #### Endpoint ``` GET https://api.applivery.io/v1/organizations/{organizationId}/apps/{applicationId}/builds ``` #### Path Parameters | Parameter | Type | Required | Description | |---|---|---|---| | `organizationId` | String | Yes | The unique identifier of your Applivery organization. | | `applicationId` | String | Yes | The unique identifier of the App whose Builds you want to list. | #### Authentication ``` Authorization: Bearer ``` #### Query Parameters The Workspace API accepts the same query parameters as the Integrations API. #### Example Request ```bash curl 'https://api.applivery.io/v1/organizations/ORG_ID/apps/APP_ID/builds?status=processed&os=android&page=1&limit=10' \ -X GET \ -H 'Authorization: Bearer YOUR_SERVICE_ACCOUNT_TOKEN' ``` --- ## Update Build Source: https://docs.applivery.com/en/app-distribution/api/builds/update-build/ Description: Update the editable metadata of an existing Build in Applivery using the Integrations API or Workspace API — version name, tags, changelog, and more. TL;DR: Update Build metadata in Applivery via the Integrations API (App API Token) or Workspace API (Service Account token). Only the fields you include are updated — the rest are left unchanged. Key topics: Build metadata update, Integrations API, Workspace API, API authentication, Applivery, App API Token, Service Account Updates the editable metadata of an existing Build — version name, tags, changelog, and, for the Workspace API, additional fields like custom metadata, default scripts, and disabled state. The build binary and processing information are not affected. Only include the fields you want to change. Fields not included in the request body retain their current values. Applivery provides two separate APIs for updating Builds, each requiring a different authentication credential. --- ### Choosing the Right API | | Integrations API | Workspace API | |---|---|---| | **Designed for** | Per-app integrations and CI/CD pipelines | Workspace-level automation across multiple Apps | | **Authentication** | App API Token (per-app) | Service Account token (Workspace-level) | | **App context** | Implicit — token is already scoped to an App | Explicit — `organizationId` and `applicationId` required in the path | | **Available fields** | `versionName`, `tags`, `changelog` | All of the above, plus `metadata`, `defaultScripts`, `disabled` | | **Typical users** | CI scripts updating labels and notes after upload | Platform engineers managing build metadata across multiple Apps | :::warning Access to the different APIs might not be available in your current plan. Please check availability on our [pricing page](https://www.applivery.com/app-distribution-pricing/). ::: --- ### Integrations API Use this endpoint to update Build metadata within the scope of a single app. Authentication uses an **App API Token**, scoped to the specific App. To create an App API Token, see [Apps API Authentication](https://docs.applivery.com/en/app-distribution/api/app-api-token/). #### Endpoint ``` PUT https://api.applivery.io/v1/integrations/builds/{buildId} ``` #### Authentication ``` Authorization: Bearer ``` #### Request format `application/json` #### Path Parameters | Parameter | Type | Required | Description | |---|---|---|---| | `buildId` | String | Yes | The unique identifier of the Build to update. E.g. `552ae3cfcb5abfc58d733b81`. Returned by [POST – Upload a Build](https://docs.applivery.com/en/app-distribution/api/builds/upload-build/) and [GET – List of Builds](https://docs.applivery.com/en/app-distribution/api/builds/list-builds/). | #### Parameters | Parameter | Type | Description | |---|---|---| | `versionName` | String | Human-readable version label for this Build. E.g. `RC-2`, `v2.5.0-beta`. | | `tags` | Array | List of tags to categorize the Build. Replaces the existing tags array. E.g. `["staging", "sprint-43"]`. | | `changelog` | String | Release notes or description of changes in this Build. | #### Example Request ```bash curl 'https://api.applivery.io/v1/integrations/builds/552ae3cfcb5abfc58d733b81' \ -X PUT \ -H 'Authorization: Bearer YOUR_APP_TOKEN' \ -H 'Content-Type: application/json' \ -d '{ "versionName": "v2.5.0-rc2", "tags": ["staging", "sprint-43"], "changelog": "Fixed crash on settings screen" }' ``` #### Responses **✓ 200 OK** ```json { "status": true, "data": { "id": "string", "status": "success", "tags": ["string"], "versionName": "string", "application": "string", "applicationInfo": { "id": "string", "name": "string", "slug": "string", "picture": "string" }, "changelog": "string", "os": "ios", "versionCode": "string", "deployer": { "name": "string", "info": { "commitMessage": "string", "commit": "string", "branch": "string", "tag": "string" } }, "uploadedBy": { "id": "string", "email": "user@example.com", "firstName": "string", "lastName": "string" }, "updatedAt": "2019-08-24T14:15:22Z", "createdAt": "2019-08-24T14:15:22Z" } } ``` **✗ 401 Unauthorized** ```json { "status": false, "error": { "code": 3002, "message": "Token Expired" } } ``` **✗ 404 Not Found** ```json { "status": false, "error": { "code": 3001, "message": "Entity not found" } } ``` --- ### Workspace API Use this endpoint when updating Builds at the Workspace level — for example, in platform engineering workflows where a single credential manages metadata across multiple Apps. Authentication uses a **Service Account** token, which is Workspace-scoped and not tied to any individual app. To create a Service Account, see [Service Accounts](https://docs.applivery.com/en/platform/api/service-accounts/). :::info This endpoint requires the `mad.build.management.update` permission on the Service Account. ::: #### Endpoint ``` PUT https://api.applivery.io/v1/organizations/{organizationId}/apps/{applicationId}/builds/{buildId} ``` #### Path Parameters | Parameter | Type | Required | Description | |---|---|---|---| | `organizationId` | String | Yes | The unique identifier of your Applivery organization. | | `applicationId` | String | Yes | The unique identifier of the App the Build belongs to. | | `buildId` | String | Yes | The unique identifier of the Build to update. | #### Authentication ``` Authorization: Bearer ``` #### Request format `application/json` #### Parameters In addition to the `versionName`, `tags`, and `changelog` fields available in the Integrations API, the Workspace API exposes the following fields: | Parameter | Type | Description | |---|---|---| | `metadata` | Object | Custom key-value metadata object for storing additional build information. | | `defaultScripts.preInstall` | String | Script to run before the Build is installed on a device. | | `defaultScripts.postInstall` | String | Script to run after the Build is installed on a device. | | `defaultScripts.audit` | String | Audit script associated with this Build. | | `defaultScripts.enforce` | String | Enforcement script associated with this Build. | | `defaultScripts.runner` | String | Script runner configuration for this Build. | | `disabled` | Boolean | Whether the Build is disabled. Disabled Builds cannot be downloaded. | #### Example Request ```bash curl 'https://api.applivery.io/v1/organizations/ORG_ID/apps/APP_ID/builds/552ae3cfcb5abfc58d733b81' \ -X PUT \ -H 'Authorization: Bearer YOUR_SERVICE_ACCOUNT_TOKEN' \ -H 'Content-Type: application/json' \ -d '{ "versionName": "v2.5.0-rc2", "changelog": "Fixed crash on settings screen", "tags": ["staging", "sprint-43"], "metadata": { "environment": "staging", "team": "mobile" } }' ``` The response schema is identical to the Integrations API. A successful update returns `{ "status": true, "data": { ... } }` with the updated Build object. --- ## Upload Build Source: https://docs.applivery.com/en/app-distribution/api/builds/upload-build/ Description: Applivery offers two APIs for uploading Builds: Integrations API for CI/CD and Workspace API for multi-app management. Choose the right one for your use. TL;DR: Applivery provides two APIs for build uploads: Integrations API for CI/CD using an App API Token, and Workspace API for multi-app management using a Service Account token. Key topics: Integrations API, Workspace API, App API Token, Service Account Token, Build Upload Parameters, Applivery, Fastlane, Bitrise, Jenkins, Azure DevOps Applivery provides **two separate APIs** for uploading Builds, each designed for a different use case and requiring a different authentication credential. It is important to understand which one applies to your workflow before integrating. * * * ### Choosing the right API

Integrations API

Workspace API

Designed for

CI/CD pipelines, build tools, and per-app integrations

Workspace-level automation and multi-app management

Authentication

App API Token (per-app)

Service Account token (Workspace-level)

Base URL

https://upload.applivery.io

https://upload.applivery.io

App context

Implicit — token is already scoped to an App

Explicit — organizationId and applicationId required in the path

Typical users

Fastlane, Bitrise, Jenkins, Azure DevOps, custom CI scripts

Platform engineers managing multiple Apps programmatically

:::warning Access to the different APIs might not be available in your current plan. Please check availability on our [pricing page](https://www.applivery.com/app-distribution-pricing/). ::: * * * ### Integrations API Use this endpoint when uploading Builds from a CI/CD pipeline or any integration that operates within the scope of a single app. Authentication uses an **App API Token**, which is scoped to the specific App you are uploading to. To create an App API Token, see [Apps API Authentication](https://docs.applivery.com/en/app-distribution/api/app-api-token/). #### Endpoint ``` POST https://upload.applivery.io/v1/integrations/builds ``` #### Authentication ``` Authorization: Bearer ``` #### Request format `multipart/form-data` #### Parameters **Build file**

Parameter

Type

Required

Description

build

File

Yes

The Build file to upload. Supported formats: .ipa, .apk, .aab. See Custom Build Platforms for additional supported formats.

buildPlatform

String

Conditional

Required when uploading a Custom Build Platform. Values: ios, android, or a custom platform identifier.

packageName

String

Conditional

Required when the Build file cannot be processed automatically (e.g., custom platforms). The App's unique identifier.

packageVersion

String

Conditional

Required when the Build file cannot be processed automatically. The version string for this Build.

packageIcon

File

Conditional

Required when the Build file cannot be processed automatically. Must be .png or .jpeg.

**Build metadata**

Parameter

Type

Required

Description

versionName

String

No

Human-readable version label for this Build. E.g. RC-1, v2.4.0-beta.

tags

Array

No

Comma-separated list of tags to categorize the Build. E.g. staging, sprint-42, hotfix.

changelog

String

No

Release notes or description of changes in this Build. Supports plain text.

**Notifications**

Parameter

Type

Required

Description

notifyCollaborators

Boolean

No

Whether to send an email notification to app and Workspace Collaborators. Default: false.

notifyEmployees

Boolean

No

Whether to send an email notification to store employees. Default: false.

notifyMessage

String

No

Custom message to include in the notification email. E.g. New Build ready for testing!.

notifyLanguage

String

No

Language for the notification email. Supported values: en, es, fr, de, it, zh, pt, ru.

filter

Nested array

No

Limits notifications to specific employee groups. Supports AND/OR logic. Each inner array is an AND clause; each outer element is an OR clause. E.g. to notify users in group1 AND group2, OR users in group3: [["group1","group2"],["group3"]].

**CI/CD deployer information** These optional fields populate the Build's deployment metadata in the Applivery Dashboard, making it easy to trace a Build back to its CI/CD origin.

Parameter

Type

Description

deployer.name

String

Display name for the CI/CD system. E.g. Jenkins CI, Bitrise, GitHub Actions.

deployer.info.commitMessage

String

Git commit message associated with this Build.

deployer.info.commit

String

Git commit SHA. E.g. f52ace0.

deployer.info.branch

String

Git branch name. E.g. develop, release/2.4.

deployer.info.tag

String

Git tag associated with this Build. E.g. RC-1, v2.4.0.

deployer.info.triggerTimestamp

String

Unix timestamp (ms) of when the CI build was triggered. E.g. 1558359012580.

deployer.info.buildUrl

String

Direct URL to the CI build run.

deployer.info.ciUrl

String

Base URL of the CI platform.

deployer.info.repositoryUrl

String

URL of the version control repository.

deployer.info.buildNumber

String

CI platform's build number. E.g. 173.

#### Example Request ```bash curl 'https://upload.applivery.io/v1/integrations/builds' \ -X POST \ --retry 5 \ --fail \ -H 'Authorization: Bearer YOUR_APP_TOKEN' \ -F 'build=@file.ipa' \ -F 'versionName=v2.4.0-rc1' \ -F 'tags=staging, sprint-42' \ -F 'changelog=Fixed crash on login screen' \ -F 'notifyCollaborators=true' \ -F 'notifyEmployees=false' \ -F 'notifyMessage=New build ready for QA' \ -F 'notifyLanguage=en' \ -F 'filter[0][0]=group1' \ -F 'filter[0][1]=group2' \ -F 'filter[1][0]=group3' \ -F 'deployer.name=GitHub Actions' \ -F 'deployer.info.commitMessage=Fix crash on login' \ -F 'deployer.info.commit=f52ace0' \ -F 'deployer.info.branch=release/2.4' \ -F 'deployer.info.tag=v2.4.0-rc1' \ -F 'deployer.info.triggerTimestamp=1558359012580' \ -F 'deployer.info.buildUrl=https://github.com/myorg/myapp/actions/runs/123' \ -F 'deployer.info.ciUrl=https://github.com/myorg/myapp/actions' \ -F 'deployer.info.repositoryUrl=https://github.com/myorg/myapp' \ -F 'deployer.info.buildNumber=173' ``` #### Responses **✓ 200 OK** ```json { "status": true, "data": { "id": "string", "status": "pending", "tags": ["string"], "versionName": "string", "application": "string", "applicationInfo": { "id": "string", "name": "string", "slug": "string", "picture": "string" }, "changelog": "string", "info": { "icon": "string", "android": { "targetSdkVersion": "string", "minSDKVersion": "string", "packageName": "string", "platformBuildVersionName": "string", "platformBuildVersionCode": "string", "versionName": "string", "versionCode": "string", "icon": "string" }, "ios": { "plist": { "CFBundleDisplayName": "string", "CFBundleSupportedPlatforms": ["string"], "MinimumOSVersion": "string", "CFBundleIdentifier": "string", "CFBundleShortVersionString": "string", "CFBundleVersion": "string", "CFBundleName": "string", "CFBundleIcons": ["string"], "UIDeviceFamily": ["string"] }, "mobileprovision": { "ExpirationDate": "2019-08-24T14:15:22Z", "TeamIdentifier": "string", "ProvisionsAllDevices": true, "TeamName": "string", "ProvisionedDevices": "string", "signingType": "ad-hoc" } }, "pkg": { "CFBundleDisplayName": "string", "CFBundleIdentifier": "string", "CFBundleShortVersionString": "string", "CFBundleVersion": "string", "CFBundleName": "string" } }, "size": 0, "processTime": 0, "queuedTime": 0, "versionCode": "string", "os": "ios", "deployer": { "name": "string", "info": { "commitMessage": "string", "commit": "string", "branch": "string", "triggerTimestamp": "string", "buildUrl": "string", "ciUrl": "string", "repositoryUrl": "string", "buildNumber": "string", "tag": "string" } }, "uploadedBy": { "id": "string", "email": "user@example.com", "firstName": "string", "lastName": "string", "picture": "string" }, "originalExtension": "string", "storageProvider": { "id": "string", "name": "string", "region": "string" }, "updatedAt": "2019-08-24T14:15:22Z", "createdAt": "2019-08-24T14:15:22Z" } } ``` **✗ 400 Bad Request** ```json { "status": false, "error": { "code": 5024, "message": "Slug already used" } } ``` **✗ 401 Unauthorized** ```json { "status": false, "error": { "code": 3002, "message": "Token Expired" } } ``` **✗ 404 Not Found** ```json { "status": false, "error": { "code": 3001, "message": "Entity not found" } } ``` :::info The Build `status` in the response will initially be `pending`. Applivery processes the Build asynchronously — the status will update to `success` or `error` once processing is complete. Use the [GET – Build details](https://docs.applivery.com/en/app-distribution/api/builds/build-details/) endpoint to poll for the final status if needed. ::: For a full list of error codes returned during build processing, see [Build Processing Codes](https://docs.applivery.com/en/app-distribution/builds/processing-error-codes/). * * * ### Workspace API Use this endpoint when you need to upload Builds at the Workspace level — for example, in platform engineering workflows where a single credential manages multiple Apps across an organisation. Authentication uses a **Service Account** token, which is Workspace-scoped and not tied to any individual app. The App context is provided explicitly via path parameters. To create a Service Account, see [Service Accounts](https://docs.applivery.com/en/platform/api/service-accounts/). #### Endpoint ``` POST https://upload.applivery.io/v1/organizations/{organizationId}/apps/{applicationId}/builds ``` #### Path Parameters

Parameter

Type

Required

Description

organizationId

String

Yes

The unique identifier of your Applivery organization.

applicationId

String

Yes

The unique identifier of the App to upload the Build to.

#### Authentication ``` Authorization: Bearer ``` #### Request format `multipart/form-data` #### Parameters The Workspace API accepts the same build file, metadata, notification, and deployer parameters as the Integrations API. #### Example Request ```bash curl 'https://upload.applivery.io/v1/organizations/ORG_ID/apps/APP_ID/builds' \ -X POST \ -H 'Authorization: Bearer YOUR_SERVICE_ACCOUNT_TOKEN' \ -F 'build=@file.apk' \ -F 'versionName=v3.1.0' \ -F 'changelog=Performance improvements' \ -F 'notifyCollaborators=true' \ -F 'deployer.name=Internal Deploy Bot' \ -F 'deployer.info.branch=main' \ -F 'deployer.info.buildNumber=88' ``` --- ## Publications Source: https://docs.applivery.com/en/app-distribution/api/publications/ Description: Programmatically manage app Publications via the Applivery API. List, create, update, and remove Publications with ease. TL;DR: Manage and automate your app distribution process using API endpoints for published applications. Key topics: API endpoints, App distribution, Automation, API The Publications API lets you manage published Apps programmatically — listing, creating, updating, and removing Publications, as well as retrieving their details and configuration. Use these endpoints to automate your release process and integrate Publication management into your existing workflows. --- ## Create Publication Source: https://docs.applivery.com/en/app-distribution/api/publications/create-publication/ Description: Create App Store Publications in Applivery using the Integrations API or Workspace API. Control app distribution and access. TL;DR: Create and manage Applivery App Store publications programmatically using the Integrations or Workspace API to control app distribution and access. Key topics: Applivery Publications, Integrations API, Workspace API, API Authentication, Build Selection Filters, Applivery, App API Token, Service Account token Create a new Publication in the Applivery App Store. A Publication is the distribution configuration that controls how and to whom a specific Build (or set of Builds) of an App is made available — including its URL slug, security mode, visibility, access filters, and branding overrides. For a conceptual overview of Publications and how they relate to Builds, see [How to Distribute Your Apps](https://docs.applivery.com/en/app-distribution/distribute/distribute-apps/). Applivery provides two separate APIs for creating Publications, each requiring a different authentication credential. * * * ### Choosing the right API | | Integrations API | Workspace API | | --- | --- | --- | | **Designed for** | Per-app CI/CD pipelines | Workspace-level automation across multiple Apps | | **Authentication** | App API Token (per-app) | Service Account token (Workspace-level) | | **App context** | Implicit — token is already scoped to an App | Explicit — `organizationId` and `storeId` required in the path | | **Typical users** | Scripts that auto-publish after a Build is uploaded | Platform engineers managing Publications across multiple Apps | :::warning Access to the different APIs might not be available in your current plan. Please check availability on our [pricing page](https://www.applivery.com/app-distribution-pricing/). ::: * * * ### Integrations API Use this endpoint when creating Publications within the scope of a single app. Authentication uses an **App API Token**, scoped to the specific App. To create an App API Token, see [Apps API Authentication](https://docs.applivery.com/en/app-distribution/api/app-api-token/). #### Endpoint ``` POST https://api.applivery.io/v1/integrations/distributions ``` #### Authentication ``` Authorization: Bearer ``` #### Request format `application/json` * * * #### Parameters Parameters are grouped by area of configuration. ##### Required parameters | Parameter | Type | Description | | --- | --- | --- | | `slug` | String | The URL-friendly identifier for this Publication. Must be unique within your Workspace. Used to construct the Publication URL: `yourworkspace.applivery.com/{slug}`. Only lowercase letters, numbers, and hyphens allowed. | | `security` | String | Authentication mode. Allowed values: `public`, `password`, `logged`. See Security modes below. | | `visibility` | String | Publication visibility. Allowed values: `active`, `inactive`, `unlisted`. See Visibility modes below. | | `filter.type` | String | Build selection strategy. Allowed values: `last`, `build`, `Builds`, `gitBranch`, `gitTag`, `tag`. See Filter configuration below. | ##### Build Selection Filter | Parameter | Type | Required | Description | | --- | --- | --- | --- | | `filter.type` | String | Yes | Build selection strategy. See Filter configuration. | | `filter.value` | String | Conditional | Required for `gitBranch`, `gitTag`, and `tag` filter types. The branch name, git tag, or build tag to match. | | `filter.ios` | String | Conditional | Build ID for the iOS build. Required when `filter.type` is `build` and the App has iOS Builds. | | `filter.android` | String | Conditional | Build ID for the Android build. Required when `filter.type` is `build` and the App has Android Builds. | | `filter.macos` | String | Conditional | Build ID for the macOS build. Required when `filter.type` is `build` and the App has macOS Builds. | | `filter.Builds` | Array | Conditional | Required when `filter.type` is `Builds`. Array of objects with `buildPlatform` and `id`. | | `filter.Builds[].buildPlatform` | String | Conditional | Platform identifier. Supported values: `ios`, `macos`, `android`, `ps4`, `ps5`, `switch`, `xbox-one`, `xbox-series`. | | `filter.Builds[].id` | String | Conditional | Build ID for the specified platform. | ##### Access Control | Parameter | Type | Required | Description | | --- | --- | --- | --- | | `password` | String | Conditional | Required when `security` is `password`. The password users must enter to access the Publication. | | `groups` | Array | No | Restricts access to specific User Groups. Supports AND/OR logic. Each inner array is an AND clause; each outer element is an OR clause. E.g. to allow users in group1 AND group2, OR users in group3: `[["group1","group2"],["group3"]]`. Only applies when `security` is `logged`. | | `activateUserAudiences` | Boolean | No | Whether to enable audience-based access for this Publication. | | `userAudienceMap` | Array | No | Array of audience assignments. Each element defines an audience and its notification preference. | | `userAudienceMap[].id` | String | Conditional | ID of the audience to assign to this Publication. | | `userAudienceMap[].notifyNewBuildsProcessed` | Boolean | No | Whether users in this audience should receive notifications when a new Build is processed. | | `allowedCountries` | Array | No | ISO 3166-1 alpha-2 country codes to **allow** access from. If set, only users from these countries can access the Publication. Cannot be combined with `blockedCountries`. | | `blockedCountries` | Array | No | ISO 3166-1 alpha-2 country codes to **block** access from. Cannot be combined with `allowedCountries`. | ##### Build Display Options | Parameter | Type | Required | Description | |---|---|---|---| | `tags` | Array | No | Tags to categorize this Publication. Comma-separated. E.g. `["staging", "sprint-42"]`. | | `showHistory` | Boolean | No | Whether users can browse and install previous Builds of the App. Default: `false`. | | `showDevInfo` | Boolean | No | Whether to display technical build information (git metadata, certificate details, tags) to users. Default: `false`. | | `expirationDate` | String | No | ISO 8601 timestamp after which the Publication becomes unavailable for download. Use to create time-limited distributions, beta programs, or promotional campaigns. E.g. `"2025-12-31T23:59:59Z"`. Once expired, the Publication behaves as if set to `inactive`. | ##### Legal Terms | Parameter | Type | Required | Description | | --- | --- | --- | --- | | `terms.active` | Boolean | No | Whether users must accept legal terms before accessing the Publication. | | `terms.text` | String | Conditional | Required when `terms.active` is `true`. The legal terms text to display. | ##### Branding and App configuration overrides | Parameter | Type | Required | Description | | --- | --- | --- | --- | | `configuration.application.name` | String | No | Overrides the App name displayed in the Publication. | | `configuration.application.description` | String | No | Overrides the App description displayed in the Publication. | | `configuration.branding.logo` | String | No | Overrides the store logo for this Publication. | | `configuration.branding.primaryColor` | String | No | Overrides the primary branding color (hex format). E.g. `#FF5733`. | | `configuration.branding.buttonColor` | String | No | Overrides the button color (hex format). | * * * #### Security modes | Value | Description | | --- | --- | | `public` | No authentication required. Anyone with the Publication URL can access and download. | | `password` | A password (specified in the `password` field) is required to access the Publication. | | `logged` | Users must be logged in with an Applivery account or your Workspace SSO to access the Publication. | #### Visibility modes | Value | Description | | --- | --- | | `active` | The Publication is listed in the App Store and accessible to all authorized users. | | `inactive` | The Publication is not accessible to anyone. | | `unlisted` | The Publication is not listed in the App Store but is accessible to anyone who has the direct URL. | #### Filter configuration | `filter.type` | Description | | --- | --- | | `last` | Always serves the most recently processed build. No additional `filter.value` needed. | | `build` | Serves a specific Build, identified by `filter.ios`, `filter.android`, or `filter.macos`. | | `Builds` | Serves specific Builds per platform, defined in `filter.Builds`. Supports custom platforms. | | `gitBranch` | Serves the latest Build matching the git branch specified in `filter.value`. E.g. `develop`. | | `gitTag` | Serves the Build matching the git tag specified in `filter.value`. E.g. `v2.4.0`. | | `tag` | Serves Builds matching the Applivery build tag specified in `filter.value`. | * * * #### Example Request Minimal Publication — public, always serving the latest Build: ```bash curl 'https://api.applivery.io/v1/integrations/distributions' \ -X POST \ -H 'Authorization: Bearer YOUR_APP_TOKEN' \ -H 'Content-Type: application/json' \ -d '{ "slug": "my-app-staging", "security": "public", "visibility": "active", "filter": { "type": "last" } }' ``` Private Publication with group access control and build history: ```bash curl 'https://api.applivery.io/v1/integrations/distributions' \ -X POST \ -H 'Authorization: Bearer YOUR_APP_TOKEN' \ -H 'Content-Type: application/json' \ -d '{ "slug": "my-app-internal", "security": "logged", "visibility": "active", "filter": { "type": "gitBranch", "value": "develop" }, "groups": [["qa-team", "developers"]], "showHistory": true, "showDevInfo": true, "tags": ["internal", "qa"] }' ``` * * * #### Responses **✓ 200 OK** :::info The `distributionUrl` field in the response contains the full public URL of the created Publication. Share this URL with your users to give them access to the Publication. ::: ```json { "status": true, "data": { "id": "string", "updatedAt": "string", "createdAt": "string", "application": "string", "applicationInfo": { "id": "string", "slug": "string", "name": "string", "picture": "string" }, "slug": "string", "filter": { "type": "last", "value": "string", "ios": "string", "android": "string", "windows": "string", "macos": "string", "builds": [ { "buildPlatform": "string", "id": "string" } ] }, "security": "public", "tags": ["string"], "groups": [["string"]], "visibility": "active", "showHistory": true, "showDevInfo": true, "distributionUrl": "string", "terms": { "active": true, "text": "string" } } } ``` **✗ 400 Bad Request** Slug already in use. ```json { "status": false, "error": { "code": 5024, "message": "Slug already used" } } ``` **✗ 401 Unauthorized** ```json { "status": false, "error": { "code": 4002, "message": "No auth token" } } ``` **✗ 404 Not Found** ```json { "status": false, "error": { "code": 3001, "message": "Entity not found" } } ``` * * * ### Workspace API Use this endpoint when creating Publications at the Workspace level — for example, in platform engineering workflows that operate across multiple Apps using a single credential. Authentication uses a **Service Account** token, which is Workspace-scoped and not tied to any individual app. To create a Service Account, see [Service Accounts](https://docs.applivery.com/en/platform/api/service-accounts/). #### Endpoint ``` POST https://api.applivery.io/v1/organizations/{organizationId}/stores/{storeId}/pubApps ``` #### Path parameters | Parameter | Type | Required | Description | | --- | --- | --- | --- | | `organizationId` | String | Yes | The unique identifier of your Applivery organization. | | `storeId` | String | Yes | The unique identifier of the store (app project) to create the Publication in. | #### Authentication ``` Authorization: Bearer ``` #### Example request ```bash curl 'https://api.applivery.io/v1/organizations/ORG_ID/stores/STORE_ID/pubApps' \ -X POST \ -H 'Authorization: Bearer YOUR_SERVICE_ACCOUNT_TOKEN' \ -H 'Content-Type: application/json' \ -d '{ "slug": "my-app-release", "security": "public", "visibility": "active", "filter": { "type": "last" } }' ``` The request body parameters and response schema are identical to the Integrations API. --- ## Delete Publication Source: https://docs.applivery.com/en/app-distribution/api/publications/delete-publication/ Description: Permanently delete App Store publications using Applivery's Integrations or Workspace APIs. Covers authentication and endpoints. TL;DR: Learn how to permanently delete App Store publications using Applivery's Integrations or Workspace API, understanding the authentication methods and implications. Key topics: API, App Store Publication, Deletion, Authentication, Applivery, App Store, Integrations API, Workspace API, App API Token, Service Account token Permanently delete a Publication from the App Store. This removes the Publication configuration and its URL — users who visit the Publication URL after deletion will no longer be able to access or download the App. :::warning This operation is **permanent and irreversible**. The Publication's URL (`distributionUrl`) will stop working immediately. If you want to temporarily block access without deleting the Publication, consider setting `visibility` to `"inactive"` via [PUT – Update Published Application](https://docs.applivery.com/en/app-distribution/api/publications/update-publication/) instead. ::: :::info Deleting a Publication does **not** delete the Builds associated with it. The underlying Builds remain in Applivery and can still be referenced by other Publications. ::: Applivery provides two separate APIs for deleting Publications, each requiring a different authentication credential. --- ### Choosing the right API | | Integrations API | Workspace API | |---|---|---| | **Designed for** | Per-app integrations and CI/CD pipelines | Workspace-level automation across multiple Apps | | **Authentication** | App API Token (per-app) | Service Account token (Workspace-level) | | **App context** | Implicit — token is already scoped to an App | Explicit — `organizationId`, `storeId`, and `publishedApplicationId` required in the path | | **Typical users** | Scripts that clean up expired or superseded Publications | Platform engineers managing Publication lifecycle across multiple Apps | --- ### Integrations API Use this endpoint when deleting Publications within the scope of a single app. Authentication uses an **App API Token**, scoped to the specific App. To create an App API Token, see [Apps API Authentication](https://docs.applivery.com/en/app-distribution/api/app-api-token/). #### Endpoint ``` DELETE https://api.applivery.io/v1/integrations/distributions/{publishedApplicationId} ``` #### Authentication ``` Authorization: Bearer ``` #### Path Parameters | Parameter | Type | Required | Description | |---|---|---|---| | `publishedApplicationId` | String | Yes | The unique identifier of the Publication to delete. E.g. `552ae3cfcb5abfc58d733b81`. Returned by [POST – Create a Published Application](https://docs.applivery.com/en/app-distribution/api/publications/create-publication/) and [GET – List of Published Applications](https://docs.applivery.com/en/app-distribution/api/publications/list-publications/). | #### Example Request ```bash curl 'https://api.applivery.io/v1/integrations/distributions/552ae3cfcb5abfc58d733b81' \ -X DELETE \ -H 'Authorization: Bearer YOUR_APP_TOKEN' ``` #### Responses **✓ 200 OK** ```json { "status": true, "data": { "delete": "OK" } } ``` **✗ 400 Bad Request** Each App must have at least one Publication. If you attempt to delete the only remaining Publication for an App, the request will be rejected with this error. Create a replacement Publication before deleting the last one, or set its `visibility` to `"inactive"` instead. ```json { "status": false, "error": { "code": 5044, "message": "Can Not Delete Last PubApplication" } } ``` **✗ 401 Unauthorized** ```json { "status": false, "error": { "code": 4002, "message": "No auth token" } } ``` **✗ 404 Not Found** ```json { "status": false, "error": { "code": 3001, "message": "Entity not found" } } ``` --- ### Workspace API Use this endpoint when deleting Publications at the Workspace level — for example, in automation pipelines that manage Publication lifecycle across multiple Apps using a single credential. Authentication uses a **Service Account** token, which is Workspace-scoped and not tied to any individual app. To create a Service Account, see [Service Accounts](https://docs.applivery.com/en/platform/api/service-accounts/). #### Endpoint ``` DELETE https://api.applivery.io/v1/organizations/{organizationId}/stores/{storeId}/pubApps/{publishedApplicationId} ``` #### Path parameters | Parameter | Type | Required | Description | |---|---|---|---| | `organizationId` | String | Yes | The unique identifier of your Applivery organization. | | `storeId` | String | Yes | The unique identifier of the store (app project) the Publication belongs to. | | `publishedApplicationId` | String | Yes | The unique identifier of the Publication to delete. | #### Authentication ``` Authorization: Bearer ``` #### Example Request ```bash curl 'https://api.applivery.io/v1/organizations/ORG_ID/stores/STORE_ID/pubApps/552ae3cfcb5abfc58d733b81' \ -X DELETE \ -H 'Authorization: Bearer YOUR_SERVICE_ACCOUNT_TOKEN' ``` A successful deletion returns `{ "status": true, "data": { "delete": "OK" } }`. The same `5044` constraint applies — the last publication of an App cannot be deleted via the Workspace API either. --- ## List Publications Source: https://docs.applivery.com/en/app-distribution/api/publications/list-publications/ Description: List your Applivery App Publications using the Integrations API or Workspace API. Retrieve Publication IDs and metadata. TL;DR: Learn how to list Applivery application publications using the Integrations API (per-app) or Workspace API (workspace-level) to retrieve publication details. Key topics: Integrations API, Workspace API, API Authentication, Publication Listing, API Parameters, Applivery, App API Token, Service Account, JSON, REST API Return a paginated list of Publications for a given App. Use this endpoint to query the current state of your Publications, retrieve `publishedApplicationId` values needed by other endpoints, or build dashboards and automation scripts that act on specific Publications. Applivery provides two separate APIs for listing Publications, each requiring a different authentication credential. --- ### Choosing the Right API | | Integrations API | Workspace API | |---|---|---| | **Designed for** | Per-app integrations and CI/CD pipelines | Workspace-level automation across multiple Apps | | **Authentication** | App API Token (per-app) | Service Account token (Workspace-level) | | **App context** | Implicit — token is already scoped to an App | Explicit — `organizationId` and `storeId` required in the path | | **Typical users** | Scripts that look up a Publication's ID before updating it | Platform engineers querying Publications across multiple Apps | :::warning Access to the different APIs might not be available in your current plan. Please check availability on our [pricing page](https://www.applivery.com/app-distribution-pricing/). ::: --- ### Integrations API Use this endpoint when listing Publications within the scope of a single app. Authentication uses an **App API Token**, scoped to the specific App. To create an App API Token, see [Apps API Authentication](https://docs.applivery.com/en/app-distribution/api/app-api-token/). #### Endpoint ``` GET https://api.applivery.io/v1/integrations/distributions ``` #### Authentication ``` Authorization: Bearer ``` #### Query parameters All parameters are optional. When no filters are applied, the endpoint returns all Publications for the App associated with the token. | Parameter | Type | Description | |---|---|---| | `slug` | String | Filter by Publication slug. Returns only the Publication matching this exact slug. | | `security` | String | Filter by security mode. Allowed values: `public`, `password`, `logged`. | | `visibility` | String | Filter by visibility state. Allowed values: `active`, `inactive`, `unlisted`. | | `filter-type` | String | Filter by build selection strategy. Allowed values: `last`, `build`, `builds`, `gitBranch`, `gitTag`, `tag`. | | `page` | Integer | Page number for pagination. Starts at `1`. | | `limit` | Integer | Maximum number of Publications to return per page. | #### Example Request ```bash curl 'https://api.applivery.io/v1/integrations/distributions?visibility=active&security=public' \ -X GET \ -H 'Authorization: Bearer YOUR_APP_TOKEN' ``` #### Responses **✓ 200 OK** ```json { "status": true, "data": { "items": [ { "id": "string", "updatedAt": "2025-10-23T07:54:26.518Z", "createdAt": "2024-07-23T08:10:46.471Z", "application": "string", "applicationInfo": { "id": "string", "slug": "string", "name": "string", "picture": "string" }, "slug": "string", "filter": { "type": "last", "value": "string", "ios": "string", "android": "string", "windows": "string", "macos": "string", "builds": [ { "buildPlatform": "string", "id": "string" } ] }, "security": "public", "tags": ["string"], "groups": [["string"]], "activateUserAudiences": false, "userAudienceMap": [], "visibility": "active", "showHistory": false, "showDevInfo": false, "expirationDate": "string", "distributionUrl": "string", "terms": { "active": true, "text": "string" }, "configuration": { "branding": { "logo": "string", "primaryColor": "string", "useAppIcon": false }, "application": { "description": "string", "name": "string" } }, "allowedCountries": [], "blockedCountries": [] } ], "totalDocs": 0, "limit": 0, "hasPrevPage": true, "hasNextPage": true, "page": 0, "totalPages": 0, "pagingCounter": 0, "prevPage": 0, "nextPage": 0 } } ``` **✗ 401 Unauthorized** ```json { "status": false, "error": { "code": 4002, "message": "No auth token" } } ``` **✗ 404 Not Found** ```json { "status": false, "error": { "code": 3001, "message": "Entity not found" } } ``` #### Key response fields | Field | Description | |---|---| | `id` | The unique identifier of the Publication (`publishedApplicationId`). Use this value in [PUT – Update](https://docs.applivery.com/en/app-distribution/api/publications/update-publication/) and [DELETE](https://docs.applivery.com/en/app-distribution/api/publications/delete-publication/) endpoints. | | `slug` | The URL-friendly identifier used to construct the Publication URL. | | `distributionUrl` | The full public URL of the Publication. Share this with users to give them access. | | `security` | Current security mode: `public`, `password`, or `logged`. | | `visibility` | Current visibility state: `active`, `inactive`, or `unlisted`. | | `filter.type` | Build selection strategy currently configured: `last`, `build`, `builds`, `gitBranch`, `gitTag`, or `tag`. | | `expirationDate` | ISO 8601 timestamp after which the Publication becomes unavailable. `null` if no expiration is set. | | `activateUserAudiences` | Whether audience-based access control is enabled for this Publication. | | `userAudienceMap` | Array of audience assignments for this Publication. | | `allowedCountries` | Country codes from which access is explicitly allowed. Empty array means no restriction. | | `blockedCountries` | Country codes from which access is explicitly blocked. Empty array means no restriction. | | `configuration` | Branding and app name/description overrides applied to this Publication. | | `terms` | Legal terms configuration — whether acceptance is required and the terms text. | #### Pagination fields | Field | Description | |---|---| | `totalDocs` | Total number of Publications matching the query. | | `page` | Current page number. | | `totalPages` | Total number of pages. | | `limit` | Number of results per page. | | `hasNextPage` | Whether there is a subsequent page of results. | | `hasPrevPage` | Whether there is a previous page of results. | | `nextPage` | Page number of the next page, or `null` if on the last page. | | `prevPage` | Page number of the previous page, or `null` if on the first page. | --- ### Workspace API Use this endpoint when listing Publications at the Workspace level — for example, in automation pipelines that operate across multiple Apps using a single credential. Authentication uses a **Service Account** token, which is Workspace-scoped and not tied to any individual app. To create a Service Account, see [Service Accounts](https://docs.applivery.com/en/platform/api/service-accounts/). #### Endpoint ``` GET https://api.applivery.io/v1/organizations/{organizationId}/stores/{storeId}/pubApps ``` #### Path parameters | Parameter | Type | Required | Description | |---|---|---|---| | `organizationId` | String | Yes | The unique identifier of your Applivery organization. | | `storeId` | String | Yes | The unique identifier of the store (app project) whose Publications you want to list. | #### Authentication ``` Authorization: Bearer ``` #### Query parameters The Workspace API accepts the same query parameters as the Integrations API. #### Example Request ```bash curl 'https://api.applivery.io/v1/organizations/ORG_ID/stores/STORE_ID/pubApps?visibility=active' \ -X GET \ -H 'Authorization: Bearer YOUR_SERVICE_ACCOUNT_TOKEN' ``` The response schema is identical to the Integrations API. --- ## Publication Details Source: https://docs.applivery.com/en/app-distribution/api/publications/publication-details/ Description: Retrieve Publication details using Applivery's Integrations or Workspace APIs, including endpoints, authentication, and examples. TL;DR: Learn how to retrieve publication details from Applivery using either the Integrations API (App API Token) or the Workspace API (Service Account token). Key topics: Applivery API, Publication Details, Integrations API, Workspace API, Authentication, Applivery, App API Token, Service Account, publishedApplicationId Return the full configuration of a single Publication, identified by its `publishedApplicationId`. Use this endpoint to inspect the current state of a specific Publication before updating it, verify its access settings, or retrieve its `distributionUrl`. :::warning Before updating a Publication with PUT**, always retrieve its current details with this endpoint first. The [PUT endpoint](https://docs.applivery.com/en/app-distribution/api/publications/update-publication/) is a full replacement — fetching the current state lets you preserve fields you don't intend to change. ::: Applivery provides two separate APIs for retrieving Publication details, each requiring a different authentication credential. --- ### Choosing the right API | | Integrations API | Workspace API | |---|---|---| | **Designed for** | Per-app integrations and CI/CD pipelines | Workspace-level automation across multiple Apps | | **Authentication** | App API Token (per-app) | Service Account token (Workspace-level) | | **App context** | Implicit — token is already scoped to an App | Explicit — `organizationId`, `storeId`, and `publishedApplicationId` required in the path | | **Typical users** | Scripts that read a Publication's config before updating it | Platform engineers inspecting Publications across multiple Apps | :::warning Access to the different APIs might not be available in your current plan. Please check availability on our [pricing page](https://www.applivery.com/app-distribution-pricing/). ::: --- ### Integrations API Use this endpoint when retrieving Publication details within the scope of a single app. Authentication uses an **App API Token**, scoped to the specific App. To create an App API Token, see [Apps API Authentication](https://docs.applivery.com/en/app-distribution/api/app-api-token/). #### Endpoint ``` GET https://api.applivery.io/v1/integrations/distributions/{publishedApplicationId} ``` #### Authentication ``` Authorization: Bearer ``` #### Path parameters | Parameter | Type | Required | Description | |---|---|---|---| | `publishedApplicationId` | String | Yes | The unique identifier of the Publication to retrieve. E.g. `552ae3cfcb5abfc58d733b81`. Returned by [POST – Create a Published Application](https://docs.applivery.com/en/app-distribution/api/publications/create-publication/) and [GET – List of Published Applications](https://docs.applivery.com/en/app-distribution/api/publications/list-publications/). | #### Example Request ```bash curl 'https://api.applivery.io/v1/integrations/distributions/552ae3cfcb5abfc58d733b81' \ -X GET \ -H 'Authorization: Bearer YOUR_APP_TOKEN' ``` #### Responses **✓ 200 OK** ```json { "status": true, "data": { "id": "string", "updatedAt": "2025-10-23T07:54:26.518Z", "createdAt": "2024-07-23T08:10:46.471Z", "application": "string", "applicationInfo": { "id": "string", "slug": "string", "name": "string", "picture": "string" }, "slug": "string", "filter": { "type": "last", "value": "string", "ios": "string", "android": "string", "windows": "string", "macos": "string", "builds": [ { "buildPlatform": "string", "id": "string" } ] }, "security": "public", "tags": ["string"], "groups": [["string"]], "activateUserAudiences": false, "userAudienceMap": [], "visibility": "active", "showHistory": false, "showDevInfo": false, "expirationDate": "string", "distributionUrl": "string", "terms": { "active": true, "text": "string" }, "configuration": { "branding": { "logo": "string", "primaryColor": "string", "useAppIcon": false }, "application": { "description": "string", "name": "string" } }, "allowedCountries": [], "blockedCountries": [] } } ``` **✗ 401 Unauthorized** ```json { "status": false, "error": { "code": 4002, "message": "No auth token" } } ``` **✗ 404 Not Found** ```json { "status": false, "error": { "code": 3001, "message": "Entity not found" } } ``` #### Key response fields | Field | Description | |---|---| | `id` | The unique identifier of this Publication (`publishedApplicationId`). | | `slug` | The URL-friendly identifier used to construct the Publication URL. | | `distributionUrl` | The full public URL of the Publication. | | `security` | Current security mode: `public`, `password`, or `logged`. | | `visibility` | Current visibility state: `active`, `inactive`, or `unlisted`. | | `filter.type` | Build selection strategy: `last`, `build`, `builds`, `gitBranch`, `gitTag`, or `tag`. | | `filter.value` | The branch name, git tag, or build tag currently configured (for `gitBranch`, `gitTag`, and `tag` filter types). | | `filter.ios` / `filter.android` / `filter.macos` / `filter.windows` | Build IDs per platform (for `build` filter type). | | `filter.builds` | Array of `{ buildPlatform, id }` objects (for `builds` filter type, including custom platforms). | | `expirationDate` | ISO 8601 timestamp after which the Publication becomes unavailable. `null` if no expiration is configured. | | `groups` | Nested array of User Group identifiers controlling access (AND/OR logic). | | `activateUserAudiences` | Whether audience-based access control is enabled. | | `userAudienceMap` | Array of audience assignments, each with `id` and `notifyNewBuildsProcessed`. | | `showHistory` | Whether users can browse and install previous Builds. | | `showDevInfo` | Whether technical build information (git metadata, certificate details, tags) is shown to users. | | `allowedCountries` | Country codes from which access is explicitly allowed. Empty array means no country restriction. | | `blockedCountries` | Country codes from which access is explicitly blocked. Empty array means no country restriction. | | `configuration.application` | App name and description overrides applied to this Publication. | | `configuration.branding` | Logo, primary color, and button color overrides applied to this Publication. | | `terms` | Legal terms configuration — `active` indicates whether acceptance is required, `text` contains the terms content. | --- ### Workspace API Use this endpoint when retrieving Publication details at the Workspace level — for example, in automation pipelines that operate across multiple Apps using a single credential. Authentication uses a **Service Account** token, which is Workspace-scoped and not tied to any individual app. To create a Service Account, see [Service Accounts](https://docs.applivery.com/en/platform/api/service-accounts/). #### Endpoint ``` GET https://api.applivery.io/v1/organizations/{organizationId}/stores/{storeId}/pubApps/{publishedApplicationId} ``` #### Path parameters | Parameter | Type | Required | Description | |---|---|---|---| | `organizationId` | String | Yes | The unique identifier of your Applivery organization. | | `storeId` | String | Yes | The unique identifier of the store (app project) the Publication belongs to. | | `publishedApplicationId` | String | Yes | The unique identifier of the Publication to retrieve. | #### Authentication ``` Authorization: Bearer ``` #### Example Request ```bash curl 'https://api.applivery.io/v1/organizations/ORG_ID/stores/STORE_ID/pubApps/552ae3cfcb5abfc58d733b81' \ -X GET \ -H 'Authorization: Bearer YOUR_SERVICE_ACCOUNT_TOKEN' ``` The response schema is identical to the Integrations API. --- ## Update Publication Source: https://docs.applivery.com/en/app-distribution/api/publications/update-publication/ Description: Update existing published applications in Applivery using the Integrations or Workspace API. Control security, visibility, and more. TL;DR: Update your Applivery published applications via API using either the Integrations API (per-app) or the Workspace API (workspace-level) to manage security, visibility, and build filters. Key topics: Applivery API, Publication Management, Integrations API, Workspace API, API Authentication, Applivery, App API Token, Service Account, JSON, OTP Update the configuration of an existing Publication. All updatable fields from the [POST – Create a Published Application](https://docs.applivery.com/en/app-distribution/api/publications/create-publication/) endpoint are supported here, including security mode, build filter, access control, visibility, branding overrides, and legal terms. :::warning This is a full replacement (`PUT`), not a partial update (`PATCH`). Any field not included in the request body will be reset to its default value. Always retrieve the current Publication state first and include all fields you want to preserve. ::: Applivery provides two separate APIs for updating Publications, each requiring a different authentication credential. * * * ### Choosing the right API | | Integrations API | Workspace API | | --- | --- | --- | | **Designed for** | Per-app CI/CD pipelines | Workspace-level automation across multiple Apps | | **Authentication** | App API Token (per-app) | Service Account token (Workspace-level) | | **App context** | Implicit — token is already scoped to an App | Explicit — `organizationId` and `storeId` required in the path | | **Typical users** | Scripts that update a Publication's build filter after a new upload | Platform engineers managing Publications across multiple Apps | :::warning Access to the different APIs might not be available in your current plan. Please check availability on our [pricing page](https://www.applivery.com/app-distribution-pricing/). ::: * * * ### Integrations API Use this endpoint when updating Publications within the scope of a single app. Authentication uses an **App API Token**, scoped to the specific App. To create an App API Token, see [Apps API Authentication](https://docs.applivery.com/en/app-distribution/api/app-api-token/). #### Endpoint ``` PUT https://api.applivery.io/v1/integrations/distributions/{publishedApplicationId} ``` #### Authentication ``` Authorization: Bearer ``` #### Request format `application/json` #### Path parameters | Parameter | Type | Required | Description | | --- | --- | --- | --- | | `publishedApplicationId` | String | Yes | The unique identifier of the Publication to update. E.g. `552ae3cfcb5abfc58d733b81`. Returned by POST – Create a Published Application and GET – List of Published Applications. | * * * #### Parameters ##### Identity and Visibility | Parameter | Type | Description | | --- | --- | --- | | `slug` | String | The URL-friendly identifier for this Publication. Must be unique within the Workspace. Changing the slug changes the Publication URL — existing links will break. | | `visibility` | String | Publication visibility. Allowed values: `active`, `inactive`, `unlisted`. | ##### Security and Access Control | Parameter | Type | Description | | --- | --- | --- | | `security` | String | Authentication mode. Allowed values: `public`, `password`, `logged`. | | `password` | String | Required when `security` is `password`. The password users must enter to access the Publication. | | `groups` | Array | Restricts access to specific User Groups. Supports AND/OR logic. Each inner array is an AND clause; each outer element is an OR clause. E.g. `[["group1","group2"],["group3"]]`. Only applies when `security` is `logged`. | | `activateUserAudiences` | Boolean | Whether to enable audience-based access for this Publication. | | `userAudienceMap` | Array | Array of audience assignments for this Publication. | | `userAudienceMap[].id` | String | ID of the audience to assign. | | `userAudienceMap[].notifyNewBuildsProcessed` | Boolean | Whether users in this audience should be notified when a new Build is processed. | | `allowedCountries` | Array | ISO 3166-1 alpha-2 country codes to **allow** access from. Cannot be combined with `blockedCountries`. | | `blockedCountries` | Array | ISO 3166-1 alpha-2 country codes to **block** access from. Cannot be combined with `allowedCountries`. | ##### Build Selection Filter | Parameter | Type | Description | | --- | --- | --- | | `filter.type` | String | Build selection strategy. Allowed values: `last`, `build`, `Builds`, `gitBranch`, `gitTag`, `tag`. | | `filter.value` | String | Required for `gitBranch`, `gitTag`, and `tag` filter types. The branch name, git tag, or build tag to match. | | `filter.ios` | String | Build ID for the iOS build. Used when `filter.type` is `build`. | | `filter.android` | String | Build ID for the Android build. Used when `filter.type` is `build`. | | `filter.macos` | String | Build ID for the macOS build. Used when `filter.type` is `build`. | | `filter.windows` | String | Build ID for the Windows build. Used when `filter.type` is `build`. | | `filter.Builds` | Array | Array of `{ buildPlatform, id }` objects. Used when `filter.type` is `Builds`. Supports custom platforms: `ios`, `macos`, `android`, `ps4`, `ps5`, `switch`, `xbox-one`, `xbox-series`. | ##### Build Display options | Parameter | Type | Description | |---|---|---| | `tags` | Array | Tags to categorize this Publication. | | `showHistory` | Boolean | Whether users can browse and install previous Builds. | | `showDevInfo` | Boolean | Whether to display technical build information (git metadata, certificate details, tags) to users. | | `expirationDate` | String | ISO 8601 timestamp after which the Publication becomes unavailable for download. Use to create time-limited distributions, beta programs, or promotional campaigns. E.g. `"2025-12-31T23:59:59Z"`. Set to `null` to remove an existing expiration date. | ##### Legal Terms | Parameter | Type | Description | | --- | --- | --- | | `terms.active` | Boolean | Whether users must accept legal terms before accessing the Publication. | | `terms.text` | String | The legal terms text to display. Required when `terms.active` is `true`. | ##### Branding and App configuration overrides | Parameter | Type | Description | | --- | --- | --- | | `configuration.application.name` | String | Overrides the App name displayed in the Publication. | | `configuration.application.description` | String | Overrides the App description displayed in the Publication. | | `configuration.branding.logo` | String | Overrides the store logo for this Publication. | | `configuration.branding.primaryColor` | String | Overrides the primary branding color (hex format). E.g. `#FF5733`. | | `configuration.branding.buttonColor` | String | Overrides the button color (hex format). | * * * #### Example Request Update a Publication to point to a specific git branch and restrict access to logged-in users in a specific group: ```bash curl 'https://api.applivery.io/v1/integrations/distributions/552ae3cfcb5abfc58d733b81' \ -X PUT \ -H 'Authorization: Bearer YOUR_APP_TOKEN' \ -H 'Content-Type: application/json' \ -d '{ "slug": "my-app-staging", "security": "logged", "visibility": "active", "filter": { "type": "gitBranch", "value": "develop" }, "groups": [["qa-team"]], "showHistory": true, "showDevInfo": true }' ``` #### Responses **✓ 200 OK** ```json { "status": true, "data": { "id": "string", "updatedAt": "string", "createdAt": "string", "application": "string", "applicationInfo": { "id": "string", "slug": "string", "name": "string", "picture": "string" }, "slug": "string", "filter": { "type": "last", "value": "string", "ios": "string", "android": "string", "windows": "string", "macos": "string", "builds": [ { "buildPlatform": "string", "id": "string" } ] }, "security": "public", "tags": ["string"], "groups": [["string"]], "visibility": "active", "showHistory": true, "showDevInfo": true, "distributionUrl": "string", "terms": { "active": true, "text": "string" } } } ``` **✗ 400 Bad Request** Slug already in use. ```json { "status": false, "error": { "code": 5024, "message": "Slug already used" } } ``` **✗ 401 Unauthorized** ```json { "status": false, "error": { "code": 4002, "message": "No auth token" } } ``` **✗ 404 Not Found** ```json { "status": false, "error": { "code": 3001, "message": "Entity not found" } } ``` * * * ### Workspace API Use this endpoint when updating Publications at the Workspace level using a single credential across multiple Apps. Authentication uses a **Service Account** token. To create a Service Account, see [Service Accounts](https://docs.applivery.com/en/platform/api/service-accounts/). #### Endpoint ``` PUT https://api.applivery.io/v1/organizations/{organizationId}/stores/{storeId}/pubApps/{publishedApplicationId} ``` #### Path parameters | Parameter | Type | Required | Description | | --- | --- | --- | --- | | `organizationId` | String | Yes | The unique identifier of your Applivery organization. | | `storeId` | String | Yes | The unique identifier of the store (app project). | | `publishedApplicationId` | String | Yes | The unique identifier of the Publication to update. | #### Authentication ``` Authorization: Bearer ``` #### Example Request ```bash curl 'https://api.applivery.io/v1/organizations/ORG_ID/stores/STORE_ID/pubApps/PUB_APP_ID' \ -X PUT \ -H 'Authorization: Bearer YOUR_SERVICE_ACCOUNT_TOKEN' \ -H 'Content-Type: application/json' \ -d '{ "slug": "my-app-release", "security": "public", "visibility": "active", "filter": { "type": "last" } }' ``` The request body parameters and response schema are identical to the Integrations API. * * * ### Managing OTP Access users **OTP (One-Time Password) access** is a Publication-level security option that allows you to share Builds securely with external users — freelancers, QA studios, contractors — **without requiring them to have an Applivery account or go through your SSO**. This is particularly useful for organizations with strict SSO-only Policies that need to share Builds externally without relaxing their global authentication settings. OTP access is configured per Publication and does not affect any other Publication or the global App Store authentication settings. :::info OTP configuration can only be applied in **edit mode** — it must be set up after the Publication has already been created. Enable it by setting `security` to `"private"` and enabling OTP in the Dashboard, or by using the API endpoint described below to add users to the allowlist. ::: :::info OTP users are scoped to the specific Publication they accessed. They cannot browse or access other Publications in the App Store. ::: #### How it works **Admin side:** 1. Create or update a Publication with OTP access enabled (`security: "private"` + OTP allowlist configured). 2. Add the email addresses of authorized external users to the OTP allowlist, and configure each user's lifecycle and single-use settings. **User side:** 1. The user visits the Publication URL and enters their email address. 2. If their email is on the allowlist, they receive a time-limited OTP via email (valid for 5–10 minutes). 3. They enter the code to verify their identity and gain access to download the App. 4. If single-use is enabled, their email is automatically removed from the allowlist after the first successful download. #### Adding OTP Users via API OTP users are managed separately from the Publication configuration itself, via a dedicated endpoint. This endpoint is called **after** creating or updating a Publication to add users to its OTP allowlist. ##### Endpoint ``` POST https://api.applivery.io/v1/organizations/{organizationSlug}/stores/{storeId}/otp-users ``` ##### Authentication ``` Authorization: Bearer ``` ##### Path parameters | Parameter | Type | Required | Description | | --- | --- | --- | --- | | `organizationSlug` | String | Yes | The URL-friendly slug of your Applivery organization (not the numeric ID). | | `storeId` | String | Yes | The unique identifier of the store the Publication belongs to. | ##### Body parameters | Parameter | Type | Required | Description | | --- | --- | --- | --- | | `email` | String | Yes | The email address of the external user to add to the OTP allowlist. | | `temporal` | Boolean | No | Whether the user should be automatically removed after 30 days. Default: `true`. Set to `false` for persistent access. | | `singleUse` | Boolean | No | Whether the user's access should be invalidated after the first successful download. Once downloaded, the email is removed from the allowlist and the user must be re-added to regain access. Default: `false`. | ##### Example Request ```bash curl 'https://api.applivery.io/v1/organizations/my-org-slug/stores/STORE_ID/otp-users' \ -X POST \ -H 'Authorization: Bearer YOUR_SERVICE_ACCOUNT_TOKEN' \ -H 'Content-Type: application/json' \ -d '{ "email": "contractor@externalstudio.com", "temporal": true, "singleUse": false }' ``` ##### Responses **✓ 200 OK** ```json { "status": true, "data": { "id": "string", "email": "contractor@externalstudio.com", "temporal": true, "singleUse": false, "createdAt": "string" } } ``` **✗ 400 Bad Request** Email already exists in the OTP allowlist for this store. **✗ 401 Unauthorized** Invalid or missing Service Account token. **✗ 404 Not Found** Organization slug or store ID not found. #### OTP configuration options reference | Option | Description | | --- | --- | | **Allowlist** | The list of email addresses authorized to request an OTP for this Publication. | | **User lifecycle** | `temporal: true` — OTP users are auto-deleted after 30 days. `temporal: false` — OTP users are retained indefinitely. | | **Single-use access** | `singleUse: true` — the email is removed from the allowlist after the first successful download. The user cannot request another OTP unless re-added by an admin. | | **OTP expiry** | OTPs are time-bound and single-use — valid for 5–10 minutes and cannot be reused even within the validity window. | | **New Build notifications** | When a new Build is published, OTP users on the allowlist can receive a notification email with a fresh OTP, allowing them to download without requesting access again manually. | #### When to use OTP Access | Scenario | Recommended approach | | --- | --- | | Share a Build with an external freelancer for a one-time review | OTP + `singleUse: true` | | Share a beta with an external QA studio for a limited test period | OTP + Expiring Publication | | Distribute to a list of external testers without permanent accounts | OTP + `temporal: true` (30-day auto-cleanup) | | Long-term external collaborators needing ongoing access | Private Publication + Audience-based access instead of OTP | :::tip For maximum control over time-limited external access, combine OTP with an **Expiring Publication**. This ensures access is both identity-verified (via OTP allowlist) and time-bounded (via Publication expiry) — with no manual cleanup needed once the deadline passes. ::: --- ## Authentication Source: https://docs.applivery.com/en/app-distribution/authentication/ Description: Applivery uses Google social login for secure, frictionless access to the Enterprise Store. Configure sign-in and access control for your organization. TL;DR: Applivery uses Google social login for secure and easy access to the Enterprise Store. Key topics: Authentication, Google Social Login, Enterprise Store Access, Applivery, Google Authentication controls how users sign in to the Applivery Enterprise Store. By default, users can authenticate with Google social login, providing a simple and reliable sign-in experience while maintaining secure access control. You can choose which authentication options are available to store users and configure them for your organization. --- ## Google Login Source: https://docs.applivery.com/en/app-distribution/authentication/google-login/ Description: Integrate Google login with Applivery to simplify authentication and user management for your Enterprise Store. TL;DR: Integrate Google login with Applivery to streamline user authentication for your Enterprise Store. Key topics: Google login, Applivery integration, Enterprise Store, Authentication, Google, Applivery Applivery provides support for integrating Google, allowing you and your users to log in using their Google credentials, simplifying authentication and user management. ### Set up your Google login Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), go to your **Workspace Settings** 1 from the top dropdown menu, then open **Login providers** 2 in the left-hand menu and click the **Social** option under the **Enterprise Store** section 3. ![google login provider](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/eb4c4cef-3463-4363-8450-fd8d30d93f17.png) You will only need to Save the configuration. ![google login provider save](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/f3438cf4-ddfc-4c0c-8fca-bcd22e95ef95.png) :::warning Once you have saved the configuration, don’t forget to **enable the switch** for your integration to start using it in your Enterprise Store. ::: :::warning Only emails with an active role in the Workspace can access the Enterprise Store. Emails without an assigned role will be denied access. ::: --- ## Builds Source: https://docs.applivery.com/en/app-distribution/builds/ Description: Builds in Applivery represent your App versions. Manage uploads, updates, storage, retention policies, and controlled releases from one place. TL;DR: Builds in Applivery are versions of your apps that you manage and distribute, containing the app package and metadata for version control and release management. Key topics: Applivery, App Distribution, Builds, Version Control, Release Management Builds represent the different versions of your Apps that you upload, manage, and distribute within your Workspace. Each Build contains the compiled App package along with its associated metadata, allowing you to organize versions, track updates, and control how each release reaches your users. Upload and tag Builds, notify Collaborators, manage download tokens, and work with Build-level settings. --- ## Build Retention Source: https://docs.applivery.com/en/app-distribution/builds/build-retention/ Description: Configure Build Retention Policies in Applivery at the Workspace and App levels to manage storage and ensure access to recent Builds. TL;DR: Applivery's build retention feature lets you control how long your app builds are stored, helping you manage storage and ensure access to recent versions. Key topics: Build Retention Policy, Workspace Configuration, App Configuration, Retention Period, Unlimited Retention, Applivery, Enterprise plans :::warning This feature may vary depending on your current plan. Check the availability on our [pricing page.](https://www.applivery.com/app-distribution-pricing/) ::: **Build Retention** allows you to define how long uploaded Builds are stored in Applivery before they are automatically archived and permanently deleted. Previously, uploaded Builds were kept indefinitely. With this new system, Builds are now retained based on your **subscription plan** and **retention settings**. - **Unlimited retention** is only available for **Enterprise plans** and must be explicitly enabled upon request. - Once a Build reaches the end of its retention period, it moves to the **Pending deletion stage**, where it remains for a **30-day grace period** before permanent deletion. ### Automatic retention rules Even with retention limits in place, Applivery automatically preserves a **minimum number of recent Builds per Publication**. This ensures that you always have access to the most recent Builds for every App Publication within your Workspace. When the retention limit is reached, the oldest Builds are deleted first while newer ones are retained. ### Configuring Build Retention You can configure Build Retention at two levels: - Workspace level. - App level. #### Workspace level Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), navigate to your **Workspace Settings** 1, select **Storage** 2 from the left-hand menu and scroll down to locate the **Build retention policy** 3 configuration. ![build retention](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/b8e3109b-d325-4029-91d8-882d3858da62.png) Here you can: - Specify the **retention period** (the number of days a Build is kept before being deleted). - Set the **number of recent Builds to retain per Publication** (these are preserved even beyond the retention period). :::info By default, all Apps within the Workspace inherit these settings. ::: :::warning In **Enterprise plans**, you can enable **Unlimited retention** if it has been previously activated after contacting our team. For other plans, you can adjust the values within the limits of your subscription. ::: #### App level Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), select the **App** you want to configure, then go to the **Settings** tab and open the **Advanced** section. Locate the **Build retention policy** configuration. ![build retention period app](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/5109af55-aa1d-48e1-bd64-df5c9431b7e2.png) At this level, you can: - Inherit Workspace settings, or - Define a **custom retention policy** for that specific App — including unlimited retention (if available in your plan) or a custom retention period and number of Builds to retain per Publication. --- ## Custom Storage Regions Source: https://docs.applivery.com/en/app-distribution/builds/custom-storage-regions/ Description: Configure custom storage regions in AWS S3 and GCP for your Applivery account to control where your Build files are stored. TL;DR: Configure custom storage regions in AWS S3 or GCP for your Applivery account by following this step-by-step guide. Key topics: AWS S3 configuration, GCP Cloud Storage configuration, Applivery storage settings, Applivery, AWS S3, GCP Cloud Storage, Amazon Web Services, Google Cloud Platform :::warning This is a premium feature that might not be available in your current plan. Check the availability on our [pricing page](https://www.applivery.com/pricing/). ::: Customers can now manage their own [Storage regions](https://docs.applivery.com/en/app-distribution/builds/storage-regions/) in [AWS S3](#aws-s3) and [GCP Cloud Storage](#gcp-cloud-storage). ### AWS S3 #### Bucket creation **Log in to AWS** Log in to your [Amazon Web Services console](https://console.aws.amazon.com/) with your credentials. **Navigate to S3** Go to the **Storage > S3** section. **Create a bucket** Click the **Create bucket** orange button. **Fill out bucket information** Fill out your bucket information (Bucket name and Region). ![s3-custom-bucket-name | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/df0f395b-d3b0-4d4e-bfe7-fc39932a86fe.png) **Configure Public Access** Scroll down until the **Block Public Access settings for bucket** section and select the following two options: - Block public access to buckets and objects granted through new public buckets or access point Policies. - Block public and cross-account access to buckets and objects through any public bucket or access point Policies. - I acknowledge that the current settings might result in this bucket and the objects within becoming public. ![s3-custom-bucket-security | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/40eb86d0-5a52-4534-9848-f6c47d0579ec.png) **Create the bucket** Scroll down and click the **Create bucket** orange button. #### Credentials configuration **Create a new AWS User** We recommend creating **a new AWS User** and credentials. Go to **AWS IAM > Users** section and click the **Add user** button. **Select User Type** Select a user name and choose the **Programmatic access** option under the access type section. ![s3-custom-bucket-user | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/260914eb-a80b-4096-a123-1f4760264076.png) **Follow the wizard** Click **Next**, and follow steps 2, 3, and 4 without changing anything, maintaining the default options, and finish by clicking the **Create user** button. **Store Credentials** The user credentials will be displayed, copied, and stored securely. You will have to provide them to our team. ![s3-custom-bucket-credentials | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/648a8e9f-ba6a-47c7-9938-1054bccd68c8.png) #### Grant permissions **Add Inline Policy** Now we have to grant some additional permissions to the new user. For this example, we will use the Inline AWS Policies, but as an alternative, you can create a new Policy and attach it to the user. Click on the new user and click **Add inline policy** under the Permissions tab. **Use JSON Editor** Use the **{} JSON** editor and enter the following AWS Policy: ```json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:PutObject", "s3:GetObject", "s3:DeleteObject", "s3:GetBucketLocation", "s3:PutObjectAcl" ], "Resource": [ "arn:aws:s3:::mycustom-private-bucket", "arn:aws:s3:::mycustom-private-bucket/*" ] } ] } ``` :::warning Note that you have to substitute the `arn:aws:s3:::mycustom-private-bucket` with the ARN of the bucket you created in the previous step. ::: #### Select your new Storage region **Access Storage configuration** Once created, a new record will be added to the list, easily identifiable as it will be displayed as a **You** or **Managed by** title. **Configure Storage region** You can configure your Custom Storage Region at the Workspace or App levels: - **Workspace:** The configuration will be applied to the entire Workspace. It will apply to all Apps except those that already have a Custom Storage region configured. To do so, just click **Select** on this screen to enable it at the entire Workspace level. - **App:** The configuration will be applied just to this App, regardless of the Workspace configuration. To do so, go to your **App Settings > Advanced** and **Select** the Storage provider you’d like. :::info Only the new Builds uploaded will be stored in the new region. Previous ones will remain in the same place. ::: ### GCP Cloud Storage #### Create a service account **Log in to GCP** Log in to your [Google Cloud console](https://console.cloud.google.com/) with your credentials. **Navigate to Service Accounts** Go to the **IAM > Service Accounts** section and click the **Create service account** button. **Fill out Service Account Information** Fill out **Step 1** with your service account information. You can safely **skip Steps 2** and 3 for now. Then click **Done**. ![step1-gcp-serviceaccount-001 | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/c888ba1f-083f-481e-aec2-9e2c55bcf1e5.png) **Create Key** Once the service account has been created, click the **CREATE KEY** button. **Navigate to Cloud Storage Interoperability** Now, navigate to **Cloud Storage** in the GCP products menu, then click **Settings > Interoperability**. **Create Key for Service Account** Then scroll down to **Service account HMAC** and click **+CREATE A KEY FOR ANOTHER SERVICE ACCOUNT**. ![step1-gcp-cloudstorage-interoperability | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/4209fb9f-ee32-479a-b02c-34e0f90fb9c3.png) **Select Service Account** Use the filtering options to find the Service Account that you generated in the previous step. Select it and then click **CREATE KEY**. ![step1-gcp-serviceaccount-004 | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ff2ccaae-1bf5-406b-8238-9ab8b48f99e0.png) **Save Credentials** A new **Access key** and **Secret** pair will be generated. Save these values for later. ![step1-gcp-serviceaccount-005 | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/6e63f445-1343-4448-9c8b-2914a154418b.png) #### Create a Cloud Storage bucket **Navigate to Cloud Storage** Now navigate to **Cloud Storage**, from the products menu, and click **Create bucket**. **Fill out Bucket Name** Fill out the bucket name and click **CONTINUE**. ![step2-gcp-cloudstorage-001 | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ffcfc277-3c55-4d42-8d9a-f0c2b0b8f2b3.png) **Choose Storage Location** Choose **where to store your data** from the available regions. You can choose regional storage, dual storage, and multi-region storage. ![step2-gcp-cloudstorage-002 | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/0a0f442f-ca33-44aa-8471-c548727ce599.png) **Choose Storage Class** Next, choose the **storage class**. We recommend using the “autoclass” option provided by GCP that automatically transitions each object to Standard or Nearline class based on object-level activity, to optimise for cost and latency. Recommended if usage frequency may be unpredictable. ![step2-gcp-cloudstorage-003 | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/a32075ce-0e2a-4fc3-a60c-d780c5609783.png) **Define Access Control** Define an **access control** policy that must be set to “**Fine-grained**” as Applivery will define individual access Policies for each object. ![step2-gcp-cloudstorage-004 | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/07b33c35-d1c7-457d-b2b6-36881a2c352b.png) **Configure Data Protection** Under **data protection**, we recommend choosing “**Soft-delete policy**” and then “**Use default retention duration**“. Then click the **CREATE** button to finish. ![step2-gcp-cloudstorage-005 | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/24a6eb9f-32bd-4654-84bd-590b15f7f5aa.png) #### Update bucket permissions **Navigate to Bucket Permissions** Now go to **Buckets**, select the bucket recently created, and click **PERMISSIONS**. **Grant Access** Click **+GRANT ACCESS**. ![step3-gcp-cloudstorage-001 | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/6d0aeda2-2578-4e23-8a09-b01e61d98cc6.png) **Assign Storage Object User Role** In the side panel, search for the service account under “**New principals**” and assign the “**Storage Object User**” role. Then click **SAVE**. ![step3-gcp-cloudstorage-002 | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/10c815a6-1327-4b78-999a-14c2a1bee7ed.png) ### Configure your Custom Storage Region in Applivery **Navigate to Storage Settings** Now that the AWS S3 or GCP Cloud Storage configuration is complete, open the top dropdown menu and access your **Workspace Settings** 1 in the [**Applivery Dashboard**](https://dashboard.applivery.io/). Then select **Storage** 2 from the left-hand menu and click the **\+ Create storage provider** 3 button. ![storage](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/fc462070-7468-4b8d-9459-6087d2211dd0.png) **Complete the Form** Complete the form with the information you generated in the previous steps. Then click the Save button. ![create storage provider](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/383de2b9-305a-4574-a9f5-7a258ed9ab2a.png) ### Enabling storage buckets You can switch between storage regions by just clicking the Select button beside every storage region. ### Testing new configurations You can use the bug icon located on each Storage region to test the proper configuration of the bucket. Applivery will run a series of tests that will confirm if the bucket has been properly configured. ![step4-gcp-cloudstorage-applivery-002 | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ea2bd444-bb83-482d-a28b-94547dfff94e.png) A successful test will look like this: ![storage check](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/92daa6b6-da1b-4b35-b6cb-2e68fbed4a55.png) ### Disabling a Custom Storage Region You can disable a Custom Storage Region by clicking the **Select** button of the default storage region (Ireland). ### Removing a Custom Storage Region You can permanently remove a Custom Storage Region by clicking the **pencil button** 4 beside it and then the **Delete** 5 button at the bottom of the modal view. The Storage Region will be permanently removed from the system. ![delete storage provider](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/0146cf90-9ae5-460d-a356-ff23a58951da.png) :::info The Builds uploaded to this storage will not be accessible anymore. ::: --- ## Markdown Cheat Sheet Source: https://docs.applivery.com/en/app-distribution/builds/markdown/ Description: Markdown syntax reference for Applivery — format Build release notes and descriptions with headings, lists, links, and images. TL;DR: This Markdown cheat sheet provides a quick and easy reference for formatting text using Markdown syntax. Key topics: Basic Markdown Syntax, Extended Markdown Syntax, Text Formatting, Lists and Links, Code Blocks, Markdown, HTML, GitHub, John Gruber ## Markdown Cheat Sheet Markdown is a lightweight syntax for formatting plain text that is easy to read and write. Applivery supports Markdown in Publications and text fields to enrich your content without needing to write HTML. For the full Markdown specification, see [John Gruber's original spec](https://daringfireball.net/projects/markdown/) and the [GitHub-flavored Markdown guide](https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax). * * * ### Basic Syntax These are the core elements supported by all Markdown applications. * * * #### Headings Use `#` symbols to define headings. The number of `#` symbols corresponds to the heading level (1–6). ```markdown ## H1 ### H2 #### H3 ##### H4 ###### H5 ###### H6 ``` * * * #### Emphasis ```markdown Italic text with *asterisks* or _underscores_. Bold text with **asterisks** or __underscores__. Combined bold and italic with **asterisks and _underscores_**. Strikethrough with two tildes: ~~strikethrough~~. ``` **Renders as:** Italic text with _asterisks_ or _underscores_. Bold text with **asterisks** or **underscores**. Combined bold and italic with **asterisks and _underscores_**. Strikethrough with two tildes: ~strikethrough~. * * * #### Horizontal Rules Any of the following produce a horizontal divider line: ```markdown ___ --- *** ``` * * * #### Lists **Ordered list:** ```markdown 1. First item 2. Second item 3. Third item ``` **Unordered list** — asterisks, hyphens, and plus signs all work: ```markdown * Item using asterisk - Item using hyphen + Item using plus ``` **Nested list:** ```markdown 1. First ordered item 2. Second ordered item - Unordered sub-item - Another sub-item 3. Third ordered item 1. Ordered sub-item ``` :::info Actual numbers in ordered lists don't matter — Markdown will render them sequentially regardless of what numbers you use. `1. 1. 1.` renders as `1. 2. 3.` ::: * * * #### Links ```markdown [Link text](https://www.example.com) [Link text with tooltip](https://www.example.com "Tooltip text") ``` Bare URLs are also automatically converted to links in most Markdown renderers: ```markdown https://www.example.com ``` * * * #### Images ```markdown ![Alt text](https://www.example.com/image.png) ![Alt text with tooltip](https://www.example.com/image.png "Tooltip text") ``` The alt text is displayed if the image fails to load and is also used by screen readers. * * * #### Code **Inline code** — wrap text in single backticks: ```markdown Use the `code` tag for inline snippets. ``` **Code blocks** — wrap with triple backticks. Optionally specify a language for syntax highlighting: ````markdown ```javascript const greeting = "Hello, world!"; console.log(greeting); ``` ```python greeting = "Hello, world!" print(greeting) ``` ``` No language specified — no syntax highlighting applied. ``` ```` **Renders as:** ```javascript const greeting = "Hello, world!"; console.log(greeting); ``` ```python greeting = "Hello, world!" print(greeting) ``` ``` No language specified — no syntax highlighting applied. ``` * * * #### Blockquotes Use `>` to create blockquotes. Blockquotes can be nested and can contain other Markdown elements. ```markdown > This is a blockquote. > This line is part of the same quote. > You can use *italic* and **bold** inside a blockquote. > First level >> Nested blockquote ``` **Renders as:** > This is a blockquote. > This line is part of the same quote. > You can use _italic_ and **bold** inside a blockquote. > First level > > > Nested blockquote * * * ### Extended Syntax These elements extend the basic syntax and are supported by most modern Markdown renderers, including GitHub-flavored Markdown. * * * #### Tables Use pipes `|` and hyphens `-` to create tables. The second row defines alignment using colons: ```markdown | Left-aligned | Center-aligned | Right-aligned | |:---|:---:|---:| | Cell | Cell | Cell | | Cell | Cell | Cell | ``` **Renders as:** | Left-aligned | Center-aligned | Right-aligned | | --- | --- | --- | | Cell | Cell | Cell | | Cell | Cell | Cell | * * * #### Task Lists ```markdown - [x] Completed task - [ ] Incomplete task - [ ] Another incomplete task ``` **Renders as:** - Completed task - Incomplete task - Another incomplete task * * * #### Footnotes ```markdown Here is a sentence with a footnote.[^1] [^1]: This is the footnote content. ``` * * * #### Escaping Characters To display a character that would otherwise be interpreted as Markdown formatting, prefix it with a backslash `\`: ```markdown \*This text is not italicized\* \# This is not a heading ``` Characters that can be escaped: `\ * _ { } [ ] ( ) # + - . !` * * * ### Quick Reference | Element | Syntax | | --- | --- | | Heading 1 | `# Heading` | | Heading 2 | `## Heading` | | Bold | `**bold**` | | Italic | `*italic*` | | Bold + Italic | `***bold italic***` | | Strikethrough | `~~strikethrough~~` | | Inline code | ``code`` | | Code block | ````language` | | Blockquote | `> quote` | | Ordered list | `1. item` | | Unordered list | `- item` | | Link | `[text](url)` | | Image | `![alt](url)` | | Horizontal rule | `---` | | Table | `\| col \| col \|` | | Task list | `- [x] done` | | Escape character | `\*` | --- ## Notifications Source: https://docs.applivery.com/en/app-distribution/builds/notifications/ Description: Configure Build notifications in Applivery at the user, App, Build, and Publication levels, including priority rules and audience management. TL;DR: Configure Applivery build notifications at user, app, build, and publication levels to control which users receive updates. Key topics: User-level notifications, App-level notifications, Build-level notifications, Publication-level notifications, Audience management, Applivery, Audience 1, Audience 2 It can be challenging when it comes to uploading new Builds to your Apps and configuring which User Groups or audiences will receive notifications about the new Build. In Applivery, there are four notification settings levels: **User-level**, **App-level**, **Build-level**, and **Publication-level**. ### User-level settings **User-level** settings take precedence over all others. Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), go to your **account configuration** 1 from the top dropdown menu, then open **Notifications** 2 in the left-hand menu and choose which notifications you’d like to receive and manage them by App (using the Manage by app button) if needed. ![user notifications](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/11ccb88f-3c68-41ad-b626-28c2deb785ab.png) :::info Only Workspace Collaborators can configure these notifications, as Employees do not have access to the Dashboard. You can learn more about Applivery user types [here](https://docs.applivery.com/en/app-distribution/distribute/manage-users/). ::: ### App-level settings **App-level** settings have the next highest priority and can be configured by navigating to the **App’s Settings** > **Email notifications** section. This configuration serves as the default for notifying Collaborators/employees when a Build is uploaded to that App. ![app notification](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/63352e33-d167-4be4-9dbd-725b911e184a.png) ### Build-level settings Simply click the **\+ Upload Build** button, and after selecting the file to upload, choose the option to **Modify notification settings for this Build**. ![notify build](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/a0fcb1ec-d25c-46f0-a081-624ef97b9d8d.png) Click the Next button to configure the notification settings for this specific Build. ![notify users](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/be7aa3d7-bddc-40bf-b78c-e163f81205fb.png) ### Publication-level settings **Publication-level** settings have the lowest priority, so the previously described settings will take precedence. ![Publication level notifications](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/8959f3d8-911f-4b7c-b682-cc11623f2bfc.png) In summary, once we go through the App-level priority, then move to the Build-level, and finally reach the Publication-level, we will check within the Publication level which groups/audiences should—or should not—be notified. :::info To learn more about group and audience management, you can check out the following resources: - [Distribution groups](https://docs.applivery.com/en/app-distribution/distribute/user-groups/). - [Managing Audiences](https://docs.applivery.com/en/app-distribution/distribute/user-audiences/). ::: ### Important considerations regarding Audience notifications When configuring notifications for your audience in Applivery, it’s essential to keep several key considerations in mind. Imagine you have an App with two different audiences: _Audience 1_ and _Audience 2_. You want to send notifications about new Builds but need to configure which audience will receive them. - Your App has enabled notifications (App-level). - The App has one Publication targeting all Builds, shared with both audiences: - _Audience 1_ – notifications **ON**. - _Audience 2_ – notifications **OFF**. #### Who will receive notifications if you upload a new Build with notifications enabled? If you upload a Build with notifications enabled, Audience 1 will receive notifications, as notifications are enabled at the App, Publication, and Build levels. However, Audience 2 will not receive any notifications. ![](https://www.applivery.com/wp-content/uploads/2025/04/notification-1024x636.png "notification | Applivery") #### Who will receive notifications if you upload a new Build with notifications disabled? If you upload a Build with notifications disabled at the Build level, it will override the App-level setting (which is enabled), and neither Audience 1 nor Audience 2 will receive notifications. This holds true even if notifications are enabled for Audience 1 at the Publication level, as the Build-level setting takes precedence. #### Who will receive notifications if you upload a new Build with notifications disabled at the App level but enabled at the Build level? In this case, Audience 1 will still receive the notification, as the Build configuration takes precedence over the App-level settings. ![](https://www.applivery.com/wp-content/uploads/2025/04/notification-2-1024x632.png "notification-2 | Applivery") --- ## Processing Error Codes Source: https://docs.applivery.com/en/app-distribution/builds/processing-error-codes/ Description: Reference guide for Applivery Build processing error codes — diagnose and resolve failures across iOS, Android, macOS, Windows, and Homebrew. TL;DR: This guide lists Applivery build processing error codes and provides solutions for common issues across different platforms. Key topics: Error codes, Build processing, Troubleshooting, Applivery, Mobile app deployment, iOS, Android, macOS, Windows, Homebrew, IPA, APK, DMG, PKG, APPX, MSIX, AAB When a Build is uploaded to Applivery, it goes through an automated processing pipeline that validates and extracts metadata from the file. If processing fails, one of the error codes below will be returned. This reference lists all possible error codes, what they mean, and what to do to resolve them. Codes are grouped by platform to make it easier to find what you are looking for. * * * ### iOS | Code | Description | Resolution | | --- | --- | --- | | `IOS_INVALID_PACKAGE` | The package inside the `.ipa` file is not valid. | Make sure the App has been built and signed correctly, and that the `.app` bundle inside the `.ipa` is not corrupted. | | `EMBEDDED_MOBILEPROVISION_NOT_FOUND` | The Embedded Mobile Provisioning Profile is missing, and the Build cannot be processed. | Make sure the App contains a valid Provisioning Profile file embedded in the `.ipa`. | | `PAYLOAD_NOT_FOUND` | The `Payload` directory was not found inside the `.ipa`. | Verify that the `.ipa` contains a valid `Payload` directory with the `.app` bundle inside it. | * * * ### Android | Code | Description | Resolution | | --- | --- | --- | | `ANDROID_MANIFEST_NOT_FOUND` | The `AndroidManifest.xml` file is missing, and the Build cannot be processed. | Make sure the App contains a valid `AndroidManifest.xml` file. | | `ANDROID_FAILED_PARSE_BINARY_ANDROID_MANIFEST` | The Android Manifest XML is invalid or not in binary format. | The APK contains a non-binary XML manifest that cannot be parsed. Check the Build process to ensure the APK has been compiled correctly. | | `ANDROID_AAB_CONFIGURATION_NOT_FOUND` | The Android App Bundle (AAB) configuration is missing or invalid. | Go to **App > Settings > Android App Bundle** and review or add a valid AAB configuration. | | `ANDROID_AAB_NO_KEY_FOUND_FOR_ALIAS_IN_KEYSTORE` | The signing key alias was not found in the provided Keystore. | Configure the correct AAB signing key under your project's **Android App Bundle Settings**. | | `ANDROID_AAB_INCORRECT_KEYSTORE_PASSWORD` | The Keystore password provided is incorrect. | Verify that the Keystore password configured in your **Android App Bundle Settings** is correct. | | `ANDROID_AAB_INCORRECT_KEY_PASSWORD` | The signing key password provided is incorrect. | Verify that the signing key password configured in your **Android App Bundle Settings** is correct. | * * * ### macOS | Code | Description | Resolution | | --- | --- | --- | | `PKG_ARCHIVE_OPEN_FAILED` | The package inside the `.pkg` file is not valid. | Make sure the App has been built and signed correctly, and that the `.pkg` package is not corrupted. | | `NO_BUILD_INSIDE_DMG` | The `.dmg` file does not contain a valid build. | Make sure the `.dmg` contains a valid `.app` or `.pkg` file for processing. | * * * ### Windows | Code | Description | Resolution | | --- | --- | --- | | `APPX_BUNDLE_MANIFEST_NOT_FOUND` | The `AppxBundleManifest.xml` file is missing from the `.appxbundle` or `.msixbundle` package. | Make sure your App package contains a valid `AppxBundleManifest.xml` file. | | `APPX_MANIFEST_NOT_FOUND` | The `AppxManifest.xml` file is missing from the `.appx` or `.msix` package. | Make sure your App package contains a valid `AppxManifest.xml` file. | * * * ### Homebrew | Code | Description | Resolution | | --- | --- | --- | | `ERROR_ARTIFACT_FROM_HOMEBREW_TOKEN` | No artifact was found using the provided Homebrew token. | Make sure your App is publicly available on Homebrew, and the token is correct. | * * * ### General / File Errors These codes are not specific to a single platform and can appear with any file type. | Code | Description | Resolution | | --- | --- | --- | | `UNSUPPORTED_FORMAT` | The uploaded file format is not supported for processing. | Check the supported file formats and re-upload in a compatible format. | | `BUILD_TYPE_NOT_FOUND` | No processable file was found inside the uploaded package. | Ensure the uploaded file contains a supported build artifact. | | `NO_VALID_FILE_FOUND_FOR_PROCESSING` | No file with a supported extension was found inside the package. | Ensure the file contains one of the following extensions: `.pkg`, `.app`, `.exe`, `.msi`, `.appxbundle`, or `.msixbundle`. | | `NO_FILES_EXTRACTED_FROM_COMPRESSED_FILE` | The `.zip` file contains no processable files. | Make sure the `.zip` contains a valid build file and is not empty or corrupted. | | `{FILE}_CURRENTLY_ONLY_ONE_BUNDLE_SUPPORTED` | The file contains multiple items of the same type and cannot be extracted. `{FILE}` will be one of: `PKG`, `APP`, `EXE`, `MSI`, `APPXBUNDLE`, `MSIXBUNDLE`. | Ensure the uploaded file contains only one item of each supported type. | | `UPLOAD_FILE_FAILED` | An error occurred while uploading the file to Applivery. | Retry the upload. If the issue persists, contact support. | | `COPY_FILE_FAILED` | An error occurred while copying the file during processing. | Retry the upload. If the issue persists, contact support. | * * * ### Supported File Formats Applivery supports the following file formats for build uploads: | Platform | Supported formats | | --- | --- | | **iOS** | `.ipa`. | | **Android** | `.apk`, `.aab`. | | **macOS** | `.pkg`, `.app`, `.dmg`. | | **Windows** | `.exe`, `.msi`, `.appx`, `.msix`, `.appxbundle`, `.msixbundle`. | | **macOS (package manager)** | Homebrew token. | | **Cross-platform** | `.zip` containing a supported format and `.tar.gz`. | --- ## Storage Regions Source: https://docs.applivery.com/en/app-distribution/builds/storage-regions/ Description: Configure storage regions for your Applivery Builds to optimize performance and meet data residency requirements, per organization or per App. TL;DR: Applivery lets you choose where your builds are stored (by region) for better performance and data compliance, either at the organization or app level. Key topics: Storage Regions, Applivery Configuration, Build Storage, Data Residency, Applivery, AWS S3, GCP Cloud Storage, Europe (Ireland) :::warning This is a premium feature that might not be available in your current plan. Check the availability on our [pricing page](https://www.applivery.com/pricing/). ::: Applivery storage of Builds is hosted in multiple locations worldwide. These locations are composed of Regions. Each Region is a separate geographic area that will allow you to place your Builds closer to your end users. By default, all Builds and resources will be stored in the `eu-west-1` Europe (Ireland) region, but account administrators will be able to customize this configuration at the following levels: - Define a default Storage Region for the entire organization. - Define a Storage Region for a specific App. :::info Modifying the default Storage Region of the organization or an App will not affect already stored Builds. It will only affect new Builds that are uploaded. ::: You can know in which region an App is located by going to the **Settings > Advanced** section of the **App**, under the **Storage provider** section. ![storage provider app](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/43981f8e-9229-47e9-b6b0-9c8c47b02dae.png) You can also check which region a specific Build is stored in by clicking on it and reviewing the **Storage provider** section. ![build storage](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/44325140-6140-4341-b679-65161532210c.png) ### Available regions The following table and map list the Regions provided by Applivery that can be selected for your Organizations and Apps. If you are running on an Enterprise Plan, you can configure your own **AWS S3** or **GCP Cloud Storage** Buckets. To set them up, follow [Custom Storage Regions](https://docs.applivery.com/en/app-distribution/builds/custom-storage-regions/). --- ## CI/CD Source: https://docs.applivery.com/en/app-distribution/ci-cd/ Description: CI/CD integrations for Applivery: automate Build uploads with Jenkins, Bitrise, Fastlane, Azure DevOps, GitHub Actions, and App Live. TL;DR: CI/CD automates app development processes, enabling continuous integration and delivery through tools like Jenkins and Azure DevOps. Key topics: Continuous Integration, Continuous Delivery, Automation, Deployment Pipelines, Jenkins, Bitrise, Fastlane, Azure DevOps, App Live Applivery integrates with your existing CI/CD pipeline so that every successful Build can be automatically uploaded and distributed without manual intervention. It supports Jenkins, Bitrise, Fastlane, Azure DevOps, GitHub Actions, and App Live workflows. Configure each integration, pass the right parameters, and automate notifications so your team is always in the loop when a new Build is ready. --- ## App Live Source: https://docs.applivery.com/en/app-distribution/ci-cd/app-live/ Description: Integrate Applivery with BrowserStack's App Live for mobile App testing on real devices. Connect your Workspace and sync releases automatically. TL;DR: Integrate Applivery with BrowserStack App Live to test your mobile apps on real devices without manual uploads. Key topics: App Live integration, Applivery integration, Mobile app testing, Real device testing, BrowserStack, App Live, Applivery, iOS, Android [App Live](https://www.browserstack.com/app-live) is BrowserStack's real-device cloud testing platform. It lets developers and QA teams run mobile Apps on real iOS and Android Devices hosted in the cloud — without a physical device lab. You can interact with Apps as end users would, test across hundreds of device and OS combinations, and debug issues in real time. The Applivery integration with App Live allows you to connect your Applivery Workspace directly to the App Live Dashboard. Once connected, all your Apps and Builds are available for testing in BrowserStack without any manual file uploads — you select an App, pick a Device, and start a live session. * * * ### Prerequisites Before setting up the integration, make sure you have: - A [BrowserStack](https://www.browserstack.com/users/sign_up) account with App Live access. A free trial is available if you don't have one yet. - An **Applivery Service Account** and its corresponding **Bearer token**. App Live uses these credentials to authenticate against your Applivery Workspace. See [Service Accounts](https://docs.applivery.com/en/platform/api/service-accounts/) for instructions on creating one. ![Service Accounts](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/033d5048-3647-421d-8250-f9efb46824d9.png) * * * ### Connect your Applivery Workspace to App Live Once in the [App Live Dashboard](https://app-live.browserstack.com/), in the **Select Source** 1 panel, click **Integrate with Applivery** 2. Enter the **Bearer token** 3 from your Applivery Service Account and click **Connect Workspace** 4. ![app live integration](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/71f82b67-a4ee-4624-ad91-e5f1a68eca34.png) Once authenticated, you will be redirected to the App Live Dashboard with your Applivery Workspace connected. Your Apps and projects will now be available in the **Select Source** panel. ![successful integration](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/176a33a6-dfef-41f4-8b7c-d41f799d975a.png) * * * ### Browsing Apps and Releases App Live organizes your Applivery data using a three-level hierarchy: ``` Project → Apps → Releases ``` - **Projects** correspond to your Applivery Apps. The list includes both projects you have added yourself and projects shared with you by teammates. - **Apps** within each project show all applications associated with it. - **Releases** show all Builds available for testing within a given App. Select a project, then an App, then a release to access the available Devices and start a test session. ![project app releases](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/8d9bde57-5f32-4c5d-aecc-3408f3f1d275.png) * * * ### Sharing Projects with your Team Once you have added a project, you can share it with your team. Shared projects appear on your teammates' App Live Dashboards under the same project list. :::info You can only share projects that you have personally added. Projects shared with you by others cannot be re-shared. ::: In the project list, click the **⋮** 5 (more options) icon next to the project name, select **Share** 6, and confirm by clicking **Share** 7 in the dialog. ![share project](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/cee3849b-6563-431f-8591-dca5a8273d22.png) The project is now accessible to your teammates in their App Live views. * * * ### Synchronizing App Releases with BrowserStack Syncing an App release uploads it to BrowserStack Cloud, which makes it available for live sessions and unlocks advanced configuration options such as large app support and video injection. Configurations applied after syncing are persistent for that release. #### Sync a release 1. Select the project and app you want to sync. 2. Click the **synchronization icon** 8 next to the App name. 3. Wait for the process to complete. The sync icon changes to an unsync button when done, and configuration options become available. ![sync app release](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/1cf7f194-2718-418f-8a6a-3e29c98afb45.png) #### Unsync a release Unsyncing removes the release from BrowserStack Cloud. After unsyncing, the App will no longer be available for testing in App Live, and configurations cannot be applied. 1. In the App list, click the **unsync icon** 9 next to the App name. 2. The release is removed from BrowserStack Cloud. ![unsync app release](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/d139519d-9a71-4598-bc40-367f579dfb96.png) * * * ### Launching an App Live Session 1. Open the App Live Dashboard and select a project from the list. 2. Choose the App you want to test. 3. Select a release — the latest version is automatically synced to ensure you are testing the most recent build. 4. Choose a Device from the available options. 5. The session launches with your selected App and device. ![launching app live session](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ca55ecef-4221-4b9e-a78b-ae3c82e4286f.png) * * * ### Managing Projects #### Add a project Click the **+** 10 icon next to the project list in the App Live Dashboard and follow the Applivery integration flow. #### Refresh a project 1. Select the project from the list. 2. Click the **⋮** 11 icon and choose **Refresh** 12. This pulls the latest Apps and releases from your Applivery Workspace. #### Delete a single project 1. Select the project. 2. Click **⋮** and choose **Delete** 13. 3. Confirm the deletion. The project is removed from your App Live view. Projects shared with you by others are not affected. ![project actions](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/a0ee3e55-439a-46e9-95fc-11b02e0fe855.png) #### Disconnect your Applivery Workspace To remove all projects you have personally added and disconnect your Applivery Workspace from App Live: 1. Go to the App Live **Integrations** page. 2. Find the Applivery tile and click **Disconnect**. This removes all projects you added. Projects shared with you by teammates remain unaffected. --- ## Azure Pipelines Source: https://docs.applivery.com/en/app-distribution/ci-cd/azure-pipelines/ Description: Integrate Applivery with Azure Pipelines for automated Mobile App Distribution using Fastlane or the Applivery API. TL;DR: Integrate Applivery with Azure Pipelines to automate mobile app distribution using Fastlane or the Applivery API. Key topics: Azure Pipelines integration, Applivery Upload API, Fastlane integration, Mobile CI/CD, Automated app distribution, Azure DevOps, Azure Pipelines, Applivery, Fastlane, Microsoft, iOS, Android ![azure-pipelines-long](https://www.applivery.com/wp-content/uploads/2021/12/azure-pipelines-long-1024x307.png "azure-pipelines-long | Applivery") [Azure DevOps](https://azure.microsoft.com/en-us/services/devops/) is a Microsoft platform that covers the full application lifecycle — version control, project management, automated Builds, testing, and release management. [Azure Pipelines](https://azure.microsoft.com/en-us/services/devops/pipelines/), part of the Azure DevOps suite, provides cloud-hosted CI/CD pipelines for Linux, macOS, and Windows, supporting web, desktop, and mobile applications. The Applivery integration with Azure Pipelines lets you automatically upload new Builds to Applivery at the end of each pipeline run, making them immediately available to QA teams, stakeholders, or internal users. There are two approaches to integrating Azure Pipelines with Applivery: - **Via Fastlane** (recommended for iOS and Android projects that already use Fastlane) — delegates the upload to the Applivery Fastlane plugin. - **Via the Applivery Upload API directly** (recommended for any project or when Fastlane is not in use) — calls the API with a `curl` step in your YAML pipeline. --- ### Prerequisites Before setting up either approach, make sure you have: - An Azure DevOps account with an Azure Pipelines configuration in place. - An Applivery App API Token. Find it in **App Settings → API Tokens** in the Applivery Dashboard, or see [Apps API Authentication](https://docs.applivery.com/en/app-distribution/api/app-api-token/). - A pipeline that produces a Build artifact (`.ipa`, `.apk`, `.aab`, or another supported format). --- **Store the App Token as a Secret Variable** Never hardcode your Applivery token directly in `azure-pipelines.yml`. Store it as a secret pipeline variable in Azure DevOps so it is masked in logs and not committed to your repository. 1. Open your Azure DevOps project and go to **Pipelines → your pipeline → Edit**. 2. Click **Variables** (top right). 3. Add a new variable named `APPLIVERY_TOKEN`. 4. Paste your Applivery App API Token as the value. 5. Enable the **Keep this value secret** toggle to mask it in logs. 6. Save. ![azure-devops-pipelines-vars](https://www.applivery.com/wp-content/uploads/2021/12/azure-devops-pipelines-vars-1024x559.png "azure-devops-pipelines-vars | Applivery") Once defined, reference it in your pipeline YAML as `$(APPLIVERY_TOKEN)`. **Option A — Integration via Fastlane** This is the recommended approach if your project already uses Fastlane for building and signing. The Applivery Fastlane plugin handles the upload and all metadata automatically. For full Fastlane plugin documentation, see [Fastlane Integration](https://docs.applivery.com/en/app-distribution/ci-cd/fastlane/). #### Pipeline YAML In your `azure-pipelines.yml`, add a script step that invokes your Fastlane lane and passes the token as a parameter: ```yaml - script: fastlane dev_deploy applivery_token:$(APPLIVERY_TOKEN) displayName: 'Deploy to Applivery via Fastlane' env: APPLIVERY_TOKEN: $(APPLIVERY_TOKEN) ``` #### Fastfile Define a lane in your `Fastfile` that Builds and uploads to Applivery. The example below uses `last_git_commit[:message]` as the changelog and `number_of_commits` to auto-increment the Build number: ```ruby desc "Build and deploy to Applivery" lane :dev_deploy do |options| increment_build_number( build_number: number_of_commits ) build_app( scheme: "MyApp-Dev", export_method: "enterprise" ) applivery( app_token: options[:applivery_token], notify_collaborators: true, changelog: last_git_commit[:message] ) end ``` :::tip You can extend the `applivery` action with additional options like `tags`, `notify_message`, and `notify_language`. See the [Fastlane Integration](https://docs.applivery.com/en/app-distribution/ci-cd/fastlane/) documentation for all available parameters. ::: **Option B — Integration via the Upload API (without Fastlane)** If you are not using Fastlane, or want a simpler setup with no additional tooling, call the Applivery Upload API directly from your pipeline using `curl`. This works for any platform and any pipeline agent. #### Pipeline YAML — iOS example ```yaml trigger: - main pool: vmImage: 'macos-latest' stages: - stage: Build jobs: - job: BuildAndUpload steps: - checkout: self - task: Xcode@5 displayName: 'Build iOS app' inputs: actions: 'build' scheme: 'MyApp' sdk: 'iphoneos' configuration: 'Release' xcWorkspacePath: 'MyApp.xcworkspace' packageApp: true signingOption: 'default' - script: | curl 'https://upload.applivery.io/v1/integrations/builds' \ --retry 5 \ --fail \ -H "Authorization: Bearer $(APPLIVERY_TOKEN)" \ -F "build=@$(Build.ArtifactStagingDirectory)/MyApp.ipa" \ -F "versionName=$(Build.BuildNumber)" \ -F "changelog=$(Build.SourceVersionMessage)" \ -F "tags=azure-pipelines, ios" \ -F "notifyCollaborators=true" \ -F "notifyMessage=New build available from Azure Pipelines" \ -F "notifyLanguage=en" \ -F "deployer.name=Azure Pipelines" \ -F "deployer.info.commit=$(Build.SourceVersion)" \ -F "deployer.info.branch=$(Build.SourceBranchName)" \ -F "deployer.info.commitMessage=$(Build.SourceVersionMessage)" \ -F "deployer.info.buildUrl=$(System.TeamFoundationCollectionUri)$(System.TeamProject)/_build/results?buildId=$(Build.BuildId)" \ -F "deployer.info.buildNumber=$(Build.BuildNumber)" \ -F "deployer.info.repositoryUrl=$(Build.Repository.Uri)" displayName: 'Upload to Applivery' env: APPLIVERY_TOKEN: $(APPLIVERY_TOKEN) ``` #### Pipeline YAML — Android example ```yaml trigger: - main pool: vmImage: 'ubuntu-latest' stages: - stage: Build jobs: - job: BuildAndUpload steps: - checkout: self - task: Gradle@3 displayName: 'Build Android APK' inputs: workingDirectory: '' gradleWrapperFile: 'gradlew' gradleOptions: '-Xmx3072m' tasks: 'assembleRelease' - script: | curl 'https://upload.applivery.io/v1/integrations/builds' \ --retry 5 \ --fail \ -H "Authorization: Bearer $(APPLIVERY_TOKEN)" \ -F "build=@$(Build.ArtifactStagingDirectory)/app-release.apk" \ -F "versionName=$(Build.BuildNumber)" \ -F "changelog=$(Build.SourceVersionMessage)" \ -F "tags=azure-pipelines, android" \ -F "notifyCollaborators=true" \ -F "notifyMessage=New Android build from Azure Pipelines" \ -F "notifyLanguage=en" \ -F "deployer.name=Azure Pipelines" \ -F "deployer.info.commit=$(Build.SourceVersion)" \ -F "deployer.info.branch=$(Build.SourceBranchName)" \ -F "deployer.info.commitMessage=$(Build.SourceVersionMessage)" \ -F "deployer.info.buildUrl=$(System.TeamFoundationCollectionUri)$(System.TeamProject)/_build/results?buildId=$(Build.BuildId)" \ -F "deployer.info.buildNumber=$(Build.BuildNumber)" \ -F "deployer.info.repositoryUrl=$(Build.Repository.Uri)" displayName: 'Upload to Applivery' env: APPLIVERY_TOKEN: $(APPLIVERY_TOKEN) ``` --- ### Azure Pipelines predefined variables The pipeline examples above use Azure Pipelines predefined variables, which are automatically available in every pipeline without additional configuration: | Variable | Description | |---|---| | `Build.BuildNumber` | The Build number. Useful as a `versionName` in Applivery. | | `Build.BuildId` | Unique numeric ID for the Build run. Used to construct the Build URL. | | `Build.SourceVersion` | The full Git commit SHA that triggered the Build. | | `Build.SourceBranchName` | The name of the triggering branch. E.g. `main`, `develop`. | | `Build.SourceVersionMessage` | The commit message of the triggering commit. Useful as `changelog`. | | `Build.Repository.Uri` | The URL of the source repository. | | `Build.ArtifactStagingDirectory` | The local directory where build artifacts are placed. | | `System.TeamFoundationCollectionUri` | The base URL of your Azure DevOps organization. | | `System.TeamProject` | The name of the Azure DevOps project. | For the full list of predefined variables, see the [Azure Pipelines predefined variables documentation](https://docs.microsoft.com/en-us/azure/devops/pipelines/build/variables). --- ### Key upload parameters reference The `curl` form data fields map directly to the Applivery Upload API. These are the most commonly used: | Parameter | Description | |---|---| | `build` | The binary file to upload. | | `versionName` | Human-readable label for the Build. Using `$(Build.BuildNumber)` links it to the Azure run. | | `changelog` | Release notes shown in the Dashboard and notification emails. | | `tags` | Comma-separated tags for filtering Builds. | | `notifyCollaborators` | Set to `true` to email app Collaborators on upload. | | `notifyMessage` | Custom message included in the notification email. | | `deployer.name` | CI platform name shown in the Applivery Dashboard. | | `deployer.info.commit` | Git commit SHA. | | `deployer.info.branch` | Git branch name. | | `deployer.info.buildNumber` | Pipeline build number. | | `deployer.info.buildUrl` | Direct URL to the Azure pipeline run. | For the full parameter reference, see [POST – Upload a Build](https://docs.applivery.com/en/app-distribution/api/builds/upload-build/). --- ## Bitrise Source: https://docs.applivery.com/en/app-distribution/ci-cd/bitrise/ Description: Integrate Applivery with Bitrise CI/CD for automated mobile App building, testing, and deployment. TL;DR: Integrate Applivery with Bitrise to automate mobile app deployment by using the Applivery Step in your Bitrise workflow. Key topics: Bitrise CI/CD, Applivery integration, mobile app deployment, workflow automation, Applivery, Bitrise, GitHub, GitLab, Bitbucket, Fastlane ![bitrise](https://www.applivery.com/wp-content/uploads/2021/12/bitrise-1024x335.png "bitrise | Applivery") [Bitrise](https://www.bitrise.io/) is a mobile-first CI/CD platform designed specifically for iOS and Android app development. It uses **Workflows** — sequences of configurable Steps — to automate building, testing, signing, and deploying Apps. Applivery has an official **Applivery Step** in the Bitrise Step Library. Adding it to your workflow automatically uploads the built binary to Applivery after each successful build, with full CI metadata (branch, commit, build number) attached. --- ### Prerequisites Before setting up the integration, make sure you have: - A [Bitrise.io](https://www.bitrise.io/) account with an App already connected to your repository (GitHub, GitLab, or Bitbucket). - An Applivery App API Token. Find it in **App Settings → API Tokens** in the Applivery Dashboard, or see [Apps API Token](https://docs.applivery.com/en/app-distribution/api/app-api-token/). --- **Store the App Token as a Bitrise Secret** Never paste your token directly into a Step input field — it would be visible in your workflow configuration. Store it as a Secret so it is masked in logs and injected as an environment variable. 1. Open your Bitrise app and go to the **Secrets** tab (top navigation). 2. Click **Add new**. 3. Set the key to `APPLIVERY_APP_TOKEN`. 4. Paste your Applivery App API Token as the value. 5. Enable **Protected** to prevent the value from being exposed in build logs. 6. Click **Save**. Once saved, you can reference it anywhere in your workflow as `$APPLIVERY_APP_TOKEN`. **Add the Applivery Step to your workflow** 1. Open your Bitrise app and go to the **Workflows** tab. 2. Select the workflow where you want to add the Applivery deployment (typically your main build workflow, e.g. `primary` or `deploy`). 3. Click the **+** button at the point in the workflow where you want to add the Step — place it **after** your Build and signing steps (e.g., after `Xcode Archive & Export for iOS` or `Android Build`). 4. In the Step search box, type **Applivery**. 5. Select the **Deploy to Applivery** step from the results and click **Add**. **Configure the Applivery Step** With the Step added to your workflow, click on it to open its configuration panel. Fill in the following fields: **Required** | Field | Value | |---|---| | **App Token** | `$APPLIVERY_APP_TOKEN` (references the secret you created in Step 1) | **Optional** | Field | Description | |---|---| | **Build name** | Human-readable label for the Build. You can use Bitrise environment variables like `$BITRISE_BUILD_NUMBER` or `$GIT_CLONE_COMMIT_MESSAGE_SUBJECT`. | | **Changelog** | Release notes for this Build. Use `$GIT_CLONE_COMMIT_MESSAGE_BODY` to pull in the commit message automatically. | | **Tags** | Comma-separated tags to label the Build in Applivery. E.g. `bitrise, staging`. | | **Notify Collaborators** | Set to `true` to send an email notification to app Collaborators after the upload. | | **Notify Employees** | Set to `true` to send an email notification to store employees. | | **Notify Message** | Custom message to include in the notification email. | | **Build path** | Path to the binary to upload. If left empty, the Step automatically uses the output from the preceding build step (`$BITRISE_IPA_PATH` for iOS or `$BITRISE_APK_PATH` for Android). | **Run your workflow** Trigger a Build manually to verify the integration: 1. In your Bitrise app, click **Start/Schedule a Build**. 2. Select the workflow you configured. 3. Click **Start Build**. Once the Build completes, the Applivery Step will upload the binary to your Applivery app. Open the Applivery Dashboard to confirm the Build appears with the correct metadata. --- ### Bitrise Environment Variables The Applivery Step automatically captures Bitrise CI metadata. You can also reference these variables explicitly in Step input fields: | Variable | Description | |---|---| | `$BITRISE_BUILD_NUMBER` | Sequential build number assigned by Bitrise. | | `$BITRISE_BUILD_URL` | Direct URL to the current build in the Bitrise dashboard. | | `$BITRISE_GIT_BRANCH` | The Git branch that triggered the Build. | | `$BITRISE_GIT_COMMIT` | The Git commit SHA that triggered the Build. | | `$BITRISE_GIT_TAG` | The Git tag, if the Build was triggered by a tag push. | | `$GIT_CLONE_COMMIT_MESSAGE_SUBJECT` | The first line of the commit message. | | `$GIT_CLONE_COMMIT_MESSAGE_BODY` | The full commit message body. | | `$BITRISE_IPA_PATH` | Path to the exported `.ipa` file (iOS Builds). | | `$BITRISE_APK_PATH` | Path to the generated `.apk` file (Android Builds). | For the full list of Bitrise environment variables, see the [Bitrise CLI documentation](https://devcenter.bitrise.io/en/references/available-environment-variables.html). --- ### Using Fastlane with Bitrise If your project already uses Fastlane, you can combine Bitrise with the Applivery Fastlane plugin instead of using the dedicated Applivery Step. Add a **Fastlane** Step to your workflow and invoke the lane that calls the `applivery` action: ``` Step: Fastlane Lane: ios deploy ``` In this setup, pass the token via a Bitrise Secret referenced as `$APPLIVERY_APP_TOKEN` and read it in your `Fastfile` as `ENV["APPLIVERY_APP_TOKEN"]`. See the [Fastlane Integration](https://docs.applivery.com/en/app-distribution/ci-cd/fastlane/) guide for full Fastfile configuration. --- ## Fastlane Source: https://docs.applivery.com/en/app-distribution/ci-cd/fastlane/ Description: Automate iOS and Android app releases using Fastlane and the Applivery plugin. Streamline building, testing, and distribution. TL;DR: Automate your iOS and Android app releases to Applivery using the Fastlane plugin, streamlining the build, upload, and notification process. Key topics: Fastlane plugin installation, Fastfile configuration, Applivery API token, iOS deployment with Fastlane, Android deployment with Fastlane, Fastlane, Applivery, iOS, Android, App Store, Google Play, Bitrise, Azure Pipelines, GitHub Actions, Jenkins ![fastlane](https://www.applivery.com/wp-content/uploads/2021/12/fastlane.png "fastlane | Applivery") [Fastlane](https://fastlane.tools/) is an open-source automation tool for iOS and Android developers that handles building, testing, code signing, and releasing Apps. The [Applivery Fastlane plugin](https://github.com/fastlane-community/fastlane-plugin-applivery) extends Fastlane with an `applivery` action that uploads a built binary to Applivery, attaches CI metadata (commit, branch, tag, repository URL), and optionally sends notifications — all in one step. --- ### Prerequisites - [Fastlane installed](https://docs.fastlane.tools/#getting-started) on your system or CI agent. - An Applivery App API Token. Find it in **App Settings → API Tokens** in the Applivery Dashboard, or see [Apps API Token](https://docs.applivery.com/en/app-distribution/api/app-api-token/). - A `Fastfile` in your project with at least one lane defined. --- **Install the Plugin** In your project directory, run: ```bash fastlane add_plugin applivery ``` This adds the plugin to your `Pluginfile` and installs it. Commit the updated `Pluginfile` and `Gemfile.lock` to your repository so the plugin is automatically available on CI. **Configure your Fastfile** Add an `applivery` action to any lane in your `Fastfile`. The only required parameter is `app_token`. All other parameters are optional. #### iOS example ```ruby platform :ios do lane :deploy do # Build the app gym( scheme: "MyApp", export_method: "enterprise" # or "ad-hoc" ) # Upload to Applivery applivery( app_token: ENV["APPLIVERY_TOKEN"], name: "v#{get_version_number} (#{last_git_commit[:abbreviated_commit_hash]})", changelog: last_git_commit[:message], notify_collaborators: true, notify_message: "New build ready for testing", tags: "ios, staging" ) puts "Build uploaded. ID: #{lane_context[SharedValues::APPLIVERY_BUILD_ID]}" end end ``` #### Android example ```ruby platform :android do lane :deploy do # Build the APK gradle(task: "assembleRelease") # Upload to Applivery applivery( app_token: ENV["APPLIVERY_TOKEN"], name: "v#{android_get_version_name}", changelog: last_git_commit[:message], notify_collaborators: true, notify_message: "New Android build available", tags: "android, staging" ) end end ``` #### Running the lane ```bash fastlane ios deploy fastlane android deploy ``` ### Plugin parameters | Parameter | Type | Required | Description | |---|---|---|---| | `app_token` | String | **Yes** | Your Applivery App API Token. Available in **App Settings → API Tokens**. | | `name` | String | No | Human-readable build name shown in the Applivery Dashboard. E.g. `RC 1.0`, `v2.4.0-beta`. | | `changelog` | String | No | Release notes or change description for this Build. | | `notify_collaborators` | Boolean | No | Send an email notification to app Collaborators after the upload. Default: `false`. | | `notify_employees` | Boolean | No | Send an email notification to store employees after the upload. Default: `false`. | | `notify_message` | String | No | Custom message included in the notification email. | | `tags` | String | No | Comma-separated tags to label the Build. E.g. `"staging, sprint-42"`. | | `filter` | String | No | Notification group filter. Comma-separated for AND, pipe-separated for OR. E.g. `"group1,group2\|group3"` means (group1 AND group2) OR (group3). | | `build_path` | String | No | Explicit path to the binary to upload. By default, uses the path produced by `gym()` (iOS) or `gradle()` (Android). | --- ### Shared values After a successful upload, the plugin exposes the resulting build ID as a Fastlane shared value. You can use it in subsequent lane steps — for example, to trigger further automation, update a Publication, or log the result. ```ruby applivery( app_token: ENV["APPLIVERY_TOKEN"] ) build_id = lane_context[SharedValues::APPLIVERY_BUILD_ID] puts "Uploaded build ID: #{build_id}" ``` --- ### Storing the Token securely Never hardcode your App Token directly in the `Fastfile`. Use one of the following approaches depending on your setup: **Environment variable (recommended for CI):** ```ruby applivery( app_token: ENV["APPLIVERY_TOKEN"] ) ``` Set `APPLIVERY_TOKEN` as a secret environment variable in your CI platform (Bitrise, Azure Pipelines, GitHub Actions, Jenkins, etc.). **Fastlane `.env` file (recommended for local development):** Create a `.env` file in your `fastlane/` directory (add it to `.gitignore`): ``` APPLIVERY_TOKEN=your_token_here ``` Fastlane automatically loads `.env` files. Reference the variable the same way: `ENV["APPLIVERY_TOKEN"]`. --- ### Complete Fastfile example A real-world `Fastfile` with separate iOS and Android deploy lanes, using Git metadata for the changelog and build name: ```ruby ## fastlane/Fastfile default_platform(:ios) platform :ios do desc "Build and deploy to Applivery" lane :deploy do increment_build_number(build_number: number_of_commits) gym( scheme: "MyApp-Staging", export_method: "enterprise", output_directory: "./build", output_name: "MyApp.ipa" ) applivery( app_token: ENV["APPLIVERY_TOKEN"], name: "#{get_version_number} (#{last_git_commit[:abbreviated_commit_hash]})", changelog: last_git_commit[:message], notify_collaborators: true, notify_message: "New iOS build — #{git_branch}", tags: "ios, #{git_branch}" ) puts "✅ Uploaded to Applivery. Build ID: #{lane_context[SharedValues::APPLIVERY_BUILD_ID]}" end end platform :android do desc "Build and deploy to Applivery" lane :deploy do gradle( task: "assemble", build_type: "Release" ) applivery( app_token: ENV["APPLIVERY_TOKEN"], name: "#{android_get_version_name} (#{last_git_commit[:abbreviated_commit_hash]})", changelog: last_git_commit[:message], notify_collaborators: true, notify_message: "New Android build — #{git_branch}", tags: "android, #{git_branch}" ) puts "✅ Uploaded to Applivery. Build ID: #{lane_context[SharedValues::APPLIVERY_BUILD_ID]}" end end ``` --- ## GitHub Actions Source: https://docs.applivery.com/en/app-distribution/ci-cd/github-actions/ Description: Integrate Applivery with GitHub Actions to automate Mobile App Distribution. TL;DR: Automate your mobile app distribution to Applivery using GitHub Actions, streamlining the deployment process for iOS and Android builds. Key topics: GitHub Actions setup, Applivery API integration, Fastlane integration, iOS deployment with GitHub Actions, Android deployment with GitHub Actions, GitHub Actions, Applivery, Fastlane, iOS, Android, YAML, curl ![github](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/66677e61-987d-457e-aaa9-3e410e59b73f.png) [GitHub Actions](https://github.com/features/actions) is GitHub's built-in CI/CD platform. Pipelines are defined as YAML workflows stored directly in your repository under `.github/workflows/`, triggered by events such as pushes, pull requests, or manual runs. The Applivery integration with GitHub Actions allows you to automatically upload a new Build to Applivery at the end of each workflow run — making freshly built binaries immediately available to QA teams, stakeholders, or internal users without any manual steps. There are two approaches to integrating GitHub Actions with Applivery: - **Via Fastlane** — recommended if your project already uses Fastlane for building and signing. A single lane call handles building and uploading. - **Via the Applivery Upload API directly** — recommended for any project or when Fastlane is not in use. Uses a `curl` step in your workflow YAML with no additional dependencies. * * * ### Prerequisites Before setting up either approach, make sure you have: - A GitHub repository with Actions enabled. - An Applivery App API Token. Find it in **App Settings → API Tokens** in the Applivery Dashboard, or see [Apps API Token](https://docs.applivery.com/en/app-distribution/api/app-api-token/). - A workflow that produces a Build artifact (`.ipa`, `.apk`, `.aab`, or another supported format). * * * **Store the App Token as a GitHub Secret** Never hardcode your Applivery token directly in a workflow file — it would be committed to your repository and visible to anyone with read access. Store it as a GitHub Secret so it is masked in logs and injected as an environment variable at runtime. 1. Open your GitHub repository. 2. Go to **Settings → Secrets and variables → Actions**. 3. Click **New repository secret**. 4. Set the name to `APPLIVERY_TOKEN`. 5. Paste your Applivery App API Token as the value. 6. Click **Add secret**. Once saved, reference it in your workflow YAML as `${{ secrets.APPLIVERY_TOKEN }}`. :::info If multiple repositories need access to the same token, create an **Organization secret** instead. Go to your organization's **Settings → Secrets and variables → Actions** and follow the same process. ::: **Option A — Integration via Fastlane** This approach is recommended if your project already uses Fastlane. The Applivery Fastlane plugin handles the upload and all metadata in a single lane call. For full plugin documentation, see [Fastlane Integration](https://docs.applivery.com/en/app-distribution/ci-cd/fastlane/). #### Workflow YAML ```yaml name: Build and deploy to Applivery on: push: branches: - develop - main jobs: deploy: runs-on: macos-latest steps: - name: Checkout uses: actions/checkout@v4 - name: Set up Ruby uses: ruby/setup-ruby@v1 with: ruby-version: '3.2' bundler-cache: true - name: Deploy to Applivery via Fastlane run: bundle exec fastlane ios deploy env: APPLIVERY_TOKEN: ${{ secrets.APPLIVERY_TOKEN }} ``` #### Fastfile ```ruby platform :ios do lane :deploy do gym( scheme: "MyApp", export_method: "enterprise" ) applivery( app_token: ENV["APPLIVERY_TOKEN"], changelog: ENV["COMMIT_MESSAGE"], notify_collaborators: true, notify_message: "New build from GitHub Actions", tags: "github-actions, #{ENV["GITHUB_REF_NAME"]}" ) end end ``` **Option B — Integration via the Upload API (without Fastlane)** This approach calls the Applivery Upload API directly from your workflow using `curl`. It works for any platform and requires no additional tooling. #### iOS example ```yaml name: Build and deploy iOS to Applivery on: push: branches: - develop jobs: build-and-deploy: runs-on: macos-latest steps: - name: Checkout uses: actions/checkout@v4 - name: Build iOS app run: | xcodebuild -scheme MyApp \ -configuration Release \ -archivePath build/MyApp.xcarchive \ archive xcodebuild -exportArchive \ -archivePath build/MyApp.xcarchive \ -exportPath build/ \ -exportOptionsPlist ExportOptions.plist - name: Upload to Applivery run: | curl 'https://upload.applivery.io/v1/integrations/builds' \ --retry 5 \ --fail \ -H "Authorization: Bearer ${{ secrets.APPLIVERY_TOKEN }}" \ -F "build=@build/MyApp.ipa" \ -F "versionName=${{ github.run_number }}" \ -F "changelog=${{ github.event.head_commit.message }}" \ -F "tags=github-actions, ${{ github.ref_name }}" \ -F "notifyCollaborators=true" \ -F "notifyMessage=New iOS build from GitHub Actions" \ -F "notifyLanguage=en" \ -F "deployer.name=GitHub Actions" \ -F "deployer.info.commit=${{ github.sha }}" \ -F "deployer.info.branch=${{ github.ref_name }}" \ -F "deployer.info.commitMessage=${{ github.event.head_commit.message }}" \ -F "deployer.info.buildUrl=${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}" \ -F "deployer.info.buildNumber=${{ github.run_number }}" \ -F "deployer.info.repositoryUrl=${{ github.server_url }}/${{ github.repository }}" ``` #### Android example ```yaml name: Build and deploy Android to Applivery on: push: branches: - develop jobs: build-and-deploy: runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v4 - name: Set up JDK uses: actions/setup-java@v4 with: java-version: '17' distribution: 'temurin' - name: Build Android APK run: ./gradlew assembleRelease - name: Upload to Applivery run: | curl 'https://upload.applivery.io/v1/integrations/builds' \ --retry 5 \ --fail \ -H "Authorization: Bearer ${{ secrets.APPLIVERY_TOKEN }}" \ -F "build=@app/build/outputs/apk/release/app-release.apk" \ -F "versionName=${{ github.run_number }}" \ -F "changelog=${{ github.event.head_commit.message }}" \ -F "tags=github-actions, ${{ github.ref_name }}" \ -F "notifyCollaborators=true" \ -F "notifyMessage=New Android build from GitHub Actions" \ -F "notifyLanguage=en" \ -F "deployer.name=GitHub Actions" \ -F "deployer.info.commit=${{ github.sha }}" \ -F "deployer.info.branch=${{ github.ref_name }}" \ -F "deployer.info.commitMessage=${{ github.event.head_commit.message }}" \ -F "deployer.info.buildUrl=${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}" \ -F "deployer.info.buildNumber=${{ github.run_number }}" \ -F "deployer.info.repositoryUrl=${{ github.server_url }}/${{ github.repository }}" ``` * * * ### Advanced: Trigger on tags for Release Builds A common pattern is to trigger the Applivery upload only on version tags (e.g. `v2.4.0`), keeping feature branch Builds separate from release candidates: ```yaml on: push: tags: - 'v*' # Triggers on v1.0.0, v2.4.0-rc1, etc. ``` Combined with `${{ github.ref_name }}` as a tag in Applivery, this makes it easy to filter release Builds from the Dashboard. * * * ### Advanced: Upload only on successful tests Use job dependencies to ensure the Build is only uploaded to Applivery if tests pass: ```yaml jobs: test: runs-on: macos-latest steps: - uses: actions/checkout@v4 - name: Run tests run: ./gradlew test deploy: runs-on: ubuntu-latest needs: test # Only runs if the 'test' job succeeds steps: - name: Upload to Applivery run: | curl ... ``` * * * ### GitHub Actions Context Variables The workflow examples above use GitHub Actions context variables that are automatically available in every workflow: | Variable | Description | | --- | --- | | `${{ github.sha }}` | Full SHA of the commit that triggered the workflow. | | `${{ github.ref_name }}` | Short name of the branch or tag (e.g. `develop`, `v2.4.0`). | | `${{ github.run_number }}` | Sequential run number for the workflow. Useful as a `versionName` in Applivery. | | `${{ github.run_id }}` | Unique numeric ID for the workflow run. Used to construct the Build URL. | | `${{ github.event.head_commit.message }}` | Commit message of the commit that triggered the workflow. Useful as `changelog`. | | `${{ github.server_url }}` | Base URL of the GitHub instance (e.g. `https://github.com`). | | `${{ github.repository }}` | Owner and repository name (e.g. `myorg/myapp`). | | `${{ secrets.APPLIVERY_TOKEN }}` | The Applivery App Token stored as a GitHub Secret. | For the full reference, see the [GitHub Actions context documentation](https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/accessing-contextual-information-about-workflow-runs). * * * ### Key upload parameters reference The `curl` form fields map directly to the Applivery Upload API. The most commonly used parameters: | Parameter | Description | | --- | --- | | `build` | The binary file to upload (`.ipa`, `.apk`, `.aab`). | | `versionName` | Human-readable label for the Build. Using `${{ github.run_number }}` links it to the GitHub run. | | `changelog` | Release notes shown in the Dashboard and notification emails. | | `tags` | Comma-separated tags for filtering Builds. E.g. `github-actions, develop`. | | `notifyCollaborators` | Set to `true` to email app Collaborators on upload. | | `notifyMessage` | Custom message included in the notification email. | | `deployer.name` | CI platform name shown in the Applivery Dashboard. | | `deployer.info.commit` | Git commit SHA. | | `deployer.info.branch` | Git branch or tag name. | | `deployer.info.buildNumber` | Workflow run number. | | `deployer.info.buildUrl` | Direct URL to the GitHub Actions workflow run. | For the complete parameter reference, see [POST – Upload a Build](https://docs.applivery.com/en/app-distribution/api/builds/upload-build/). --- ## Jenkins Source: https://docs.applivery.com/en/app-distribution/ci-cd/jenkins/ Description: Integrate Jenkins with Applivery to automate Build uploads and streamline your Mobile App Distribution CI/CD workflow. TL;DR: Integrate Jenkins with Applivery to automatically upload new builds after each pipeline run, streamlining your mobile app distribution process. Key topics: Jenkins integration, Applivery API, CI/CD automation, build upload, Jenkinsfile configuration, Jenkins, Applivery, HTTP Request plugin, Applivery Upload API, iOS, Android ![jenkins](https://www.applivery.com/wp-content/uploads/2025/02/jenkins-1-1024x316.jpeg "jenkins | Applivery") ## Jenkins Integration [Jenkins](https://www.jenkins.io/) is an open-source automation server widely used for continuous integration and delivery. It orchestrates build, test, packaging, and deployment stages of a software delivery pipeline. The Applivery integration with Jenkins allows you to automatically upload a new Build to Applivery at the end of each pipeline run — making freshly built binaries immediately available to QA teams, stakeholders, or internal users without any manual steps. :::info Applivery does not have a dedicated Jenkins plugin. The integration uses Jenkins' standard [HTTP Request plugin](https://www.jenkins.io/doc/pipeline/steps/http_request/) to call the Applivery Upload API directly. This approach is simpler, more maintainable, and works with any Jenkins version. ::: --- ### Prerequisites Before setting up the integration, make sure you have: - A Jenkins instance with the [HTTP Request plugin](https://plugins.jenkins.io/http_request/) installed. - An Applivery Integration API Token. Find it in **App Settings → API Tokens** in the Applivery Dashboard, or see [Integration API Token](https://docs.applivery.com/en/app-distribution/api/app-api-token/) for instructions on creating one. - A Jenkins pipeline that produces a Build artifact (`.ipa`, `.apk`, `.aab`, or another supported format). --- **Store the App Token as a Jenkins Credential** Never hardcode your Applivery token directly in the `Jenkinsfile`. Store it as a secret credential in Jenkins and reference it via an environment variable. 1. Go to **Jenkins → Manage Jenkins → Credentials**. 2. Add a new **Secret text** credential. 3. Set the ID to `APPLIVERY_TOKEN` (or any name you prefer — just use it consistently). 4. Paste your Applivery App API Token as the secret value. In your `Jenkinsfile`, expose the credential as an environment variable: ```groovy environment { APPLIVERY_TOKEN = credentials('APPLIVERY_TOKEN') } ``` **Add the Upload Stage to Your Pipeline** Add an `Applivery Upload` stage after your Build step. The stage uses the `httpRequest` step from the HTTP Request plugin to call the Applivery Upload API with `multipart/form-data`. ```groovy stage('Applivery Upload') { def response = httpRequest( url: 'https://upload.applivery.io/v1/integrations/builds', httpMode: 'POST', consoleLogResponseBody: true, wrapAsMultipart: true, customHeaders: [ [ maskValue: true, name: 'Authorization', value: "Bearer ${env.APPLIVERY_TOKEN}" ] ], formData: [ // Build file [ name: 'build', fileName: 'app.ipa', uploadFile: './app.ipa', contentType: 'application/octet-stream' ], // Build metadata [name: 'versionName', value: "${env.BUILD_TAG}"], [name: 'changelog', value: "${env.GIT_COMMIT_MSG}"], [name: 'tags', value: 'jenkins, ci'], // Notifications [name: 'notifyCollaborators', value: 'true'], [name: 'notifyEmployees', value: 'false'], [name: 'notifyMessage', value: 'New build available from Jenkins'], [name: 'notifyLanguage', value: 'en'], // Notification group filter (optional) // To notify users in group1 AND group2, OR group3: [name: 'filter[0][0]', value: 'group1'], [name: 'filter[0][1]', value: 'group2'], [name: 'filter[1][0]', value: 'group3'], // CI/CD metadata — appears in the Applivery Dashboard [name: 'deployer.name', value: 'Jenkins'], [name: 'deployer.info.commitMessage', value: "${env.GIT_COMMIT_MSG}"], [name: 'deployer.info.commit', value: "${env.GIT_COMMIT}"], [name: 'deployer.info.branch', value: "${env.GIT_BRANCH}"], [name: 'deployer.info.buildUrl', value: "${env.BUILD_URL}"], [name: 'deployer.info.buildNumber', value: "${env.BUILD_NUMBER}"], [name: 'deployer.info.repositoryUrl', value: "${env.GIT_URL}"] ] ) echo "Applivery upload response: ${response}" } ``` --- ### Complete Jenkinsfile Example Here is a full pipeline example for an iOS build: ```groovy pipeline { agent any environment { APPLIVERY_TOKEN = credentials('APPLIVERY_TOKEN') } stages { stage('Checkout') { steps { checkout scm } } stage('Build') { steps { // Replace with your actual build command sh 'xcodebuild -scheme MyApp -configuration Release archive -archivePath build/MyApp.xcarchive' sh 'xcodebuild -exportArchive -archivePath build/MyApp.xcarchive -exportPath build/ -exportOptionsPlist ExportOptions.plist' } } stage('Applivery Upload') { steps { script { def response = httpRequest( url: 'https://upload.applivery.io/v1/integrations/builds', httpMode: 'POST', consoleLogResponseBody: true, wrapAsMultipart: true, customHeaders: [ [ maskValue: true, name: 'Authorization', value: "Bearer ${env.APPLIVERY_TOKEN}" ] ], formData: [ [ name: 'build', fileName: 'MyApp.ipa', uploadFile: './build/MyApp.ipa', contentType: 'application/octet-stream' ], [name: 'versionName', value: "${env.BUILD_TAG}"], [name: 'changelog', value: "Build #${env.BUILD_NUMBER} — ${env.GIT_BRANCH}"], [name: 'notifyCollaborators', value: 'true'], [name: 'notifyMessage', value: 'New build ready for testing'], [name: 'notifyLanguage', value: 'en'], [name: 'deployer.name', value: 'Jenkins'], [name: 'deployer.info.commit', value: "${env.GIT_COMMIT}"], [name: 'deployer.info.branch', value: "${env.GIT_BRANCH}"], [name: 'deployer.info.commitMessage', value: "${env.GIT_COMMIT_MSG}"], [name: 'deployer.info.buildUrl', value: "${env.BUILD_URL}"], [name: 'deployer.info.buildNumber', value: "${env.BUILD_NUMBER}"], [name: 'deployer.info.repositoryUrl', value: "${env.GIT_URL}"] ] ) echo "Applivery upload response: ${response}" } } } } post { failure { echo 'Build or upload failed.' } } } ``` --- ### Key parameters reference The `formData` array maps directly to the Applivery Upload API parameters. These are the most commonly used ones: | Parameter | Description | |---|---| | `build` | The binary file to upload. Use `uploadFile` for the local path and `fileName` for the filename Applivery will record. | | `versionName` | Human-readable label for the Build. Using `${env.BUILD_TAG}` or `${env.BUILD_NUMBER}` makes it easy to trace in Applivery. | | `changelog` | Release notes shown in the Applivery Dashboard and notification emails. | | `tags` | Comma-separated tags for filtering Builds. E.g. `jenkins, staging`. | | `notifyCollaborators` | Set to `true` to email app Collaborators when the Build is uploaded. | | `notifyEmployees` | Set to `true` to email store employees. | | `notifyMessage` | Custom message included in the notification email. | | `notifyLanguage` | Language for the notification email. Supported values: `en`, `es`, `fr`, `de`, `it`, `zh`, `pt`, `ru`. | | `filter[N][M]` | Group-based notification filter. Each inner array is an AND clause; each outer index is an OR. | | `deployer.name` | CI platform name shown in the Applivery Dashboard. E.g. `Jenkins`. | | `deployer.info.commit` | Git commit SHA. | | `deployer.info.branch` | Git branch name. | | `deployer.info.buildNumber` | Jenkins build number. | | `deployer.info.buildUrl` | Direct URL to the Jenkins build run. | | `deployer.info.repositoryUrl` | URL of the source repository. | For the complete parameter reference, see [POST – Upload a Build](https://docs.applivery.com/en/app-distribution/api/builds/upload-build/). --- ### Jenkins Environment Variables The pipeline examples above use standard Jenkins built-in environment variables. These are available in any pipeline without additional configuration: | Variable | Description | |---|---| | `BUILD_NUMBER` | The current build number. | | `BUILD_TAG` | String of the format `jenkins--`. Useful as a version name. | | `BUILD_URL` | Full URL to the current build in the Jenkins UI. | | `GIT_COMMIT` | SHA of the current Git commit (requires Git plugin). | | `GIT_BRANCH` | Name of the current Git branch (requires Git plugin). | | `GIT_URL` | URL of the Git repository (requires Git plugin). | :::warning `GIT_COMMIT_MSG` is not a built-in Jenkins variable. To use the commit message in the upload, capture it first with a shell step: ```groovy env.GIT_COMMIT_MSG = sh(script: 'git log -1 --pretty=%B', returnStdout: true).trim() ``` ::: --- ## Distribute Source: https://docs.applivery.com/en/app-distribution/distribute/ Description: Applivery App Distribution — manage and deploy Builds across mobile, desktop, web, and console platforms from a single Dashboard. TL;DR: Applivery's App Distribution feature provides a centralized solution for managing and deploying apps across various platforms. Key topics: App Distribution, Applivery Features, Mobile App Deployment, Applivery Make your Apps available to users through Publications, Audiences, and the Enterprise Store. Once a Build is uploaded, you can create a Publication, define its visibility, set access controls, and distribute it to the right people. You'll also find guidance on managing Collaborators and employees, configuring User Groups, and setting up OTP access for external users who don't have an Applivery account. --- ## Distribute Apps Source: https://docs.applivery.com/en/app-distribution/distribute/distribute-apps/ Description: Distribute Apps through Applivery's public and private App Stores. Control access, security, and branding per app and audience. TL;DR: Applivery enables secure app distribution through public and private app stores with flexible access control, including OTP for external users. Key topics: Public App Stores, Private App Stores, Published Apps Configuration, OTP Access, Applivery, Google, Bing, iOS, Android Applivery provides a powerful way to distribute Apps through **Public or Private App Stores** that support multiple security, access control, and branding configurations. You can also have different configurations for each App and each Audience. ### App Stores Applivery supports both **Public** and **Private** App Stores. **Public App Stores**: - Your App Store is publicly available under your URL (`yourname.applivery.com` or your Custom Domain). - Anyone who knows the URL can access the list of published Apps, as long as they are not unlisted or inactive. - Your App Store and its content may be indexed by search engines like Google or Bing. **Private App Stores**: - Your App Store is not available to the general public. Users must authenticate to access the App list. - Users can log in using their Applivery account and/or your Workspace's Single Sign-On (if configured). - The App Store homepage may be indexed by search engines, but content requires authentication. :::tip For Private App Stores, you can completely disable Public Publications. Go to **Enterprise Store > Customize**, find the **Security** section, and disable the **Allow Public Publications** option. If Public Publications already exist, you will be prompted to remove them. ::: ![allow public Publications](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/9424b2ef-d7d0-4dfe-8f12-3002d37959e0.png) In both cases, users will be able to add the App Store to their Home Screen to have more direct and easy access to your Workspace Apps. You can follow the steps described in our articles for both iOS and Android. ### Published Apps For each App project in Applivery, you can create one or more **Published Apps** to control how different Builds are made available to Collaborators, employees, and external users through the App Store. There are four key configuration areas for each Publication: **Build selection** Defines which Build(s) are surfaced by the Publication: | Mode | Behavior | | --- | --- | | **Manual** | Distributes a specific Build from your Build list. Build history is not available in this mode. | | **Tags** | Distributes any Build matching a custom tag or set of tags. | | **Git Tag / Git Branch** | Deploys Builds matching a specific git branch (e.g. `develop`) or git tag (e.g. `3.2.1`). | | **Last** | Always points to the most recent uploaded Build for each OS. | **Visibility** Controls whether and how the Publication appears in the App Store: | Option | Behavior | | --- | --- | | **Inactive** | Not accessible to anyone. | | **Active** | Visible to everyone in the App Store. | | **Unlisted** | Not listed in the App Store, but accessible to anyone with the direct URL. | **Security** Controls the authentication method required to access the Publication: | Option | Behavior | | --- | --- | | **Public** | No authentication required. Anyone with the link can access and download. | | **Private** | Requires login via Applivery account or your Workspace's SSO. | | **Password** | Requires a password you define. No user account needed. | | **OTP (One-Time Password)** | Access is granted via a time-limited code sent by email to a pre-approved allowlist. No SSO or Applivery account required. | **Access control** Optional rules that further restrict who can access a Publication, independent of the security mode: - **User Groups** our **Audiences**: For Private Publications, limit access to specific User Groups or defined Audiences within your Workspace. - **Country restrictions**: Allow or block access based on the user's geographic location. ![create Publication](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/e2491937-01dd-4b0d-b85d-d24b44b68136.png) ### OTP (One-Time Password) access OTP access is a security configuration available for Private Publications that allows you to share Builds securely with external users who are not part of your organization — freelancers, external studios, external QA testers, and similar collaborators — without requiring them to have an Applivery account or go through your SSO. This is especially relevant for organizations with strict SSO-only policies that need to share Builds externally without relaxing their global authentication configuration. OTP access is configured per Publication and does not affect any other Publication or the global App Store authentication settings. :::info OTP is available at the Publication level only — it is not a global login method for the App Store. A user who accesses a Publication via OTP is restricted to that Publication and cannot freely navigate to other parts of your App Store. If they navigate away, they can only return to the same Publication they originally accessed via OTP. ::: #### How it works ##### From the Admin side :::warning OTP can only be configured after the Publication has been created. Open the Publication in edit mode to access OTP settings. ::: :::warning OTP user changes are saved immediately when you click Save inside the OTP panel. You do not need to save the Publication again afterwards. ::: **Open the Publication in edit mode** **Enable OTP access** In the Security section, enable OTP access. **Configure Access Control** In the Access Control section, select who can access the Publication. OTP works with **Every User**, a specific **User Group**, or an **Audience**. **Add users to the OTP allowlist** Open the OTP Users panel and add the email addresses of the external users you want to grant access to. **Configure settings per user** For each user, set the **Download limit**: choose between unlimited downloads or a specific number. Set it to `1` to enforce single-use access. The Downloads field in the OTP Users panel shows the number of downloads remaining, not the number of downloads already made. :::tip Combine OTP with an Expiring Publication to set an absolute deadline on access — no manual cleanup required once the deadline passes. ::: ##### From the external user's side **Enter email address** The user visits the Publication URL and is prompted to enter their email address. **Receive the OTP by email** If their email is on the allowlist, they receive a time-limited OTP via email, valid for **5 minutes**. **Enter the OTP** They enter the OTP to verify their identity and gain access to the Publication. **Access the Publication** Once authenticated, their session remains active for **2 hours**. After that, they will need to request a new OTP to access the Publication again. **Download limit reached (if configured)** If a download limit is configured and the user has reached it, they will not be able to download again unless an admin resets or increases their limit from the OTP Users panel. #### Configuration options | Option | Description | | --- | --- | | Allowlist | The list of email addresses authorized to request an OTP. | | Download limit | Maximum number of downloads allowed per user. Set to `1` to enforce single-use access, or leave unlimited for unrestricted downloads. Admins can update this value at any time from the OTP Users panel. | | OTP expiry | OTPs are valid for exactly 5 minutes and cannot be reused. | | Session duration | After a successful OTP login, the session remains active for 2 hours. | | New Build notifications | When a new Build is published, OTP users on the allowlist can receive a notification email that includes a fresh OTP, letting them download without having to request access again manually. | :::info **New Build notifications** is not yet available. This feature is coming soon. ::: #### When to use OTP access | Scenario | Recommended approach | | --- | --- | | Share a Build with an external freelancer for a one-time review | OTP + download limit set to 1. | | Share a beta with an external QA studio for a limited testing period | OTP + Expiring Publication. | | Distribute to a list of external testers without giving them permanent accounts | OTP + temporary user lifecycle. | | Long-term external collaborators who need ongoing access | Private Publication + Enterprise Store Audience. | :::tip For long-term collaborators who need recurring access to multiple Builds over time, consider using a Private Publication with Audience-based access through the Enterprise Store instead of OTP. OTP is intended for temporary and controlled external sharing scenarios. ::: ### Advanced configuration #### Restricting access to certain User Groups or Audiences When configuring **Private Published Apps** (either using Applivery Login or Single Sign-On), you can also specify which User Groups or Audiences will have access to the App itself. To do so, add the list below the **Access** selector and then click **Save**. ![access groups](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/b4ecd93b-41bc-45c8-a0de-02298d1adb52.png) #### Blocking or allowing access by Country You can define which countries are allowed or blocked from accessing a Publication. Add the country list in the **Access Control** setting of the Publication and save. ### Best practices #### Use separate Publications for different Audiences When distributing to different groups (internal testers, QA, customers, partners, external studios), **create a separate Publication for each Audience**. This keeps access control and visibility independent, and makes it easy to revoke or modify access for one group without affecting others. #### Use Last Build for continuous updates If you upload Builds frequently, avoid creating a new Publication for each one. Instead, set **Build Selection = Last** and enable **Show build history**. This gives you a single Publication that always points to the latest Build, while still providing access to previous versions through the Build history. You can also share a specific Build directly by appending the following to the Publication URL: ``` demo.applivery.io/{pubSlug}/{OS}/{buildId} ``` #### Combine OTP with Expiring Publications for time-limited external access For maximum control when sharing with external users, combine **OTP access** with **Expiring Publications**. This ensures that access is both identity-verified (via OTP allowlist) and time-bounded (via Publication expiry) — without any manual cleanup required once the deadline passes. ![auto expire](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/d9708724-015a-46d3-9585-7995a9e9c52c.png) #### Keep your SSO Policy intact when sharing externally If your organization enforces SSO-only authentication globally, use **OTP access** for external collaborators rather than relaxing your SSO Policy or creating exceptions. OTP operates independently of your global authentication settings and does not interfere with how internal users authenticate. --- ## Manage Users Source: https://docs.applivery.com/en/app-distribution/distribute/manage-users/ Description: Manage users in Applivery App Distribution. Understand Collaborator and Store Employee roles, permissions, and best practices. TL;DR: Applivery user management involves two key user types: Collaborators with administrative access and Store Employees who access apps via the Enterprise Store, each managed with distinct roles and permissions. Key topics: Collaborators, Store Employees, User Roles, Groups and Audiences, User Activity, Applivery, Groups, User Audiences, SSO, SDK, OTP User management is a core component of App Distribution in Applivery. It ensures that the right people have the correct level of access to projects, Apps, and the Enterprise Store. Applivery divides users into two main categories: **Collaborators** and **Store Employees**. Understanding the distinction between them is essential for setting up a secure and well-organised distribution workflow. * * * ### Collaborators Collaborators are users with administrative access to your Workspace and App projects. They operate through the Applivery Dashboard and are responsible for managing Apps, uploading Builds, configuring settings, and overseeing distribution. #### Roles and Permissions Each Collaborator is assigned one of the following roles, which determines their level of access: | Role | Description | | --- | --- | | **Owner** | Super-administrator of the Workspace. Has full access to all resources, including Billing. Only one Owner per Workspace. | | **Admin** | Full administrative permissions over Apps and Workspace settings, except Billing. Can manage other Collaborators. | | **Editor** | Can upload Builds. Has read-only access to Distribution and Settings. Cannot access Billing. | | **Viewer** | Read-only access to all resources, except Billing, Directory, and Settings. | | **Unassigned** | No access at the Workspace level. Can be assigned a specific role at the individual App level. | :::info These roles apply to App Distribution. Device Management uses its own roles, assigned on Segment permissions. See [Custom Collaborator Roles](https://docs.applivery.com/en/platform/roles-permissions/custom-collaborator-roles/). ::: ![Collaborators app management](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/5345d862-0170-471c-9456-67c0fe1bffc4.png) :::tip Follow the principle of least privilege when assigning roles — grant each Collaborator only the access they need to perform their responsibilities. ::: * * * ### Store Employees Store Employees represent the end users who access your Apps through the Enterprise Store. Unlike Collaborators, they do not have access to the Applivery Dashboard — they only interact with the App Store experience. Store Employee accounts can be managed at both the App and Organisation levels, and their access is controlled through Groups, User Audiences, and app-specific permissions. #### Employee origins Store Employee accounts are created through different mechanisms. The origin of an account determines how it was created and how it behaves: | Origin | Description | | --- | --- | | **Dashboard** | Employees manually invited by an administrator from the Dashboard. They receive an email invitation to register their account and access the App Store. | | **SSO** | Employees automatically created the first time they log into the App Store using Single Sign-On. No manual invitation required. | | **SDK** | Named employees (with at least a known email address) created programmatically via the Applivery SDK `bindUser()` method. | | **SDK Temporal** | Anonymous users automatically created by the SDK to identify a Device. Unique per Workspace based on device ID. Expire automatically after **30 days of inactivity**. | | **OTP** | Temporary external users granted access via a One-Time Password at the Publication level. Designed for users who are not part of your organisation and should not require an Applivery account or SSO access. OTP users are scoped to a specific Publication and expire after **30 days** unless configured as persistent. | ![employees app distribution](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ff05aa19-af8b-427f-9b62-170f97373107.png) :::info For more information about SDK users and how `bindUser()` works, see [SDK Users](https://docs.applivery.com/en/app-distribution/sdk/sdk-users/). ::: :::info You can learn more about OTP users by following this [link](https://docs.applivery.com/en/app-distribution/distribute/distribute-apps/#otp-one-time-password-access). ::: * * * ### Groups and User Audiences Collaborators can organise Store Employees into collections to simplify app targeting and distribution at scale. [**Groups**](https://docs.applivery.com/en/app-distribution/distribute/user-groups/) are static collections of Store Employees manually created by administrators. They are well-suited for department-based distribution, temporary project teams, or controlled rollout scenarios where membership is fixed and explicitly managed. [**User Audiences**](https://docs.applivery.com/en/app-distribution/distribute/user-audiences/) are dynamic groups automatically populated based on Store Employee attributes or activity. Membership updates automatically as attributes change, making Audiences ideal for large-scale or evolving distribution scenarios where managing static groups would be impractical. Apps and Publications can be targeted to individual employees, Groups, and User Audiences — or a combination of all three. This allows for precise access control, phased rollouts, and compliance with internal distribution Policies. * * * ### User Activity The **User Activity** view provides visibility into the last login and last action timestamps for every user, whether a Collaborator or Store Employee. - **Logins** update both the last login and last action timestamps. - **Other actions** — such as uploading a Build or installing an App — update the last action timestamp only. Regularly reviewing user activity helps keep the Workspace clean and ensures that inactive or stale accounts are identified and handled appropriately. * * * ### How to invite users To add users to your Workspace, go to the [**Applivery Dashboard**](https://dashboard.applivery.io), navigate to **Settings** 1, and select the **Directory** 2 section from the left-hand menu. From there, choose whether to add a Collaborator or a Store Employee. ![add user](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/e5cc55d8-7c55-4455-912f-45a3937ba866.png) #### Inviting Collaborators The invitation flow for new Collaborators depends on whether the person already has an Applivery account. **New user (no existing Applivery account):** 1. The user receives an email invitation to sign up. Their email address is pre-filled in the registration form. 2. After registering, the user receives a second email to verify their address. 3. Once verified, they are redirected to the login page to enter their new credentials. 4. After logging in, they access the Dashboard. They may need to select your Workspace from the left-hand menu to find the App they were invited to. **Existing user (already has an Applivery account):** The user receives an email notification with a direct link to the Dashboard. They may need to log in first before the link redirects them to the correct App. ![Collaborators flow](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ccc4c04b-f0d5-4e11-b347-fe3ee2eeb73b.webp) #### Inviting Store Employees When a Store Employee is invited, they are directed straight to your Enterprise Store — not the Dashboard. They follow a streamlined onboarding flow to access the Apps they are authorised to install and use. ![employees flow](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/eaa3acd9-d2fc-4c74-9e1d-61627a112f43.png) * * * ### Best Practices - Assign Collaborator roles following the **principle of least privilege** — give each person only the access they need. - Use **User Audiences** for dynamic, attribute-based App targeting rather than maintaining large static groups manually. - Use **Groups** for fixed, intentional groupings such as teams, departments, or beta testers. - **Combine Groups and Audiences** for hybrid distribution strategies — for example, a baseline audience plus an opt-in group for early access. - **Review Store Employee activity regularly** to identify and remove stale or inactive accounts, particularly SDK Temporal users that may accumulate over time. --- ## Progressive Deployment with Tags Source: https://docs.applivery.com/en/app-distribution/distribute/progressive-deployment/ Description: Release Builds gradually to your organization using deployment rings — map each ring to a Publication filtered by tags and promote a single Build from pilot to production. TL;DR: Create one Publication per ring with Build selection set to Tags, assign each ring its own Groups or Audiences, then promote a release by adding the next ring's tag to the same Build. Key topics: Deployment rings, Build tags, Publications, Access control, Applivery, Builds, User Groups, Audiences Releasing a new version to everyone at once means that if something is wrong, everyone finds out at the same time. **Progressive deployment** — also called a staged or ring-based rollout — avoids that by releasing to a small group first and widening the audience only once the version has proven itself. Applivery has no dedicated "rings" feature. You build them out of two things you already have: **tags on Builds** and **Publications that select Builds by tag**. The whole model fits in one sentence: > A ring is a Publication that serves Builds carrying a specific tag. Promoting a release means adding the next ring's tag to the same Build. ### How rings map to Applivery A typical setup uses three rings, though you can use as many as you need:

Ring

Who it reaches

Purpose

Pilot

A handful of people — QA, early adopters

Catch obvious breakage before anyone else sees it

Rollout

One or two departments

Validate against real day-to-day usage

Production

Everyone

General availability

Each ring needs two pieces: - **A tag** that identifies the ring, set on the Publication's Build selection. - **An access rule** — the User Groups or Audiences allowed to reach that Publication. The Build itself carries no notion of a ring. It just carries tags, and the Publications decide what to do with them. :::tip When you upload a Build, tags are sent as a **comma-separated list**, so a comma inside a tag name splits it into two tags. Use hyphens instead: `ring-pilot`, `ring-rollout`, `ring-production`. Pick a convention and stick to it — the tag is what wires everything together. ::: ### Create a ring A ring is an ordinary Publication with **Build selection** set to **Tags**. Create one per ring. #### From the Dashboard **Open your App and go to Published Apps** Create a new Publication. **Set Build selection to Tags** Enter the tag for this ring, for example `ring-pilot`. The Publication will serve any Build carrying that tag. **Set Visibility and Security** For internal rings, **Active** visibility with **Private** security is the usual combination — people sign in with their Applivery account or your Workspace SSO. Use **Unlisted** if you would rather share the ring by direct URL only. **Restrict access** In **Access control**, add the User Groups or Audiences allowed into this ring. See [Choosing who gets each ring](#choosing-who-gets-each-ring) below. **Give it a recognizable slug** For example `myapp-pilot`. The resulting URL is `yourworkspace.applivery.com/{slug}`. You end up with one Publication and one URL per ring, each listening for its own tag. For the full list of Publication settings, see [Distribute Apps](https://docs.applivery.com/en/app-distribution/distribute/distribute-apps/). #### From the API The key parameter is `filter.type` set to `tag`, with `filter.value` holding the ring's tag. Full reference: [POST – Create a Publication](https://docs.applivery.com/en/app-distribution/api/publications/create-publication/). **Integrations API** — scoped to a single App, authenticated with an App API Token: ```bash curl 'https://api.applivery.io/v1/integrations/distributions' \ -X POST \ -H 'Authorization: Bearer YOUR_APP_TOKEN' \ -H 'Content-Type: application/json' \ -d '{ "slug": "myapp-pilot", "security": "logged", "visibility": "active", "filter": { "type": "tag", "value": "ring-pilot" }, "groups": [["qa-team"]], "showHistory": true }' ``` **Workspace API** — Workspace-level, authenticated with a Service Account token: ```bash curl 'https://api.applivery.io/v1/organizations/ORG_ID/stores/STORE_ID/pubApps' \ -X POST \ -H 'Authorization: Bearer YOUR_SERVICE_ACCOUNT_TOKEN' \ -H 'Content-Type: application/json' \ -d '{ "slug": "myapp-production", "security": "logged", "visibility": "active", "filter": { "type": "tag", "value": "ring-production" }, "activateUserAudiences": true, "userAudienceMap": [ { "id": "AUDIENCE_ID", "notifyNewBuildsProcessed": true } ] }' ``` `security` accepts `public`, `password` or `logged`. `visibility` accepts `active`, `inactive` or `unlisted`. ### Choosing who gets each ring Access to a ring is controlled by the Publication's **Access control**, using either User Groups or Audiences. - [**User Groups**](https://docs.applivery.com/en/app-distribution/distribute/user-groups/) are hand-picked collections of people. Best for a pilot ring, where you want to name the exact testers. - [**Audiences**](https://docs.applivery.com/en/app-distribution/distribute/user-audiences/) are defined by rules and update on their own as people join or leave. Best for wider rings, where maintaining a manual list would be a chore. A reasonable starting point:

Ring

Typical access

ring-pilot

User Group — QA team, early adopters

ring-rollout

Audience — a department such as IT or Support

ring-production

Audience — everyone in the Workspace

Via the API, `groups` supports AND/OR logic: each inner array is an AND clause and each outer element is an OR clause, so `[["group1","group2"],["group3"]]` means _group1 AND group2, OR group3_. It only applies when `security` is `logged`. For Audiences, set `activateUserAudiences` to `true` and list them in `userAudienceMap`. ### Promote a Build through the rings Promotion does not involve rebuilding or re-uploading anything. It is the same Build gaining tags: ```text Build #A (v2.0) 1) tags: ring-pilot → visible in pilot only 2) tags: ring-pilot, ring-rollout → now also in rollout 3) tags: ring-pilot, ring-rollout, ring-production → now also in production ``` #### From the Dashboard **Open the Build** Go to **Builds** in your App and select the Build you want to promote. **Add the next ring's tag** Edit its **Tags** and add the tag for the next ring. **Remove the tag from the previous Build** If an older Build still carries that ring's tag, remove it so the ring serves exactly one Build. The Build appears in that ring's Publication as soon as you save. #### From the API Use [PUT – Update a Build](https://docs.applivery.com/en/app-distribution/api/builds/update-build/). :::warning The `tags` field **replaces the entire array**. Include every tag the Build should keep — if you send only the new tag, all the others are dropped. ::: ```bash curl 'https://api.applivery.io/v1/integrations/builds/BUILD_ID' \ -X PUT \ -H 'Authorization: Bearer YOUR_APP_TOKEN' \ -H 'Content-Type: application/json' \ -d '{ "tags": ["ring-pilot", "ring-rollout"] }' ``` The Workspace API equivalent is `PUT https://api.applivery.io/v1/organizations/ORG_ID/apps/APP_ID/builds/BUILD_ID` with a Service Account token. :::tip Keep each ring's tag on **one Build at a time**. When you promote a new Build into a ring, remove the tag from the previous one. That way the version each ring is serving is never ambiguous. ::: ### One Build for all rings, or one Build per ring? Prefer **one Build promoted across rings**.

Approach

What it means

Recommendation

One Build → several rings

Compile and upload once; the same binary moves forward by gaining tags

Preferred

One Build per ring

Compile and upload a separate Build for each ring

Only for specific cases

The single-Build approach wins for three reasons: - **You ship what you tested.** The exact binary your pilot group validated is the one production receives — no rebuild in between to introduce differences. - **Version metadata stays consistent.** Applivery reads version information from the package itself, so one Build means one set of version values across every ring. - **Traceability is simple.** One release equals one Build equals one history. Uploading a distinct Build per ring only makes sense when the rings genuinely need different binaries — different build configurations, different endpoints baked in at compile time, and similar. Otherwise, promote by tag. ### Setting the initial tag at upload time You can save yourself a step by tagging a Build into the first ring as you upload it. This is the natural fit for a CI pipeline, which uploads and drops the result straight into pilot: ```bash curl 'https://upload.applivery.io/v1/integrations/builds' \ -X POST \ -H 'Authorization: Bearer YOUR_APP_TOKEN' \ -F 'build=@myapp.aab' \ -F 'versionName=v2.0' \ -F 'tags=ring-pilot' \ -F 'changelog=Sprint 42 release' ``` The response includes the Build `id`, which you will need to re-tag it later. See [POST – Upload a Build](https://docs.applivery.com/en/app-distribution/api/builds/upload-build/) for the full parameter list. ### Checklist - One Publication per ring, each with **Build selection = Tags**. - A tag naming convention agreed and written down, with no commas. - Access control set per ring — Groups for the pilot, Audiences for the wider rings. - CI uploads new Builds already tagged into the first ring. - Promotion means adding the next ring's tag to the same Build, and removing it from the previous one. --- ## Roll Back a Release Source: https://docs.applivery.com/en/app-distribution/distribute/roll-back-a-release/ Description: Revert a problematic Build in Applivery App Distribution by rebuilding your stable version with a higher version identifier and moving the Publication tag to it. TL;DR: Rebuild your last stable version with a higher version identifier, upload it, and move the ring's tag to the new Build. Remember to lower the SDK forced update threshold if you use one. Key topics: Rollback procedure, Version identifiers, Build tags, Forced updates, Applivery, Builds, Publications, Applivery SDK You shipped a release, something is wrong with it, and you need people back on the version that worked. The instinct is to put the previous Build back into circulation — but that is not enough on its own, because whether a device accepts an older version is decided by the operating system, not by Applivery. The reliable way to revert a release is to **ship forward**: take the code of the last version that worked, rebuild it with a **higher** version identifier than the problematic Build, and distribute that. The code goes backwards; the version number goes forwards. To the device it is an ordinary update, which is exactly why it installs. :::info This approach works on every platform Applivery distributes to. Some platforms would also accept a straight downgrade, but the roll-forward is the one procedure that is safe everywhere — so it is the one worth standardizing on. ::: ### Why you cannot simply re-serve the old Build On Android, the system package manager refuses to install a package whose `versionCode` is lower than the one already installed. The install fails with `INSTALL_FAILED_VERSION_DOWNGRADE`. Android's [manifest documentation](https://developer.android.com/guide/topics/manifest/manifest-element) states the rule plainly: each successive version must carry a higher number. So if you re-tag the old Build, anyone who already installed the problematic version stays stuck on it. The people you most need to fix are precisely the ones the old Build cannot reach. Rebuilding with a higher version identifier sidesteps this entirely. ### The version identifier on each platform Applivery **reads** version information from the package you upload — it is not something you can set in the Dashboard or pass to the API. It has to be set at build time. | Platform | What to increase | Format | | --- | --- | --- | | Android | `versionCode` in your build configuration | Integer — `201` | | iOS / macOS | `CFBundleVersion` in the app's Info.plist | One to three period-separated integers — `2.0.1` | | Windows (MSIX / APPX) | Version in `AppxManifest.xml` | Four-part version | | Custom platforms | `packageVersion` at upload time | Manual | :::warning Apple's `CFBundleVersion` is **not** a plain integer like Android's `versionCode`. It is a string of up to three period-separated integers, so "add one" is not meaningful on its own. If the problematic Build is `2.0.0`, your rollback Build should be `2.0.1` or higher. See Apple's [CFBundleVersion reference](https://developer.apple.com/documentation/bundleresources/information-property-list/cfbundleversion). ::: The user-facing version — `versionName` on Android, `CFBundleShortVersionString` on Apple — has no technical rules. Use it to make the situation legible: keeping `1.9` makes clear which code is running, while `2.0.1` makes clear it is newer than the release it replaces. Pick whichever your users will find less confusing. ### The procedure **Identify the last known-good version** Find the source of the version you are reverting to, and confirm the version identifier of the problematic Build so you know what you have to exceed. **Rebuild it with a higher version identifier** Same code, new version identifier — higher than the problematic Build. This happens in your project configuration or CI pipeline, not in Applivery. **Upload the rebuilt Build** Give it a `versionName` that makes its purpose obvious, such as `v1.9 (rollback)`. Wait for processing to finish before continuing. **Remove the tag from the problematic Build** Open the problematic Build and remove the affected Publication's tag. It stops being served immediately. **Add the tag to the rollback Build** The Publication now serves the rollback Build, and devices see it as an available update. **Lower the forced update threshold, if you use one** See [Watch out for forced updates](#watch-out-for-forced-updates) below. Skipping this step can lock users out of the app entirely. #### Worked example ```text Problem: Build v2.0 · versionCode 200 · live in production · defect found Rollback: Rebuild v1.9 source · versionCode 201 (higher than 200) Upload, then move the production tag from Build 200 to Build 201 ``` A device sitting on `200` receives `201`, treats it as an update, and installs it — but the code it ends up running is the stable 1.9 logic. #### From the API Both tag changes use [PUT – Update a Build](https://docs.applivery.com/en/app-distribution/api/builds/update-build/). :::warning The `tags` field **replaces the entire array**. Send every tag the Build should keep, not just the one you are changing. ::: ```bash ## 1. Stop serving the problematic Build curl 'https://api.applivery.io/v1/integrations/builds/BUILD_ID_PROBLEM' \ -X PUT \ -H 'Authorization: Bearer YOUR_APP_TOKEN' \ -H 'Content-Type: application/json' \ -d '{ "tags": [] }' ## 2. Point the ring at the rollback Build curl 'https://api.applivery.io/v1/integrations/builds/BUILD_ID_ROLLBACK' \ -X PUT \ -H 'Authorization: Bearer YOUR_APP_TOKEN' \ -H 'Content-Type: application/json' \ -d '{ "tags": ["ring-production"] }' ``` The Workspace API equivalent is `PUT https://api.applivery.io/v1/organizations/ORG_ID/apps/APP_ID/builds/BUILD_ID` with a Service Account token. If you use [progressive deployment](https://docs.applivery.com/en/app-distribution/distribute/progressive-deployment/), roll back one ring at a time, starting with the ring where the problem appeared. ### Apple devices behave differently depending on how the app was installed Apple does not document what happens when you install an app whose `CFBundleVersion` is lower than the one already on the device, so we tested it ourselves. On **iOS 26.5**, the same app on the same device behaved in two opposite ways depending on the delivery path: | How the app reaches the device | Installing an older Build | | --- | --- | | **App Distribution** — user installs from the Enterprise Store | The older Build installs normally | | **Device Management** — Build assigned through MDM | The device keeps the newer version | :::warning When an older Build is assigned through Device Management, the device does **not** downgrade — and it does **not** report an error either. The command is accepted, nothing fails, and the newer version simply stays installed. If you are rolling back this way, the Dashboard will not tell you that nothing happened. Verify the installed version before assuming devices are fixed. ::: The practical consequence: - If you distribute through the **Enterprise Store**, you can roll back by simply moving the tag back to the previous Build. No rebuild needed. - If you deploy through **Device Management**, moving the tag is not enough. You have to rebuild with a higher version identifier, exactly as described above. :::info This behavior is not documented by Apple, which means it is not guaranteed to stay the same in future iOS releases. Our test covered a supervised device enrolled through Apple Business. Treat the Enterprise Store shortcut as a convenience, not as something to build automation around — the roll-forward procedure is the one that keeps working regardless. ::: ### Watch out for forced updates If your App embeds the [Applivery SDK](https://docs.applivery.com/en/app-distribution/sdk/) with forced updates enabled, there is a trap here worth knowing about. Forced updates block app usage when the installed version falls below a **minimum version threshold** you configure in the Dashboard. If that threshold is still set to the problematic release, your rollback Build sits below it — and every user who installs it gets locked out of the app by the very fix you shipped. **Lower the threshold as part of the rollback, not after it.** One thing works in your favour: the SDK always updates to the **most recent Build available** for the App, matching only bundle ID or package name. It goes by recency, not by version number, so a freshly uploaded rollback Build is picked up as the update regardless of where its version sits. :::info The SDK does not respect Publication filters, groups, or audiences. If you need the rollback confined to one ring, be aware that SDK-driven updates do not honour that boundary. ::: ### After the rollback - **Keep the problematic Build.** Do not delete it — you will want it to reproduce the defect. Untagging is enough to take it out of circulation. - **Mind the version numbers going forward.** Your next real release has to exceed the rollback Build, not the problematic one. If the rollback was `201`, the fixed release starts at `202`. - **Let people know.** If the Publication notifies its audience, an explicit message speeds things up — users who postponed the previous update may otherwise ignore this one too. :::tip The cleanest way to avoid ever needing this is to catch the defect in a small ring first. See [Progressive Deployment with Tags](https://docs.applivery.com/en/app-distribution/distribute/progressive-deployment/). ::: --- ## User Audiences Source: https://docs.applivery.com/en/app-distribution/distribute/user-audiences/ Description: Use Applivery audiences to manage App Distribution, control user access, and customize Build notifications per release. TL;DR: Applivery audiences enable granular control over app distribution by defining user groups and assigning them to publications for controlled access and notifications. Key topics: Audience creation and configuration, User targeting and group management, Publication assignment and access control, Build notification management, Workspace vs. App-scoped audiences, Applivery, Workspace, App, Publications, SSO, SCIM Audiences are a feature in Applivery that lets you control access to [Publications](https://docs.applivery.com/en/app-distribution/distribute/distribute-apps/) in a scalable, dynamic way. Rather than managing access user by user, Audiences let you define a set of users based on conditions — the [groups](https://docs.applivery.com/en/app-distribution/distribute/user-groups/) they belong to, their email addresses, or both — and assign that set to one or more Publications in a single step. Because Audiences are condition-based, their membership updates automatically as users are added to your Workspace or App. This makes them especially powerful when combined with SSO and [SCIM provisioning](https://docs.applivery.com/en/device-management/integrations/sso/scim-attributes-mapping/), where user directory changes flow through automatically without any manual audience management. In short, an Audience defines who can see, access, and download Builds from a given Publication. ![audiences](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/7661e1b1-0316-41f3-88c8-046010169753.png) :::warning Being part of an Audience does not define a user's role as a Collaborator or Employee. Audiences cannot contain roles (Admin, Editor, Viewer, etc.). Roles must be assigned individually at the Workspace or App level. See [Managing users](https://docs.applivery.com/en/app-distribution/distribute/manage-users/) for more information. ::: * * * ### Key concepts **Audience scope** defines where an audience can be managed and where it will be available for assignment: - **Workspace-scoped** audiences are available across the entire Workspace. You can optionally restrict which Apps are allowed to use them. - **App-scoped** audiences are only available within a specific App. **User search scope** determines where Applivery looks when resolving which users belong to an audience: - **Workspace**: Searches across all users in the Workspace. - **App**: Searches only within the users of a specific App. When creating a Workspace-scoped audience, the user search scope is always set to Workspace. When creating an App-scoped audience, you can choose to search within the App or expand the search to the full Workspace. * * * ### Creating an Audience Audiences can be created from two places: - **Workspace level:** Go to the **Settings** section, and from the left-hand menu, select **User Audiences**. - **App level:** go to **App > Audiences**. Click **\+ Create audience** and fill in the following sections: **Configuration** | Field | Description | | --- | --- | | **Name** | A clear, descriptive name for the audience. | | **Description** | Optional. Useful for documenting the purpose of the audience. | | **Audience scope** | Choose **Workspace** or **App**. If Workspace, you can additionally restrict which Apps this audience will be available in. | **Users targeting** | Field | Description | | --- | --- | | **User search scope** | Choose **Workspace** or **App** to define where Applivery looks for matching users. | | **Groups** | Add one or more User Groups using `AND` / `OR` logic to define the conditions for membership. Membership updates automatically as group membership changes. | | **Emails** | Add individual users by email address. Works for both existing users and new ones. When adding a user who doesn't yet belong to the Workspace or app, use the invite button that appears to send them an invitation in one click. | :::tip As you configure conditions, a live preview of matching users appears at the bottom of the screen, so you can verify the audience resolves as expected before saving. ::: Click **Save** when done. * * * ### Exploring users within an Audience To see which users currently match a given audience, open the Publication list, click the **three vertical dots** menu next to the Publication, and select **View users**. This displays a list of all users who satisfy the audience's conditions at that moment. You can also access this information directly from the audience list view: - Click the **Users** field on any audience row to see the users it targets. - Click the **Pubs** field to see which Publications are using that audience. ![Publication audience](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/eccb266b-0bb9-4691-a0c7-225448582854.png) * * * ### Assigning Audiences to Publications Audiences are used to control access to Private Publications. To assign one: 1. Create or edit a Publication. 2. Set the **Security** to **Private**. 3. Under the **Access** section, select **Audiences**. 4. Add one or more audiences to the Publication. Users who belong to any of the assigned audiences will be able to see and download Builds from that Publication. Users outside the audience will not have access. ![assign audience to Publication](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/7e062b8f-5750-421f-9262-5aed657ed7a9.png) * * * ### Viewing Publications associated with an Audience To see which Publications a given audience is currently assigned to, open the audience detail page and click the Publications count shown at the top of the screen. This gives you a full list of all Publications that reference that audience. ![audience assigned to a Publication](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/83395703-aa64-4bbe-9485-36526b02f896.png) * * * ### Build notifications When creating or editing an audience, you can control whether its members receive email notifications when new Builds are published. Use the **bell icon** (🔔) next to the audience name to toggle notifications on or off per audience. Two important caveats to keep in mind: - **User-level preferences take priority.** If an individual user has disabled notifications in their personal settings, the audience-level setting will not override that. - **App-level notification settings also apply.** You can disable notifications entirely for Collaborators or Employees at the App level by going to **App > Settings > Notifications**. This overrides audience-level notification settings. * * * ### Best Practices - **Use groups as the primary targeting mechanism.** Group-based conditions update automatically, keeping your audiences accurate without manual intervention — especially valuable with SSO and SCIM integrations. - **Use email-based targeting for exceptions.** Add individuals by email when you need to grant access to someone outside of your standard groups, such as an external stakeholder or a one-off reviewer. - **Prefer Workspace-scoped audiences for reuse.** If the same set of users needs access across multiple Apps or Publications, a Workspace-scoped audience avoids duplication and keeps management centralised. - **Use App-scoped audiences for isolation.** When an audience is specific to a single App and should not be reused elsewhere, App scope keeps things tidy and prevents accidental assignment to unrelated Publications. - **Verify membership before saving.** Use the live user preview at the bottom of the audience editor to confirm conditions resolve correctly before publishing the audience. --- ## User Groups Source: https://docs.applivery.com/en/app-distribution/distribute/user-groups/ Description: Use Applivery's group-based access control for App Distribution. Combine AND/OR logic and integrate with SSO (LDAP/SAML). TL;DR: Applivery allows you to control app distribution by granting access based on user group memberships, with support for AND/OR logic and SSO integration. Key topics: Group-based access control, SSO integration (LDAP/SAML), Applivery app distribution, User group synchronization, App store security, Applivery, LDAP, SAML, App Store Applivery lets you control access to your App Store Publications with fine-grained group-based rules, combining `AND` and `OR` logic to match any distribution scenario. * * * ### Overview App Distribution supports three access security modes for Publications — Public, Password, and Private. When a Publication is set to **Private**, users must authenticate before accessing it, either via their Applivery account or a custom Single Sign-On (SSO) integration. Beyond authentication, the Private mode also lets you restrict access to specific **User Groups**. Only users who belong to the configured groups will be granted access after a successful login — everyone else is denied, even with valid credentials. :::info For a full overview of Publication security options, see [How to Distribute Your Apps](https://docs.applivery.com/en/app-distribution/distribute/distribute-apps/). ::: * * * ### Configuring Group-Based Access You can add as many groups as needed and combine them using `AND` and `OR` logic: - **Groups on the same line** are treated as `AND`: The user must belong to **all** of them. - **Each new line** is treated as `OR`: The user must satisfy **at least one** of the lines. #### Example To grant access to users who belong to both `groupOne` and `groupTwo`, **or** to users who belong to `groupThree`: ``` groupOne, groupTwo groupThree ``` This reads as: _(groupOne AND groupTwo) OR (groupThree)_. A user in `groupOne` alone would **not** have access. A user in `groupThree` alone **would** have access. A user in both `groupOne` and `groupTwo` **would** have access. ![groups](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/31745035-443c-407d-b32e-0d130acc0029.png) * * * ### Single Sign-On Group Sync (LDAP and SAML) When your App Store is connected to an SSO provider — via **LDAP** or **SAML** — Applivery automatically captures and syncs User Group membership from your User Directory, including groups defined as Organisational Units (OUs). #### How Syncing Works Group synchronisation happens **every time a user logs in**. At that point, Applivery reads the user's current group memberships from your directory and updates them in the platform. To distinguish SSO-sourced groups from groups created directly in Applivery, synced groups are automatically prefixed: | Source | Prefix | Example | | --- | --- | --- | | LDAP | `ldap:` | `ldap:engineering`, `ldap:qa-team` | | SAML | `saml:` | `saml:developers`, `saml:beta-testers` | | Applivery (native) | _(none)_ | `groupOne`, `groupThree` | This makes it straightforward to use SSO groups in your access rules alongside native Applivery groups — simply reference them with their prefix, for example: ``` saml:qa-team, saml:mobile-testers ldap:contractors ``` #### Important behaviour :::warning **Group sync is login-triggered.** All group memberships for a user are overwritten on every new login based on the current state of your User Directory. If you add or remove a user from a group in your directory, the change will **not** be reflected in Applivery until that user logs in to your App Store again. ::: This means: - Removing a user from a group in your directory does not immediately revoke their access in Applivery. - Adding a user to a new group in your directory does not immediately grant them access in Applivery. - In both cases, the change takes effect on the user's **next login**. * * * ### Best Practices - Use **SSO-prefixed groups** (`ldap:` / `saml:`) for access rules that should stay in sync with your corporate directory automatically. - Use **native Applivery groups** for distribution rules that are managed independently from your directory — such as internal beta testers or project-specific access. - When revoking access, keep in mind the login-triggered sync behaviour — if immediate revocation is critical, remove the user account from Applivery directly in addition to updating your directory. Taking longer than usual. Trying again shortly (attempt 8) --- ## Getting Started Source: https://docs.applivery.com/en/app-distribution/getting-started/ Description: Distribute internal enterprise Apps, manage beta testing, and publish production Builds with Applivery's secure platform. TL;DR: Learn how to get started with app distribution using Applivery, including accessing the dashboard, managing users, and customizing your enterprise app store. Key topics: Applivery Dashboard, Enterprise App Store, User Management, App Distribution Workflow, Applivery, Apple, Android, Windows **App Distribution** is one of the core capabilities of Applivery. Whether you need to distribute internal enterprise Apps, manage beta testing programs, or publish production-ready Builds to employees, Applivery provides a centralized and secure platform to streamline the entire process. ### Accessing the Applivery Dashboard The **Applivery Dashboard** is the administrative console where you and your team manage everything related to application distribution. It is accessible at [https://dashboard.applivery.io](https://dashboard.applivery.io). Users with access to the Dashboard are called **Collaborators**. Collaborators can have different roles and permissions, such as administrative or development access, depending on their responsibilities within the project. End users, referred to as **Store employees**, do not access the Dashboard. Instead, they access your organization’s **Enterprise Store**, where they can download the applications that have been made available to them. :::info You can find more information about user types in the following article from [our documentation](https://docs.applivery.com/en/app-distribution/distribute/manage-users/). ::: Getting started with Applivery is straightforward. Once your Workspace is created, you can begin organizing your applications and publishing them to your users. #### The Dashboard The Applivery Dashboard interface is organized into several key sections that allow you to manage your applications and distribution workflows efficiently. ##### Overview The Overview section is the main landing page of your Workspace. Here you will find: - Download statistics and build activity. - Reports and usage insights. - Employee metrics. - General information about your subscription plan. This section provides a high-level view of your distribution activity and overall Workspace performance. ![app distribution](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/37dd3bfe-5214-481e-a8e3-af36377a488e.png) ##### Apps An **App** in Applivery represents your project container. Each App can store Builds for multiple platforms, including: - Apple (`.ipa`, `.pkg`, `.dmg`). - Android (`.apk`, `.aab`). - Windows (`.msi`, `.exe`, `.msix`, `.appx`, `.msixbundle`, `.appxbundle`). - [Custom build platforms](https://docs.applivery.com/en/app-distribution/platforms/custom-platforms/). From this section, you can: - Create new applications. - Upload and manage Builds. - Update existing versions. - Configure distribution settings. You have full control over your Apps and can decide whether to create a new App for each project or reuse an existing one, depending on your release strategy. The Apps section acts as the technical repository of your binaries and versions. ![Apps app distribution](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/fd213c28-8e5b-4226-8ba4-53340a3d37ad.png) ##### Enterprise Store From this section, you can: - Create new Publications. - Edit existing ones. - Control which Apps are visible to which users. - Manage version rollout strategies. ![enteprise store section](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/839b496e-6eea-4019-8df3-3844dd2f593b.png) ##### Directory and Configuration The **Directory and Configuration** section centralizes the management of users, access control, and Workspace-level settings within Applivery. From this section, administrators can manage both internal Collaborators and end users, define audience segmentation, and configure Enterprise Store customization options. - **Collaborators**: Users who **have access to the Applivery Dashboard**. They can be assigned different roles and permission levels depending on their responsibilities, such as administrative access, App management, or development tasks. Proper role assignment ensures secure operational workflows and prevents unauthorized changes within the Workspace. - **Store Employees**: The end users who **access the Enterprise Store** to download applications. They do not have access to the Dashboard but can authenticate into the Store based on the configured access method. Administrators can manage employee accounts individually or through directory integrations, depending on the organization’s setup. - **User Audiences**: This feature allows administrators to group employees based on attributes. These audiences can then be used to control App visibility within the Enterprise Store, restrict access to specific Builds, and define segmented distribution strategies. This enables granular distribution control and supports complex organizational structures. :::info You can find more information about User Audiences in the following article from [our documentation](https://docs.applivery.com/en/app-distribution/distribute/user-audiences/). ::: - **Store customization**: The Enterprise Store can be fully customized to align with corporate branding. From this section, administrators can configure logo and brand assets, color themes, store naming, and security. This ensures a consistent brand experience while maintaining enterprise-grade security. - **Build Platforms**: This section shows which platforms are currently enabled at the Workspace level (Apple, Android, Windows, or custom platforms). :::warning By default, **iOS and Android** are available for all plans. Workspace admins cannot enable new platforms on their own. If additional platforms are required, you must contact Applivery Support via [**support@applivery.com**](mailto:support@applivery.com) or through **the in-app chat**. ::: ![build platforms](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/50fd1029-f420-41cd-92e5-baaec630f1c1.png) #### The Enterprise App Store The **Enterprise App Store** represents your organization’s Private App Store. This is where your published applications become available to end users (Store employees). It is a web-based App Store that: - Supports multiple authentication and security configurations. - Is fully customizable to match your corporate branding. - Allows granular control over app visibility. ![enterprise app store](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/122d1d74-563d-40a6-ba7a-8f8e4b62f6a0.png) --- ## Android App Store Guide Source: https://docs.applivery.com/en/app-distribution/getting-started/android-app-store-guide/ Description: Access, navigate, and install Apps from your organization's Applivery App Store on Android. Covers login, password recovery, and sharing. TL;DR: This guide explains how to access, navigate, and install apps from your organization's Applivery App Store on Android. Key topics: App Store Login, App Navigation, App Installation, Password Recovery, App Sharing, Applivery, Android, Google Play Protect, Google Chrome ### Access & Login Sometimes you will be required to authenticate in order to access the App Store or a given App. Depending on your organization's configuration, there will be one or multiple Authentication options: 1. **Traditional login or LDAP:** Enter your email or corporate user name and password. Then click the green **Next** button to proceed. 2. **Single-Sign On:** If available, a green button with the text **Login with Company Name** will be displayed at the top of the login screen. Click on it, and you will be redirected to the Single-Sign-On screen where you can securely enter your corporate login credentials. ![login android](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/9b8f1aaa-79ed-464b-8306-c0d4f55b2479.png) #### Recovery password In case you have lost your password, click the **I forgot my password** link from the login screen and **type your email address** in the prompted pop-up. You will receive an email with the instructions to reset your password. ![forgot password android](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/b7d3c7c3-20e0-4e10-93f7-b52e56a8cb1b.png) ### Navigation, Search, Language, and Sharing #### Navigation Once you access the App Store, all Publications you have permission to view will be listed under the **Apps** section. You can adjust how they are displayed—by **Publication**, **App**, or **Build**. ![store display](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/cc3d85e5-db72-4ecd-ab1a-ad431ca6c11b.png) #### Searching Apps You can filter the list of Apps by clicking the magnifier icon at the top. Depending on the tab you are in, you’ll find several filter options, including **version**, **version code**, **slug**, **tags**, **package name**, and **changelog**. ![filter options android](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/3e3ffd20-a34d-4808-97a4-3dee5057b39b.png) #### Change language Applivery is available in 10 different languages. It automatically detects your operating system's default language and applies it if available. If not, the default language (English) will be automatically selected. You can change the language at any time from the **More options > Change language** menu located at the top right of the App Store. ![change language android](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/7536a043-9990-4b56-a614-84b06d952fa5.png) #### Sharing options You can share the link to a given App with others in many different ways (QR Code, URL, or through your favourite native Apps). Once inside an App follow these steps: **Open the App's More Options Menu** Tap the **More options** in the top right menu. **Select the Share Option** From the drop-down menu, select the **Share** option. **Choose Your Sharing Method** All sharing options will be displayed next, including a unique URL and QR code. You can also tap the **Share to…** option to display the native sharing options to share the App with others through the social Apps installed on your Device. ![share android](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/8d949d03-bdf9-4259-9dda-c1a3d85e0b46.png) ### Installing Apps Once inside an App in the App Store: **Tap the Install button** Tap the **Install** green button. **Confirm the download** An alert will be shown from the bottom of the screen requesting confirmation to download the APK file. Click the **OK** button. **Open the downloaded file** Once downloaded, click **Open**. **Confirm the installation** An alert will be shown asking if you want to install the App. Click **Install**. **Bypass Google Play Protect warning** Another alert will be displayed, noting that the App has not been recognized by Google Play. Click **INSTALL ANYWAY**. **Enable Google Play Protect Scanning (Recommended)** Additionally, a third alert could be displayed requesting permission to scan the application through Google Play Protect. We always recommend **SEND** for scanning. #### Unknown sources & Unknown Apps If **Unknown sources** are disabled in your phone, a new alert will be displayed. **Open Settings** Click the **Settings** button. **Enable Unknown Sources** Enable the **Allow from this source** check and click back to continue. ### Add to Home Screen You can add your organization's App Store directly as a standard App in the Home Screen to simplify accessing your company's Apps in a faster way. **Open the App Store URL in Chrome** **Open your organization's App Store URL** (i.e., demo.applivery.com) using **Google Chrome**. **Open Chrome's More Options Menu** Tap the **More options** button at the top right bar. **Select Add to Home Screen** Tap the **Add to Home screen** option from the drop-down menu. **Name the App and Add** Choose a name for the App and click the **Add** button. **Finalize the Addition** Drag & Drop the App icon or tap the **Add automatically** button to finish. You will find your organization's App Store added to the Home Screen of your phone. It will remember your login settings and open in full-screen mode for a better user experience. --- ## iOS App Store Guide Source: https://docs.applivery.com/en/app-distribution/getting-started/app-store-user-manual-ios/ Description: Access, navigate, and install Apps from your organization's Applivery App Store on iOS. Covers login, search, and language settings. TL;DR: Learn how to access, navigate, and install apps from your organization's App Store on your iOS device. Key topics: App Store Access, App Navigation, App Installation, Troubleshooting, Customization, App Store, iOS, Safari, Applivery ### Access & Login Sometimes you will be required to authenticate in order to access the App Store or a given App. Depending on your organization's configuration, there will be one or multiple Authentication options: 1. **Traditional login or LDAP:** Enter your email or corporate user name and password. Then click the green **Next** button to proceed. 2. **Single-Sign On:** If available, a green button with the text **Login with Company Name** will be displayed at the top of the login screen. Click on it, and you will be redirected to the Single-Sign-On screen where you can securely enter your corporate login credentials. ![login ios](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/9f3a3669-f128-45f3-98dd-36be88aca4ad.png) #### Recovery password In case you have lost your password, click the **I forgot my password** link from the Login screen and **type your email address** in the prompted pop-up. You will receive an email with the instructions to reset your password. ![forgot password ios](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/5167de0e-fa2f-4b1a-b819-6490ff04bff8.png) ### Navigation, Search, Language and Sharing #### Navigation Once you access the App Store, all Publications you have permission to view will be listed under the **Apps** section. You can adjust how they are displayed—by **Publication**, **App**, or **Build**. ![store display ios](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/4d429d64-577d-470c-afa9-01735cabba8c.png) #### Searching Apps You can filter the list of Apps by clicking the magnifier icon at the top. Depending on the tab you are in, you’ll find several filter options, including **version**, **version code**, **slug**, **tags**, **package name**, and **changelog**. ![filter ios](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/75feb7ba-cd2f-46f2-b3a6-4f408f8c003e.png) #### Change language Applivery is available in 10 different languages. It automatically detects your operating system's default language and applies it if available. If not, the default language (English) will be automatically selected. You can change the language at any time from the **More options > Change language** menu located at the top right of the App Store. ![change language ios](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/90eaea91-ac2c-4c58-9946-67453bdda71c.png) #### Sharing options You can share the link to a given App with others in many different ways (QR Code, URL or through your favourite native Apps). **Open the App's More Options Menu** Tap the **More options** in the top right menu. **Select the Share Option** From the drop-down menu, select the **Share** option. **Choose your Sharing Method** All sharing options will be displayed next, including a unique URL and QR code. You can also tap the **Share to…** option to display the native sharing options to share the App with others through the social Apps installed on your Device. ![share ios app](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/89aa5c13-d5a3-41b1-95e2-3eb2b59d91d7.png) ### Installing Apps Once inside an App in the App Store: **Tap the Install button** Tap the **Install** green button. **Confirm installation** A confirmation message will be prompted requesting your permission to install the App. Tap **Install**. **Wait for installation** Swipe up to go to your Home Screen. The download and installation process will start, and you will see a progress bar. Wait until the App icon appears to open it. #### Enterprise Apps (Untrusted Enterprise Developer) Depending on the type of certificate used to sign the applications, they may require some additional steps to **trust** the application developer. If, once the App is installed, you see the message **Untrusted Enterprise Developer** when tapping on it, follow the next steps: **Open Settings** Go to **Settings > General**. **Access Device Management** Tap **Settings & Device Management**. **Trust the Developer** 1. Select your **Company name**. 2. Press **Trust Company name**. ### Add to Home Screen You can add your organization's App Store directly as a standard App in the Home Screen to simplify accessing your company's Apps in a faster way. **Open App Store in Safari** **Open your organisation's App Store URL** (i.e., demo.applivery.com) using Safari Web Browser. **Add to Home Screen** 1. Tap the **Share** button on the bottom grey navigation bar. 2. Tap the **Add to Home Screen** option from the prompt menu. 3. Choose a name for the App and click the **Add** button. You will find your organization's App Store added to the Home Screen of your phone. It will remember your login settings and open in full-screen mode for a better user experience. --- ## Create Your First App Source: https://docs.applivery.com/en/app-distribution/getting-started/create-first-app/ Description: Create your first App in Applivery. Set up the App profile, upload Builds, and configure analytics and distribution settings. TL;DR: Learn how to quickly create your first app in Applivery to start managing builds and distribution. Key topics: App creation, Applivery interface, App management, Applivery Applivery is about Apps and Devices. Apps represent one of the most important elements in Applivery. You can manage them on your own which means that you can for instance: - Create a separate App for each different project - Create more than one App for the same project to better manage different versions of the same App or team-level segregation. - Create an App for each different environment you might have to better differentiate between Development, Staging, Quality, or Production Apps. Inside the Apps you’ll find everything related to them: Builds, analytics, user permissions, version management, and distribution options. Let’s start creating a new App. **The Apps section** Click the **\+ Create App** button. ![create app](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/fc2584ec-9e47-4115-8ea1-b06ff1a42b59.png) **Choose App name** Choose an easy-to-identify App name and click **Save**. ![create app form](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/c06bb670-bf5b-4033-8fa8-d6e811569c4e.png) Congratulations! You have successfully created your first App in Applivery. You can now start uploading Builds and managing your App Distribution. --- ## Main Concepts Source: https://docs.applivery.com/en/app-distribution/getting-started/main-concepts/ Description: Key concepts for Applivery App Distribution: Workspaces, Apps, Builds, users, audiences, and Publications — everything you need to start distributing. TL;DR: Learn the core concepts of Applivery's App Distribution platform to streamline mobile app deployment within your organization. Key topics: Workspaces and Apps, Builds and Publications, Users, Groups, and Audiences, Enterprise Store, Integration API and App Tokens, Applivery, iOS, Android, Windows, Integration API, App Token As an introduction to Applivery’s App Distribution, we highly recommend you explore and understand the following basic concepts that will be explained in detail in the following chapters of the documentation, since they represent the very basic concepts of our platform. ### Workspace A **Workspace** is the organizational environment where all Apps, Builds, Collaborators, Store employees, and configurations are managed. Each Workspace operates independently and contains its own distribution structure and access control settings. ### App You can understand an **App** as the equivalent of your project. It acts as a container for all related Builds of the same application, regardless of version or platform (iOS, Android, Windows, or custom). Each App centralizes version management, distribution settings, and Publication controls. ### Build A **Build** is a specific version of an application uploaded to Applivery. Builds are the actual installation files distributed to users, such as: - `.ipa` (iOS). - `.pkg`, `.dmg` (maOS). - `.apk`, `.aab` (Android). - `.msi`, `.exe`, `.msix`, `.appx`, `.msixbundle`, `.appxbundle` (Windows). Multiple Builds can exist under the same App, enabling version control, staged rollouts, and update management. ### Publication A [**Publication**](https://docs.applivery.com/en/app-distribution/distribute/distribute-apps/) determines how and to whom a Build is made available. Publications allow administrators to control: - Which Build is distributed. - Which Store employees or audiences can access it. - Visibility rules within the Enterprise Store. This enables flexible distribution strategies such as internal rollouts, department-based releases, or beta testing scenarios. ### Collaborators and Store employees There are two different types of users in Applivery: - **Collaborators** are users who have access to the Applivery Dashboard. They can be assigned different roles and permission levels, such as administrative access or development permissions. Collaborators manage Apps, upload Builds, configure distribution settings, and control Publications. - **Store employees** represent each end-user who accesses applications through the Enterprise Store. They do not have access to the Dashboard. Their interaction is limited to downloading and installing the applications made available to them. :::info You can find more information about user types in the following article from [our documentation](https://docs.applivery.com/en/app-distribution/distribute/manage-users/). ::: ### Groups A [**Group**](https://docs.applivery.com/en/app-distribution/distribute/user-groups/) is a logical collection of employees within a Workspace. Groups are used to organize users based on criteria such as department, role, location, or project. They simplify application distribution by allowing administrators to assign Publications to multiple users at once instead of managing access individually. Groups help maintain scalable and structured distribution workflows, especially in large organizations where app availability must be segmented across different teams or business units. ### User Audiences A [**User Audience**](https://docs.applivery.com/en/app-distribution/distribute/user-audiences/) is a dynamic group of employees automatically generated based on predefined rules or attributes. Unlike static Groups, which require manual user assignment, User Audiences update automatically when employees meet the defined criteria (such as department, role, location, or custom attributes). This dynamic behavior enables scalable and automated distribution strategies. When publishing an App to a User Audience, any employee who matches the conditions will automatically gain (or lose) access as their attributes change. User Audiences are ideal for large organizations that require rule-based, continuously updated targeting without manual maintenance. ### Enterprise Store The **Enterprise Store** is your organization’s Private App Store. It is a web-based portal where employees can access and download the applications published for them. The Store supports branding customization, security configurations, and audience-based visibility rules. ### Integration API The [**Integration API**](https://www.applivery.com/wp-content/docs/openapi.html#tag/Integration-Builds/paths/~1integrations~1builds~1/get) allows organizations to programmatically interact with Applivery’s App Distribution environment. Through the API, external systems such as CI/CD pipelines, internal portals, or third-party platforms can automate actions, including uploading new Builds or creating or updating Publications. The Integration API enables full automation of App lifecycle processes, reducing manual intervention and ensuring seamless integration with existing enterprise systems. ### App Token An [**App Token**](https://docs.applivery.com/en/app-distribution/api/app-api-token/) is a secure authentication credential used to authorize requests to the Integration API. Each token is generated within the Workspace and linked to a specific App or scope. It allows external systems to securely upload Builds or perform automated distribution actions without requiring full dashboard access. App Tokens should be stored securely and managed following best practices for credential protection, as they grant programmatic access to App-related operations. ### App Distribution vs. Device Management App Distribution is designed for distributing applications to users, regardless of whether their Devices are managed. It can operate independently or be combined with Device Management for more advanced scenarios such as silent installations, policy enforcement, or automated deployments. --- ## Upload Your First Build Source: https://docs.applivery.com/en/app-distribution/getting-started/upload-first-build/ Description: Upload your first App Build to Applivery step by step — from the Dashboard, via API, or CI/CD integration. TL;DR: Learn how to upload your first mobile app build to Applivery through a simple step-by-step process. Key topics: Applivery build upload, Mobile app distribution, Build processing states, Applivery, iOS, Android, IPA, APK, AAB, Bitrise.io, Fastlane, Windows, macOS If you have already [created your first app](https://docs.applivery.com/en/app-distribution/getting-started/create-first-app/), now it’s time to upload your first Build. There are several ways to do it, including automatic ones using our API or 3rd party platforms such as Bitrise.io or Fastlane that allows to automatically deploy your Apps into Applivery in a seamless and effortless way. Since it’s your first time, let’s keep it simple! **Go to your Applications** From the **Apps** section, click the **App** where you want to upload a Build to. ![Apps section](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/0e20f8ac-ba6c-48e4-bce5-6d0d65dcbb03.png) **Upload your Build** You will be redirected to the list of Builds (probably empty right now). Now, click the **\+ Upload Build** button. ![upload build](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ef6457f8-3a2d-426e-b91c-7fbbe8014ce0.png) Click in the greyed area to browse your hard disk and find the package you want to upload that must have one of the following file extensions: - `.ipa` for iOS and iPadOS. - `.pkg` or `.dmg` for macOS. - `.apk` or `.aab` for Android. - `.msi`, `.exe`, `.msix`, `.appx`, `.msixbundle` or `.appxbundle` for Windows. - `.zip` or `.tar.gz` formats are supported across all platforms. :::info These are the default file extensions you can upload to your Workspace. You can read more about **Custom Build Platforms** [here](https://docs.applivery.com/en/app-distribution/platforms/custom-platforms/). ::: ![upload build form](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/aa1ad383-6ee6-4d6b-aefb-64fc15f626f4.png) The modal view will automatically change to allow you to select some additional settings, such as the name of the Build, add some tags, add a changelog, or configure the notification settings. Once you are ready to proceed, click the **Upload** button to start the upload process. ![upload build](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/d328085b-61ab-4e20-82a5-84b1a7e0f8df.png) Once it finishes uploading your Build, you will be back to the list of Builds, and you should find a new row with one of the following states: - **Queued:** The Build is waiting to be processed by our systems. - **Processing:** The package is being processed by our systems. - **Failed:** The package has been analyzed, but we were not able to get any information out of it. You can read more about the Build processing error codes [here](https://docs.applivery.com/en/app-distribution/builds/processing-error-codes/). - **Finished:** The Build has been successfully processed. You will see the App icon (if any) and additional information. Please be patient since it might take a while, depending on the size of your Builds. ![build state](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/fbd89c68-2a97-40a7-bf15-ad988581cb07.png) --- ## Integrations Source: https://docs.applivery.com/en/app-distribution/integrations/ Description: App Distribution Integrations in Applivery: connect with Slack and webhooks for real-time Build notifications and automation. TL;DR: Applivery's app distribution integrates with webhooks and Slack for automated notifications and workflow extensions. Key topics: App Distribution, Integrations, Automation, Webhooks, Slack, Applivery Applivery App Distribution connects with external services to extend automation and keep your team informed. You can trigger custom webhooks on key events or send real-time Build notifications directly to a Slack channel. Configure each integration and customize the events and messages sent to your external tools. --- ## Slack Source: https://docs.applivery.com/en/app-distribution/integrations/slack/ Description: Connect Applivery with Slack to get real-time notifications for new Builds, feedback, and Certificate expirations. TL;DR: Integrate Applivery with Slack to receive instant notifications about new builds, feedback, bug reports, and expiring certificates directly in your Slack workspace. Key topics: Applivery integration, Slack notifications, Mobile app build alerts, Workspace configuration, Applivery, Slack, Build, Feedback report, Bug report, Enterprise certificate ![applivery-slack-macIphone | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/8e0ca2d7-921c-47eb-b6f9-0d4b32d04df1.png) Now you can integrate Applivery with Slack and start receiving notifications when the following events take place: - A new **Build** has been uploaded. - A new **Build** has been processed and is ready to install. - A new **Feedback report** has been received. - A new **Bug report** has been received. - An App **enterprise certificate** is about to expire. Integrating Applivery in your Slack team is quite simple thanks to our Official App, and the configuration will take you less than 1 minute. Just follow the next steps. ### Getting started Slack integration can be configured at the **Workspace** level, so notifications from all Apps and Builds activity within your organization are sent to a specific `#channel` or `@user`. **Navigate to Integrations** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), go to your **Workspace Settings** 1 from the top dropdown menu, then open **Integrations** 2 in the left-hand menu and click the **\+ Create integration** 3 button. ![integrations](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/4f179d05-6d7c-49c5-b654-ba62c802673a.png) **Slack events** Choose the **Slack** option, select the events you want to receive from the list, and then click **Add to Slack** button. ![slack integration](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/71550d3a-3864-4e8f-8c10-f4c9718b14f5.png) **Authorize the integration** Now it’s time to sign into your team, so you’ll need to enter your **Slack account email address** and **Slack password**. After that, select where the messages from Applivery should be posted using the bottom drop-down menu that will display the list of available users and channels under your Slack team. Once done, click the **Allow** button. ![slack-step4-1 | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/92f790ba-de74-448d-9a6a-aee13fa8274c.png) **Manage Slack integrations** You will be automatically redirected to the **Integrations** section, where the new Slack integration should be listed, including all the details you have selected: - **Type:** Slack. - **Configuration:** `#channel` or `@user` that will receive the messages. - **Events:** list of events that will be notified. ![slack-step4-1 | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/92f790ba-de74-448d-9a6a-aee13fa8274c.png) That’s all! You’ll be automatically redirected back to Applivery, and we’ll start sending notifications to your Slack team immediately. **Update Slack integration settings** You can edit your current Slack Integrations at any time by going to the **Integrations section** of your **Workspace** and then clicking one of your existing Slack Integrations. A side panel will be opened, allowing you to choose which events will be posted to your `@users` or `@channels`. You will be able to also delete the integration by clicking the **Delete** button. #### Notification examples ![new-Builds-messages | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/99ca45b9-c2b3-439b-86a2-999d16107ab0.png)![new-feedback-messages | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/265daebc-72c2-4c22-9355-b8cca6b0bbb7.png) **Custom Webhooks** Learn how to configure custom webhooks for advanced integration scenarios. --- ## Custom Webhooks Source: https://docs.applivery.com/en/app-distribution/integrations/webhooks/ Description: Integrate Applivery with webhooks to receive real-time notifications for new builds, feedback, bug reports, and certificate expirations. TL;DR: Integrate Applivery with webhooks to receive real-time notifications about app distribution events like new builds, feedback, bug reports, and certificate expirations. Key topics: Webhook configuration, Event payloads, App distribution events, Integration management, Applivery, HTTP POST, JSON, CI/CD pipelines ![webhooks](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/a78842cc-a70c-4563-8b35-9740ae11e2d1.png) Integrate Applivery with external services using custom webhooks to receive real-time notifications about key App Distribution events. Webhooks allow you to connect Applivery to any external service that accepts HTTP POST requests — CI/CD pipelines, custom dashboards, notification tools, and more. When a relevant event occurs in Applivery, a JSON payload is sent automatically to the URL you configure. For App Distribution, the following events can trigger a webhook notification: - A new **Build** has been uploaded. - A new **Build** has been processed and is ready to install. - A new **Feedback report** has been received. - A new **Bug report** has been received. - An App **enterprise certificate** is about to expire. ### Getting started Webhook integrations can be configured at two levels: - **Workspace** — Notifications from all Apps within your organization are sent to the configured URL. - **App** — Notifications from a specific App only are sent to the configured URL. **Navigate to Integrations** Decide whether you want a Workspace-level or App-level integration. Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/): - For **Workspace**: Go to your Workspace Settings 1 from the top dropdown menu, then open Integrations 2 in the left-hand menu and click the + Create integration 3 button. ![integrations](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/f9d029bf-b26a-4951-9f24-7f1b086ed836.png) - For a specific **App**: Go to the **App Settings** 4 and, from the left-hand menu, select **Integrations** 5. Click the **\+ Create integration** 6 button. ![app integration](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/3c423eaf-87f2-4da8-a4e1-74c2dd765cc9.png) **Configure the Webhook** 1. Select **Webhook** as the integration type. 2. Enter the **URL** that should receive the webhook payloads. 3. Select the **events** you want to subscribe to from the list. 4. Click **Save**. ![webhook configuration](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/e6adcaa6-e8b5-42fd-9616-42021457e409.png) ### Managing Webhook Integrations After saving, you will be redirected to the Integrations section, where your new webhook is listed with a summary of its configuration: - **Type:** Webhook - **Configuration:** The destination URL - **Events:** The list of subscribed events #### Editing a Webhook Go to the **Integrations** section of your Organization or App and click on an existing webhook integration. A side panel will open where you can update the destination URL and the subscribed events. #### Deleting a Webhook Open the webhook integration from the Integrations section and click the **Delete** button in the side panel. ### Event Payloads All webhook notifications are delivered as HTTP POST requests with a JSON body. Use the `action` field to identify the event type and route your processing logic accordingly. _[Accordion]_ Fired when a new Build has been uploaded and queued for processing, but has not yet been processed."> ```json { "action": "build_created", "organization": { "id": "5d4d1391cd523c15f50df235", "name": "Applivery Test", "url": "https://dashboard.applivery.io/test" }, "application": { "id": "5e790ce04faa50cac52e4676", "name": "Awesome App", "url": "https://dashboard.applivery.io/test/apps/awesome-app" }, "build": { "id": "5e79232e98d88ac68cf7d4bc", "url": "https://dashboard.applivery.io/test/apps/awesome-app/builds?id=5e79232e98d88ac68cf7d4bc" } } ``` _[Accordion]_ Fired when a Build has been successfully processed and is ready to install. "> ```json { "action": "build_processed", "organization": { "id": "5d4d1391cd523c15f50df235", "name": "Applivery Test", "url": "https://dashboard.applivery.io/test" }, "application": { "id": "5e790ce04faa50cac52e4676", "name": "Awesome App", "url": "https://dashboard.applivery.io/test/apps/awesome-app" }, "build": { "id": "5e79232e98d88ac68cf7d4bc", "os": "android", "versionName": "", "url": "https://dashboard.applivery.io/test/apps/awesome-app/builds?id=5e79232e98d88ac68cf7d4bc" } } ``` _[Accordion]_ Fired when a new Bug Report has been submitted."> ```json { "action": "bug_created", "organization": { "id": "5c9921fbb9f3bb001cc5c9a9", "name": "Applivery Dev", "url": "https://dashboard.applivery.io/test" }, "application": { "id": "5cd19870cdecf8001bef50b7", "name": "Awesome App", "url": "https://dashboard.applivery.io/test/apps/awesome-app" }, "report": { "message": "This is a Bug message that will be included in the Report along with the technical information of the device", "url": "https://dashboard.applivery.io/test/apps/awesome-app/reports?id=5e7923a976b4b0e9aa4aa6a9" } } ``` _[Accordion]_ Fired when a new Feedback Report has been submitted. "> ```json { "action": "feedback_created", "organization": { "id": "5c9921fbb9f3bb001cc5c9a9", "name": "Applivery Dev", "url": "https://dashboard.applivery.io/test" }, "application": { "id": "5cd19870cdecf8001bef50b7", "name": "Awesome App", "url": "https://dashboard.applivery.io/test/apps/awesome-app" }, "report": { "message": "This is a Feedback message that will be included in the Report along with the technical information of the device", "url": "https://dashboard.applivery.io/test/apps/awesome-app/reports?id=5e7923a976b4b0e9aa4aa6a9" } } ``` _[Accordion]_ Fired when an App enterprise certificate is approaching its expiration date."> ```json { "action": "certificate_application_will_expire", "organization": { "id": "5c9921fbb9f3bb001cc5c9a9", "name": "Applivery Dev", "url": "https://dashboard.applivery.io/test" }, "application": { "id": "5cd19870cdecf8001bef50b7", "name": "Awesome App", "url": "https://dashboard.applivery.io/test/apps/awesome-app" }, "numDays": "5", "team": { "name": "Applivery Test", "identifier": "BJ55L1KAQW" } } ``` :::info The `numDays` field indicates how many days remain before the certificate expires. ::: ### Event Reference | Action | Trigger | | --- | --- | | `build_created` | A new Build has been uploaded and is queued for processing. | | `build_processed` | A Build has been processed and is ready to install. | | `bug_created` | A new Bug Report has been submitted. | | `feedback_created` | A new Feedback Report has been submitted. | | `certificate_will_expire` | An App enterprise certificate is about to expire. | --- ## Platforms Source: https://docs.applivery.com/en/app-distribution/platforms/ Description: End-to-end guidance for publishing and distributing apps across platforms. Applivery natively supports iOS, Android, macOS, and Windows — each with their own platform-specific configuration options. You can also extend distribution to any other platform using Custom Build Platforms. Each supported platform has its own requirements for signing certificates, app bundles, UDID provisioning, and distribution. --- ## Android Source: https://docs.applivery.com/en/app-distribution/platforms/android/ Description: Distribute and manage Android Apps within your organization using Applivery — AABs, signing Certificates, private Apps, and more. TL;DR: Applivery enables secure Android app distribution and management within organizations, covering AABs, signing certificates, and private apps. Key topics: Android App Bundles (AAB), Signing Certificate Management, Private App Distribution, Installation Requirements, Android, Applivery, Android App Bundles, AAB Applivery enables you to securely distribute and manage Android applications within your organization. You can work with Android App Bundles (AAB), manage signing certificates and keystores, distribute self-hosted Private Apps, and handle platform-specific distribution requirements. Whether you're distributing internal enterprise apps or managing a testing program, you'll find the platform-specific guidance you need here. --- ## Android App Bundles (AAB) Source: https://docs.applivery.com/en/app-distribution/platforms/android/aab/ Description: Applivery supports Android App Bundles (AAB) for App Distribution — generate Universal APKs and deploy them to your users seamlessly. TL;DR: Applivery utilizes Android App Bundles (AAB) to create Universal APKs for broad Android device compatibility, with future plans to support Dynamic Delivery. Key topics: Android App Bundles (AAB), Universal APK Generation, Applivery App Distribution, Keystore Configuration, Android App Bundle, Applivery, Universal APK, Google Play, Android, bundletool ## Android App Bundle (AAB) The [Android App Bundle (AAB)](https://developer.android.com/platform/technology/app-bundle) is Android's official publishing format, designed to make App delivery more efficient and flexible. Instead of generating a single APK that works for all Devices, an AAB contains all your App's compiled code and resources and defers APK generation and signing to the distribution platform — resulting in smaller, more optimised installs for end users. Switching to AAB does not require refactoring your code. The format also unlocks modular app development and customisable feature delivery, making it easier to scale and maintain your App over time. ![android-app-bundle | Applivery](https://www.applivery.com/wp-content/uploads/2021/12/android-app-bundle-1024x362.png "android-app-bundle | Applivery") ### How Applivery handles AAB files Google Play uses an App bundle to generate and serve optimised APKs tailored to each Device's specific hardware configuration, so users only download the code and resources their Device actually needs. Applivery's distribution model works differently. Because users typically download Apps through a browser (Safari, Chrome, Firefox, etc.), Applivery does not have reliable access to the Device's hardware configuration at download time, which is a prerequisite for generating a Device-specific optimised APK. To work around this, Applivery uses [Android's official bundletool](https://developer.android.com/tools/bundletool) to extract a **Universal APK** from your App bundle. A Universal APK includes all the code and resources needed to install the App on any supported Android device, regardless of hardware. This means the App will install correctly on all your supported Devices, but the download will be larger than a Device-optimised APK generated by Google Play. #### Current limitations As a result of this approach, some Android App Bundle features are not yet fully supported in Applivery: - **Dynamic Delivery**: Feature-based delivery and smaller device-specific APK sizes are not available, since they require hardware detection at download time. #### What we are working on Our team is actively working on two approaches to bring full AAB support to Applivery: - **Device prediction**: To enable Dynamic Delivery from Applivery App Stores without requiring explicit hardware detection. - **SDK-level hardware detection**: To obtain device hardware information through the Applivery SDK and enable Dynamic Delivery for in-app updates. You can follow the progress of both initiatives on our [public roadmap on GitHub](https://github.com/orgs/applivery/projects/1). * * * ### Configuring Android App Bundle in Applivery To upload and process AAB files, you first need to provide your App's signing configuration so Applivery can generate a valid Universal APK from your bundle. **Add your Keystore configuration** Go to **Settings > Android App Bundle** within the App you want to configure, and provide the following required information: | Field | Description | |---|---| | **Keystore** | The deployment keystore (`.jks` file) used to sign the generated APKs. | | **Keystore password** | The keystore's password. Can be entered as plain text or provided via a `.pwd` file. | | **Keystore alias** | The alias of the signing key to use within the keystore. | | **Key password** | The password for the signing key. Can be entered as plain text or provided via a `.pwd` file. | ![aab](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/67d91b3d-af21-4158-8dbd-7f89a196049e.png) :::info This configuration must be in place before uploading any `.aab` file. Uploads will fail processing if the keystore configuration is missing or incorrect. See [Build Processing Codes](https://docs.applivery.com/en/app-distribution/builds/processing-error-codes/) for error details. ::: **Upload Your AAB File** Once your keystore is configured, you can upload your `.aab` file using any of the following methods: - **Dashboard**: Go to the **Builds** section of your App and select or drag and drop your `.aab` file. - **Upload API**: Use the same upload method as standard APKs. See the [Upload API documentation](https://docs.applivery.com/en/app-distribution/api/builds/upload-build/) for details. - **CI/CD integrations**: Use any of Applivery's existing integrations with popular CI/CD platforms such as Fastlane, Jenkins, Bitrise, or Azure DevOps. Once uploaded, Applivery will automatically process the bundle, extract the Universal APK using bundletool, sign it with your keystore configuration, and make it available for distribution. --- ## Convert Keystore to JKS Source: https://docs.applivery.com/en/app-distribution/platforms/android/convert-keystore-to-jks/ Description: Convert your Android keystore file to JKS format using the keytool command to secure your App signing process. TL;DR: Convert your Android keystore to JKS format using the keytool command for secure app signing. Key topics: Keystore, JKS, keytool command, Android app signing, Android, Java, keytool, Google Play If you are developing an Android application, you might have created a keystore file during the signing process. - **Keystore**: A keystore file in Android development acts as a secure container for storing cryptographic keys and certificates. It is used to sign Android app packages (APKs or Android App Bundles (AABs)) before distribution via app stores like Google Play or directly to users. This signing process ensures that neither the App store nor users receive an App that has been tampered with or modified by unauthorized sources. - **JKS**: JKS stands for Java Keystore, a proprietary file format specific to Java. Keystore files in the `.jks` format are widely used for storing keys in Java-based applications. Follow these steps to convert an existing Keystore file into a JKS file: **Open Terminal or command prompt** Launch your command-line interface (Terminal on macOS/Linux, or CMD/PowerShell on Windows). **Navigate to the Keystore file’s location** Use the `cd` command to navigate to the directory containing your `.keystore` file. **Execute the conversion command** Run the following **keytool** command to create a `.jks` file from your current `.keystore` file: ```bash keytool -importkeystore -srckeystore yourapp.keystore -destkeystore yourapp.jks -deststoretype jks ``` Replace `yourapp.keystore` with the name of your existing keystore file, and `yourapp.jks` with the desired name of the output JKS file. When you execute the command, you’ll be asked to provide the following passwords: - **Source Keystore password**: The password for your current `.keystore` file. - **Destination Keystore password**: The new password for the `.jks` file. **Ensure this password is strong and unique**. Once the command completes successfully, a `.jks` file will be created. This file can then be used to sign your Android app before uploading it. --- ## Self-Hosted Private Apps Source: https://docs.applivery.com/en/app-distribution/platforms/android/self-hosted-private-apps/ Description: Distribute self-hosted private Android Apps through Managed Google Play with Applivery — covers configuration, publishing, and release steps. TL;DR: Distribute your self-hosted private Android apps through Managed Google Play by configuring your app in the Google Play Console, sharing it with your Applivery organization, and configuring the RSA key in Applivery. Key topics: Managed Google Play configuration, Android app distribution, Applivery integration, Google Play Console setup, Private app management, Google Play Console, Applivery, Android, Google, Managed Play Store In addition to the many features the [Managed Play Store provides to manage your Private Apps](https://docs.applivery.com/en/device-management/android/app-management/private-app-distribution/), you can also manage and distribute the Apps you have hosted in Applivery or another platform. There are a few **requirements and steps** that you should follow to enable this feature: 1. You must have an active Android Developer License. 2. You can not use the Google Play Managed accounts that are generated automatically when uploading Apps through your Managed Play Store since these accounts are not – and can not be – linked with an active Android Developer Account. 3. Self-hosted private Apps must be configured in the Google Play Account with an active Android Developer License. Once you are sure you meet them, you can proceed with the following configuration steps: ### Create and configure a new App in your Google Play Console **Create a new App in the Google Play Console** Go to the [Google Play Console](https://play.google.com/console) and log in with your Android Developer account. Once inside, click the **Create app** button and fill out the form. ![google-play-console-create-app | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ccaa35bc-310e-46bf-a032-3077f8d08f45.png) **Complete your Store listing information** Once created, you will be required to complete the App listing information with all the details of the App, including icons, screenshots, descriptions, etc. ![google-play-console-store-listing | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ba9112df-4e40-451a-95ee-8b57f2225642.png) **Make it private and share it with your Applivery Managed Google Play** You should remember that you are creating and uploading an App into your Google Play Account, which is not the same account that you have configured in Applivery, so the next step is quite important: 1. Make your App Private. 2. Share it with the Applivery Managed Play Store. Going back to the **Google Play Console** and inside your App, navigate to the **Setup > Advanced settings** section, go to the **Managed Google Play** tab, and enable the _Restricted access to your App and manage closed testing tracks_ option. Below will appear a new section that will restrict which organizations will have access to your App. Click the **Add organization** button and enter your Applivery Android MDM organization ID. You can find it in your [**Applivery Dashboard**](https://dashboard.applivery.io) by navigating to **Settings**, from the left-hand menu, select **Android Setup**. At the top of that section, you’ll find the Enterprise ID. Make sure you Save the changes. Once done, your App will be available only to the users of your Applivery MDM. ![play-console-share-org | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/6f990c8b-1973-4f5b-9057-2e005d0efee3.png) ### Configure the Applivery Project **Get the RSA Public Key of your App** Now that your App listing is completed, go to the **Monetisation setup > Licensing** section. There you will find the Base64-encoded RSA Public Key of your App that Applivery will use to secure and verify the origin of the downloads from your Managed Play Store. **Copy the string.** You will need it in the next step. ![google-play-console-rsa | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/adedb5c4-63e5-46ed-ba87-f94ca6fcf159.png) **Configure your App in the Applivery Dashboard** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), navigate to your App. Once there, go to the **Settings > Advanced** section. Paste the RSA Public Key under the **Google Play license key** text area. ![google play license key](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/c63eb4b8-c083-4273-9536-fd4a9f0c3f56.png) **Upload a new Build** [Upload a new Android build](https://docs.applivery.com/en/app-distribution/getting-started/upload-first-build/) to your App. Applivery will automatically generate a JSON file that contains all the information of your App. Once the upload is finished, click the Build and **Download JSON** file. ![download json file](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/bd067057-e06d-4589-a652-079a019d2c6e.png) ### Upload and release the App Now that everything is set and still in the Google Play Console, start a new **Production release**. **Choose the JSON file** you just downloaded in the previous step and upload it under the **App Bundles and APKs** section. Complete the rest of the fields. Once ready, click **Save and Review** release to complete the process. Review all the information in the next screen and, once ready, click **Start roll-out to Production** to release your App. Please note that although there is no review by Google of the Self-hosted Private Apps, it will take a few hours for the App to be available to users. ![play-store-release | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/2c9d764c-5064-4ea4-80c4-e9852ed872fb.png) --- ## Unknown Sources Source: https://docs.applivery.com/en/app-distribution/platforms/android/unknown-sources/ Description: Enable App installation from unknown sources on Android safely — covers the Per-App permission model and Google Play Protect behavior. TL;DR: Learn how to safely install apps from unknown sources on Android by granting per-app permissions and relying on Google Play Protect for security. Key topics: Android security, Installing APKs, Unknown sources permission, Google Play Protect, Android, Google Play Store, Applivery, Chrome ![unknown sources](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/f7f20415-e62e-423e-a8f1-3959358b1680.jpeg) Android’s operating system includes a built-in security feature that blocks the installation of Apps from sources outside the Google Play Store. This means if you’re trying to install an App via Applivery for the first time, you might encounter a warning message. #### What you might see When you attempt to install an App from Applivery, a message like this may appear: :::danger Install blocked For your security, your phone currently isn't allowed to install unknown Apps from this source. You can change this in Settings. ::: Prior to Android 8.0 (Oreo), users could enable a global setting to allow installations from unknown sources. However, with the introduction of **Android 8.0** (**API level 26**), this approach shifted to a **per-app permission** model. Now, instead of a single setting, users must grant permission to each App individually to install unknown applications. This change enhances security by ensuring that only trusted Apps can install unknown `.apk` files. For more details, refer to the official Android Developers documentation available at this [link](https://developer.android.com/studio/publish#publishing-unknown). ![device alert unknown sources](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/72ff92cf-d443-4703-9615-36e2c1706888.png) ### How to enable App installation from Applivery To proceed with the installation, follow these steps: **Open Settings** Open your Device’s **Settings**. **Navigate to Apps** Navigate to **Apps** and tap on **Special app access** (this may be under **Advanced** depending on your Device). **Select Install unknown Apps** Select **Install unknown Apps**. **Grant Permission** Here, you’ll find a list of Apps that allow you to request permission to install from unknown sources. To grant access, simply choose the App you’ll be using to download or install the `.apk` (e.g., Chrome or your file manager), then enable **Allow from this source**. :::warning Once enabled, you can retry installing the App. Keep in mind that **enabling this option will allow app installations from all sources, not just Applivery**. ::: ### You're still protected Even if you allow installations from unknown sources, your Device is still protected. [Google Play Protect](https://www.android.com/intl/es_es/play-protect/) will continue to scan Apps for potential threats like malware or harmful behavior, regardless of where they come from. If anything suspicious is detected, the App will be blocked automatically. **App Distribution Platform** Distribute your Apps with a friendly and familiar user interface powered by a fully customizable web-based App Store. Secure your deployments by syncing your user directory and enabling enterprise security through Applivery App Distribution. --- ## Apple Source: https://docs.applivery.com/en/app-distribution/platforms/apple/ Description: Securely distribute and manage iOS applications across your organization with Applivery. Learn about UDID collection, app signing, and troubleshooting. TL;DR: Applivery facilitates secure iOS app distribution and management within organizations, covering UDID collection, app signing, and troubleshooting. Key topics: iOS app distribution, Applivery features, App signing, UDID management, Apple, Applivery, iOS, iOS SDK, UDID Applivery enables you to distribute and manage iOS and macOS applications securely across your organization. You can collect UDIDs for device provisioning, understand app signing types (Ad-Hoc, Enterprise, App Store), troubleshoot installation issues, and work with platform-specific distribution requirements. --- ## App Signing Types Source: https://docs.applivery.com/en/app-distribution/platforms/apple/app-signing-types/ Description: Apple App signing types explained — Ad-Hoc, Enterprise (In-House), Development, and TestFlight: differences, use cases, and limitations. TL;DR: This guide explains the different Apple app signing types (Ad-Hoc, Enterprise, Development, TestFlight) and helps you choose the right one for your app distribution needs. Key topics: Ad-Hoc distribution, Enterprise (In-House) distribution, Development signing, TestFlight, Apple Developer Program, Apple, iOS, macOS, App Store, Applivery, Xcode, Apple Developer Enterprise Program Every iOS and macOS app must be cryptographically signed before it can be installed on a Device. The signing type determines who can install the App, on how many Devices, how the App is distributed, and what certificates and provisioning profiles are required. Applivery supports **Enterprise (In-House)**, **Ad-Hoc**, **Development**, and **TestFlight** signed Apps. Choosing the right signing type for your use case is one of the first decisions you need to make when setting up your distribution workflow. :::warning The details below are defined by Apple and may change at any time without notice. Always refer to [Apple's official documentation](https://developer.apple.com/programs/) for the most current information. ::: * * * ### Signing types at a glance | Profile type | Audience | Device limit | Build expiry | Certificate validity | Cost | | --- | --- | --- | --- | --- | --- | | **Ad-Hoc** | Specific registered Devices | 100 Devices | 1 year | 3 years | $99 / year | | **Enterprise (In-House)** | Employees and collaborators of the organisation | Unlimited | 1 year | 3 years | $299 / year | | **Development** | Registered developer Devices | 100 Devices | 1 year | 3 years | Free (included with Apple Developer Program) | | **TestFlight** | Registered testers (internal or external) | 10,000 testers | 90 days per build | N/A | $99 / year | * * * ### Ad-Hoc Ad-Hoc distribution allows you to install a signed app on a specific set of pre-registered Devices. It is the most common signing type for distributing pre-release Builds to a controlled group of testers or stakeholders. #### How it works Before signing the App, you collect the UDIDs of every Device that needs to install it and add them to a provisioning profile. The signed app can then only be installed on those specific Devices. #### Key characteristics - Requires knowing the UDID of every target device in advance. - Device registration and provisioning profile updates are needed every time you add a new Device. - Maximum of **100 Devices** per Apple Developer account (shared across Ad-Hoc and Development profiles). - Builds expire after **1 year** from the signing date. #### Best for Small to medium internal test groups, QA teams, and client preview distributions where you have a defined and manageable list of target Devices. * * * ### Enterprise (In-House) The Apple Developer Enterprise Program allows organisations to sign and distribute Apps internally to an **unlimited number of Devices**, without going through the App Store or registering individual device UDIDs. #### How it works Apps are signed with an Enterprise certificate and can be installed on any Device belonging to the organisation, as long as the Device trusts the organisation's certificate. Users typically install the App via a direct link or an internal distribution platform such as Applivery. #### Key characteristics - No device UDID registration required. - No device limit — suitable for large-scale internal rollouts. - Apple requires that Apps distributed this way are **only used by employees or official collaborators** of the organisation. Distribution to the general public is a violation of Apple's terms and may result in certificate revocation. - Builds expire after **1 year** from signing; the Enterprise certificate itself lasts **3 years**. - Requires [Apple Developer Enterprise Program](https://developer.apple.com/programs/enterprise/) membership, which is subject to Apple's approval process. #### Best for Large organisations distributing proprietary internal Apps across their entire employee base without App Store involvement. :::warning Enterprise certificates carry significant responsibility. If Apple detects misuse — such as distributing Apps to users outside the organisation — they may revoke the certificate, immediately breaking all Apps signed with it across every Device where they are installed. ::: * * * ### Development The Development signing type is primarily intended for testing Apps during the development process on a small set of known Devices. It works similarly to Ad-Hoc in terms of device registration requirements. #### How it works A Development provisioning profile is created containing the UDIDs of specific Devices. The signed app can only be installed on those registered Devices. Xcode is typically used to deploy directly, though the `.ipa` can also be distributed manually. #### Key characteristics - Requires registering each target device's UDID in the provisioning profile. - Maximum of **100 Devices** (shared with Ad-Hoc across the Apple Developer account). - For **macOS Apps**, Development signing is the only way to distribute an Apple Developer Program-signed app for testing outside the Mac App Store. - Free with any Apple Developer Program membership. #### Best for Developer testing during the Build phase, or distributing macOS test Builds to a small internal team. * * * ### TestFlight TestFlight is Apple's official beta testing platform, integrated into the App Store ecosystem. Unlike the other signing types, TestFlight does not use a traditional provisioning profile — Apple manages distribution directly after you submit the Build. #### How it works You upload your App to App Store Connect, where it goes through a review process before being made available to testers. Testers install the TestFlight app and access your Build through it — they cannot install the `.ipa` directly. #### Key characteristics - Requires an [Apple Developer Program](https://developer.apple.com/programs/) membership ($99/year). - Builds are available for **90 days** before expiring automatically. - Supports up to **10,000 external testers** via email invitation or a public link. - Internal testers (up to 100) can receive Builds immediately without App Store review. - External testers require a Beta App Review before they can access the Build. - Cannot be used to distribute an `.ipa` directly — testers must use the TestFlight app. #### Best for Large-scale beta testing programmes, external user research, and pre-release validation before App Store submission. * * * ### Choosing the right Signing Type | Scenario | Recommended signing type | | --- | --- | | Distributing to a small QA team with known Devices | Ad-Hoc | | Distributing an internal app to all employees at scale | Enterprise (In-House) | | Testing a Build on your own development device | Development | | Distributing macOS test Builds outside the Mac App Store | Development | | Running a large-scale beta programme with external testers | TestFlight | | Releasing an App to the general public | App Store _(not supported on Applivery)_ | * * * ### A note on App Store Signing App Store signing is a separate type. It is exclusively for Apps intended for public distribution through the official Apple App Store and **cannot be used on Applivery**. MDM systems and enterprise distribution platforms like Applivery are designed to manage and deploy private or internal Apps — not Apps published on the App Store. * * * ### Further Reading - [Apple Developer Program](https://developer.apple.com/programs/) - [Apple Developer Enterprise Program](https://developer.apple.com/programs/enterprise/) - [TestFlight overview](https://developer.apple.com/testflight/) - [Provisioning profiles — Apple documentation](https://developer.apple.com/documentation/xcode/distributing-your-app-to-registered-devices) --- ## Debug iOS App Installation Source: https://docs.applivery.com/en/app-distribution/platforms/apple/debug-ios-app-installation/ Description: Troubleshoot iOS app installation failures using Xcode. Connect your device, access the console, and analyze logs to identify and resolve issues. TL;DR: Use Xcode to debug iOS app installation issues by analyzing device logs and filtering for the `installld` process. Key topics: Xcode, iOS debugging, App installation, Device logs, Apple, iPhone, iPad, Applivery, iOS, Mac In case all the previous options fail for you, we recommend you debug the installation process of your App. You will need the following: - A real Apple device (iPhone or iPad). - A USB cable. - A Mac. - Xcode is installed on your Mac. :::info These issues can not be addressed by our Engineering team since we do not have access to your source code or your Apple Developer Portal. ::: **Connect your Device to a Mac and Open Xcode** Start by connecting your Apple device to your Mac. An alert might be prompted, requesting you to **Trust** your computer. Click **Trust** to continue. Once done, open **Xcode** on your Mac and select **Window > Devices and Simulators** from the top bar menu or use the following shortcut **Shift + Command + 2**. ![xcode-window | Applivery](https://www.applivery.com/wp-content/uploads/2021/12/xcode-window-1024x805.png "xcode-window | Applivery") **Open device console** Once your Device has been recognized by Xcode, select it from the left side menu under the **Devices > Connected** section and then click the **Open Console** button. ![Devices-and-simulators | Applivery](https://www.applivery.com/wp-content/uploads/2021/12/devices-and-simulators-1024x597.png "devices-and-simulators | Applivery") **Find the appropriate logs** A new screen will be opened. Make sure your iOS device is selected from the left side menu and then click the **Start** button at the top. The logs will start being printed on the screen. In the top-right search box, you can filter by `Process: installd`, which is the name of the process responsible for the installation of Apps on your Device. Now, on your **iOS device, go to the Applivery App Store and start a new installation of the App**. Several logs should appear; read them carefully to understand exactly where the installation issue is. You can click each line to get the full error log message at the very bottom of the screen. ![xcode-console | Applivery](https://www.applivery.com/wp-content/uploads/2021/12/xcode-console-1014x1024.png "xcode-console | Applivery") --- ## Exclude SDK from iOS Production Builds Source: https://docs.applivery.com/en/app-distribution/platforms/apple/exclude-sdk-ios-production/ Description: Exclude the Applivery SDK from your iOS production Builds using Xcode configurations and compiler flags to prevent App Store rejection. TL;DR: Exclude the Applivery SDK from your iOS production builds using Xcode configurations and compiler flags to avoid App Store rejection. Key topics: Xcode Configuration Files, Build Settings, Compiler Flags, Conditional Compilation, Applivery SDK Exclusion, Applivery SDK, iOS, Xcode, Apple App Store, Google Play As you may already know, it’s not allowed to use the Applivery SDK in production Apps that are released in the official Apps Stores (Google Play and Apple App Store). In addition, it is a practice that we do not recommend, and that could cause the rejection of your App during the review process. You can conditionally exclude the Applivery SDK based on the Environment of the App (i.e., Live, Test, Staging, or Quality). :::info You need to know the basics of how to manage different environments by using Schemas and Configurations. If you don't, take a look at the following [blog post](https://www.freecodecamp.org/news/managing-different-environments-and-configurations-for-ios-projects-7970327dd9c9/). ::: **Create Configuration Settings Files (.xcconfig) for Each of Your Environments** Go to **File > New > File… (Command + N) -> Configuration Settings file** and choose a descriptive name for your configuration file. For this example, we will create two different Configuration Files: one for the development environment (`DEV.xcconfig`) and another one for the production environment (`PROD.xcconfig`). **DEV.xcconfig** ``` // App Info APP_NAME = My Awesome App [DEV] BUNDLE_IDENTIFIER = com.acme.awesome.dev // Environment ENVIRONMENT = DEV // Applivery Options APPLIVERY_TOKEN = b7C...2I6 ``` **PROD.xcconfig** ``` // App Info APP_NAME = My Awesome App [PROD] BUNDLE_IDENTIFIER = com.acme.awesome.prod // Environment ENVIRONMENT = PROD // Applivery Options APPLIVERY_TOKEN = 1gxC...66f EXCLUDED_SOURCE_FILE_NAMES = Applivery.framework ``` Since we do not want the Applivery SDK to be included in the Production Environment, we have added the following line of code `EXCLUDED_SOURCE_FILE_NAMES = Applivery.framework` that will exclude the source files of the Applivery SDK during the process of building the App. Additionally, we will take advantage of this Configuration File to also define a different Applivery SDK Token for each of the environments. **Link the Configuration Files with Your Project Schemas** Now that we have multiple configuration files that describe the particularities of your Environments, it’s time to link them with your project Schemas. To do so, under your **Project Configurations settings**, select the appropriate Configuration File by using the **Build Configurations** dropdown menu. ![ios-sdk-configurations-002 | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/4b937ac6-bcfa-44a2-bd33-d5469e2c6cad.png) **(Optional) Use Configuration File Variables in Your Code** ![ios-sdk-configurations-003 | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/a4d9fc97-2ef7-4354-9d7a-19f3d584b8ca.png) Additionally, to use the `Info.plist` **Keys** in your code, you can follow the next approach: ```swift // Get values from Info.plist public func InfoDictionary(_ key: String) -> String { guard let constant = Bundle.main.infoDictionary?[key] as? String else { return "CONSTANT NOT FOUND" } return constant } // Example of usage of the above function when starting the Applivery SDK applivery.start(token:InfoDictionary("APPLIVERY_TOKEN"), appStoreRelease: false) ``` **Conditionally use the SDK** Since the **Import** of the Applivery SDK has been excluded from the `.xcconfig` file when building the code, we recommend using **Swift Compiler Custom Flags and Active Compilation Conditions** to declare a set of constants that will help you conditionally start the Applivery SDK. Here is an example: ```swift #if !APPSTORE import Applivery #endif struct AppliveryWrapper { func setup() { #if !APPSTORE && !DEBUG let applivery = Applivery.shared applivery.logLevel = .info applivery.start(token:InfoDictionary("APPLIVERY_TOKEN"), appStoreRelease: false) #endif } } ``` ![ios-sdk-configurations-004 | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/88f9c11a-9677-4a6c-8986-d5d090a0a574.png) Alternatively, if you do not want to use Configuration Files, you can exclude certain **Source File Names** under the **Build Settings** of your project for each of your Project Schemes. :::tip Remember to thoroughly test your App in all environments to ensure the Applivery SDK is correctly excluded from production Builds. ::: --- ## UDID Collection Source: https://docs.applivery.com/en/app-distribution/platforms/apple/udid-collection/ Description: Collect iOS Unique Device Identifiers (UDIDs) with Applivery to distribute beta and alpha Builds to specific devices. TL;DR: Applivery simplifies iOS UDID collection for beta app distribution through its enterprise app store, enabling developers to easily gather device identifiers for provisioning profiles. Key topics: UDID collection, iOS beta distribution, Applivery Enterprise App Store, Provisioning profiles, Applivery, iOS, Apple, iTunes, Safari :::warning This is a premium feature that might not be available in your current plan. Check the availability on our [pricing page](https://www.applivery.com/pricing/). ::: UDID is the abbreviation for **Unique Device Identifier**. It is a value of 40 alphanumeric characters and is used by Apple for device registration. UDIDs are required if you want to install alpha or beta versions of iOS Apps before they are released to the official Apple Store. Developers require these identifiers to include them in the Provisioning Profiles of the alpha and beta Apps before they are signed and distributed to you. You can always connect your iPhone / iPad to your computer and get the UDID, IMEI, and other details using iTunes. However, Applivery provides an easy and friendly way to collect UDIDs through the Applivery Enterprise App Stores, in a fully-branded and guided web-based environment. :::info Applivery provides the feature of UDID collection. Once collected, you must add the UDIDs to the provisioning profile, and you are responsible for code signing and package generation. ::: ### How it works Once the UDID collection feature is enabled in your organization, you can start collecting UDIDs from your Enterprise App Store URL, depending on whether you use a custom domain or subdomain: - `{workspace_slug}.applivery.io/collect` - `your-apps-tore-domain.com/collect` - `your.app-store-subdomain.com/collect` :::info Users will be requested to use **Safari** to browse this site since this is mandatory to install the required Profiles. ::: Once there, users just have to follow the different steps: **Download the Profile** Click the **Download** button to start the profile download. **Allow Profile Download** **Allow** Profile Download when prompted. **Install the Profile** Go to **Settings > Profile downloaded** and click **Install**. Below you can see the entire process: ![udid collection part 1](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/02e88757-c8f4-4993-9e91-69ba6eb82eca.png)![udid collection part 2](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/433b84be-7353-4afd-ab7a-7227e50f63f3.png) ### Retrieving UDIDs All registered UDIDs will be automatically stored in your account under the **Inventory** section. The records will provide the following information: - Device name. - Serial number. - UDID. - Collection date. In the cases where authentication is enforced at the Store level, the records will also come with the email address of the user who authorized the collection. You can also use the **Download CSV** button to trigger the download of all the records in a single CSV file. Additionally, you can take a look at the [GET method of the Inventory API entity](https://api.applivery.io/openapi#tag/InventoryItem/paths/~1organizations~1:organizationId~1inventory-items~1/get). --- ## Untrusted Enterprise Developers Source: https://docs.applivery.com/en/app-distribution/platforms/apple/untrusted-enterprise-developer/ Description: Fix the "Untrusted Enterprise Developer" error on iOS by manually trusting the Enterprise Developer certificate on your device. TL;DR: To run beta apps on iOS, you must trust the Enterprise developer certificate in Settings > General > Device Management. Key topics: iOS Device Management, Enterprise App Installation, Trusting Developers, iOS, Apple, Enterprise Developer, Device Management Since iOS 9, testers are required to _trust_ your organization’s Apple Enterprise developer certificate before running Beta distributions. This is a one-time process. When running an App from an untrusted certificate, testers will see the message **Untrusted Enterprise Developer**. They can trust the certificate by following the steps below: **Navigate to Device Management** Go to **Settings** > **General** > **Device Management** on your iOS device. **Select the Developer Profile** Locate and select the developer profile under the **ENTERPRISE APPS** section. **Trust the Developer** Tap **Trust "\[Developer Name\]"**. **Confirm Trust** Select **Trust** to confirm. ![untrusted enterprise developer](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/75b3c86e-c26f-4a71-861c-e4528de1a7c2.png) Remember to only trust Enterprise developers that you know and trust. --- ## Custom Build Platforms Source: https://docs.applivery.com/en/app-distribution/platforms/custom-platforms/ Description: Custom Build Platforms in Applivery extend App Distribution beyond mobile — distribute Builds for game consoles, web runtimes, and more. TL;DR: Applivery's Custom Build Platforms allow you to distribute builds to any platform, including game consoles and web runtimes, using the same Applivery workflow. Key topics: Custom Platform Configuration, Build Upload Process, Metadata Requirements, API Integration, Supported Platforms, Applivery, Android, iOS, macOS, Windows, PlayStation, Xbox, Nintendo Switch, Steam, Upload API By default, Applivery natively supports Android, iOS, macOS, and Windows Builds. **Custom Build Platforms** extends this to cover any platform your team distributes to — including game consoles, alternative storefronts, web runtimes, and archive formats — all managed through the same Applivery workflow. This is particularly useful for game studios, cross-platform development teams, and organisations distributing to Devices or environments outside the four major mobile and desktop operating systems. * * * ### Key capabilities **Extended platform support** — upload and distribute Builds for platforms beyond iOS, Android, macOS, and Windows, including PlayStation, Xbox, Nintendo Switch, Steam, and more. **Manual metadata configuration** — unlike native platforms, where Applivery extracts metadata automatically from the Build file, Custom Platforms require you to provide `packageName`, `packageVersion`, and optionally `packageIcon` manually at upload time. **Unified management** — all Builds, regardless of platform, are managed in the same Applivery Workspace and accessible through the same [Upload API](https://docs.applivery.com/en/app-distribution/api/builds/upload-build/), keeping your distribution workflow consistent across every target. **Raw file distribution** — Custom Platforms distribute build files in their original format without automated processing, giving you full control over what gets delivered. * * * ### Supported platforms and file extensions Every custom platform supports `.zip` and `.tar.gz` as universal container formats. Platform-specific supported extensions are listed below: | Platform identifier | Supported extensions | | --- | --- | | `android` | `.apk`, `.aab` | | `amazon` | `.apk`, `.aab` | | `flexion` | `.apk`, `.aab` | | `ios` | `.ipa` | | `macos` | `.pkg`, `.dmg` | | `macos-archive` | `.zip`, `.tar.gz` | | `windows` | `.msi`, `.exe`, `.msix`, `.appx`, `.msixbundle`, `.appxbundle` | | `windows-archive` | `.zip`, `.tar.gz` | | `ps4` | `.pkg` | | `ps5` | `.pkg` | | `switch` | `.nsp` | | `xbox-one` | `.zip`, `.tar.gz` | | `xbox-series` | `.zip`, `.tar.gz` | | `steam` | `.zip`, `.tar.gz` | | `steam-mac` | `.zip`, `.tar.gz` | | `epic` | `.zip`, `.tar.gz` | | `epic-mac` | `.zip`, `.tar.gz` | | `web` | `.unityweb`, `.wasm`, `.js`, `.html` | :::info All platforms also accept `.zip` and `.tar.gz` as generic archive formats, regardless of the extensions listed above. ::: * * * ### How to upload a Build for a Custom Platform **Upload your file** Follow the standard build upload process described in [How to upload your first build](https://docs.applivery.com/en/app-distribution/getting-started/upload-first-build/). You can upload via the Dashboard or the [Upload API](https://docs.applivery.com/en/app-distribution/api/builds/upload-build/). If you are uploading a `.zip` or `.tar.gz` file that does not correspond to a native platform, Applivery will prompt you to select the target Custom Platform in the next step. **Select the Custom Platform** After uploading, select the platform the Build is intended for from the Custom Platform selector. This tells Applivery how to categorise and display the Build within your Workspace. ![upload build for custom platform](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/a8a00bf3-bb23-4ec0-a6c6-c5e53272d447.png) **Provide build metadata** Because Custom Platforms do not undergo automated metadata extraction, you must supply the following information manually: | Field | Required | Description | | --- | --- | --- | | `packageName` | Yes | The unique identifier for your App or build (e.g. `com.studio.mygame`). | | `packageVersion` | Yes | The version string for this Build (e.g. `1.4.2`). | | `packageIcon` | No | An icon image to represent the Build in the Applivery interface. | ![required fields custom platforms](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/11476b4f-43fb-4357-9a0b-236b5c36fa6d.png) Once submitted, the Build will appear in your App's Builds section alongside any other Builds for that project. * * * ### How to enable Custom Platforms Custom Build Platforms are not enabled by default and must be activated at the Workspace level. To view your currently enabled platforms, go to the [**Applivery Dashboard**](https://dashboard.applivery.io), navigate to the **Settings** 1 section, and select **Build Platforms** 2 from the left-hand menu. ![build platforms](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/eaa35661-27da-426a-9e59-7471833da260.png) :::info To enable Custom Platforms for your Workspace, contact the Applivery Support team at [support@applivery.com](mailto:support@applivery.com). We will enable the feature and help you configure the specific platforms you need. ::: * * * ### Using the Upload API with Custom Platforms Custom Platforms are fully supported through the Applivery Upload API, allowing you to integrate build uploads into your CI/CD pipeline just as you would for native platforms. The same endpoint is used — you simply specify the custom platform identifier in your request. See the [Upload API documentation](https://docs.applivery.com/en/app-distribution/api/builds/upload-build/) for full details on request format, authentication, and required parameters, including `packageName` and `packageVersion` for custom platform Builds. --- ## SDK Source: https://docs.applivery.com/en/app-distribution/sdk/ Description: Integrate app distribution and user management directly into your applications with the Applivery SDK. Deliver in-app updates and manage users easily. TL;DR: The Applivery SDK enables direct integration of app distribution and user management into applications, allowing for in-app updates and user control. Key topics: SDK integration, app distribution, user management, Applivery, SDK The Applivery SDK is a lightweight library for iOS and Android that adds over-the-air update management, forced update enforcement, feedback reporting, and user binding directly into your App. It is designed for internal and beta distribution Builds — not for App Store or Google Play production releases. The SDK integrates with just a few lines of code and requires no Applivery account registration from your end users. :::info The SDK always updates to the **most recent build available** for the App, matching only the bundle ID or package name. It does not respect Publication filters, groups, or audiences — since the Publication from which a Build was originally downloaded cannot be identified at update time. If you need per-flavor or per-feature update isolation, create a separate Applivery app for each variant with a single Publication each. ::: * * * ### Features **OTA Automatic Updates** Notifies users when a new version is available and lets them install it with a single tap. **Forced Updates** Blocks app usage and forces an update when the installed version falls below a minimum version threshold configured in the Applivery Dashboard. **Feedback & Bug Reporting** Users can report bugs or send feedback by taking a screenshot or recording a video. Device information is automatically attached. **User Binding** Associate your own authenticated users with Applivery sessions for analytics, download tracking, and feedback attribution. **iOS SDK** **Current version:** 4.5.4 **Minimum iOS version:** 15.0 **Language:** Swift **Distribution:** Swift Package Manager (recommended), CocoaPods (deprecated) **Repository:** [applivery/applivery-ios-sdk](https://github.com/applivery/applivery-ios-sdk) #### Installation ##### Swift Package Manager (recommended) In Xcode, go to **File → Add Package Dependencies** and enter: ``` https://github.com/applivery/applivery-ios-sdk.git ``` Set the dependency rule to **Up to next major version** (`4.0.0 < 5.0.0`). You will be prompted to choose between two targets: | Target | When to use | | --- | --- | | `Applivery` | Use when the App is strictly internal and will never be submitted to the App Store. Static framework. | | `AppliveryDynamic` | Use when you distribute internally via Applivery but also submit to the App Store. The framework can be excluded at build time for App Store schemes. | :::info **App Store submissions:** Including the Applivery SDK in an App Store build is not permitted and your submission may be rejected. Use `AppliveryDynamic` and exclude it from your App Store build configuration — see [Conditionally excluding the Applivery iOS SDK](https://docs.applivery.com/en/app-distribution/platforms/apple/exclude-sdk-ios-production/) for step-by-step instructions. ::: ##### CocoaPods (deprecated) ```ruby pod 'Applivery', '~> 4.5' ``` #### Setup Initialize the SDK early in your App's lifecycle, typically in `AppDelegate` or `SceneDelegate`: **Swift** ```swift import Applivery let applivery = AppliverySDK.shared applivery.start(token: "YOUR_APP_TOKEN", tenant: "YOUR_TENANT") ``` **Objective-C** ```objc @import Applivery; AppliverySDK *applivery = [AppliverySDK shared]; [applivery startWithToken:@"YOUR_APP_TOKEN" tenant:@"YOUR_TENANT"]; ``` The `tenant` parameter is optional. If omitted, the SDK uses the default Applivery host. Your **App Token** is available in **App Settings → API Tokens** in the Applivery Dashboard. #### Configuration Pass an `AppliveryConfiguration` object to `start()` to customize SDK behavior: **Swift** ```swift import Applivery let config = AppliveryConfiguration( postponedTimeFrames: [3600, 86400], // Delay options in seconds shown to users when an update is available enforceAuthentication: true // Require user login before SDK usage ) AppliverySDK.shared.start( token: "YOUR_APP_TOKEN", tenant: "YOUR_TENANT", configuration: config, skipUpdateCheck: false ) ``` **Objective-C** ```objc NSArray *timeFrames = @[@3600, @86400]; AppliveryConfiguration *config = [[AppliveryConfiguration alloc] initWithPostponedTimeFramesNSNumber:timeFrames enforceAuthentication:YES]; ``` | Property | Type | Description | | --- | --- | --- | | `postponedTimeFrames` | `[TimeInterval]` | Time intervals in seconds shown as "remind me later" options in the update dialog. Maximum 3 options. | | `enforceAuthentication` | `Bool` | If `true`, users must log in to Applivery before the App can be used. Default: `false`. | #### Key API Methods | Method | Description | | --- | --- | | `start(token:tenant:configuration:skipUpdateCheck:)` | Initializes the SDK. Call once at app launch. | | `checkForUpdates(forceUpdate:)` | Checks for a newer build and prompts the user to update. Pass `forceUpdate: true` to ignore any postponed delay. | | `isUpToDate() -> Bool` | Returns `true` if the current build number matches the latest available. Does not respect Publication filters. | | `update(onDownload:)` | Downloads and installs the latest Build immediately. | | `setCheckForUpdatesBackground(_ enabled: Bool)` | Automatically checks for updates when the App returns from background. | | `feedbackEvent()` | Presents the feedback UI programmatically (e.g., on shake gesture). | | `enableScreenshotFeedback()` / `disableScreenshotFeedback()` | Enables or disables screenshot detection to trigger feedback. | | `bindUser(email:firstName:lastName:tags:onComplete:)` | Associates a user identity with the current session for analytics and feedback tracking. | | `unbindUser(onComplete:)` | Removes the currently bound user. | | `getUser(onSuccess:)` | Returns the currently bound user's profile as a dictionary. | | `handleRedirectURL(url:)` | Handles SAML authentication redirect URLs. Call from `AppDelegate` or `SceneDelegate`. | | `setLogHandler(_ handler:)` | Sets a custom log handler to capture or redirect Applivery logs. | #### Customization **UI Colors** ```swift AppliverySDK.shared.palette = Palette( primaryColor: .orange, secondaryColor: .white, primaryFontColor: .white, secondaryFontColor: .black, screenshotBrushColor: .green ) ``` **String Literals** — localize or rebrand SDK messages: ```swift AppliverySDK.shared.textLiterals = TextLiterals( appName: "MyApp", otaUpdateMessage: "A new version is available. Update now?", forceUpdateMessage: "This version is no longer supported. Please update to continue." ) ``` **Logging** ```swift applivery.logLevel = .info // .none | .error | .info | .debug ``` | Level | Recommended for | | --- | --- | | `.none` | Production (default) | | `.error` | Development | | `.info` | Testing the SDK integration | | `.debug` | Debugging SDK requests and responses | #### Swift / Xcode Compatibility | SDK Version | Xcode | Swift | | --- | --- | --- | | v4.0+ | 13.x+ | 5.x | | v3.4 | 13.x | 5.x | | v3.2 | 12.x | 5.x | | v2.7.x | 9.x – 10.x | 4.0, 4.2 | **Android SDK** **Current version:** 5.0.0 **Minimum Android version:** Android 7.0 (API level 24) **Language:** Kotlin **Distribution:** Maven Central **Repository:** [applivery/applivery-android-sdk](https://github.com/applivery/applivery-android-sdk) #### Installation Add the dependency to your App's `build.gradle`. The SDK is designed for non-production Builds: ```kotlin // Use debugImplementation so Applivery only runs in debug/testing builds debugImplementation("com.applivery:applivery-sdk:${latestVersion}") ``` **No-op artifact for release Builds** To avoid a complex source set configuration for excluding the SDK from release Builds, use the no-op artifact. It exposes the same public API as the full SDK but does nothing at runtime: ```kotlin releaseImplementation("com.applivery:applivery-sdk-no-op:${latestVersion}") ``` This lets you call Applivery SDK methods throughout your codebase without affecting release Builds. #### Setup Initialize the SDK in your `Application.onCreate()` method: ```kotlin import com.applivery.android.sdk.Applivery import com.applivery.android.sdk.start class MyApplication : Application() { override fun onCreate() { super.onCreate() Applivery.start(APPLIVERY_TOKEN) // For private Applivery instances, also pass the tenant: // Applivery.start(APPLIVERY_TOKEN, TENANT) } } ``` :::info For Java projects (version 4.0.0+), use the `AppliveryInterop` class to access SDK functionality. ::: Your **App Token** is available in **App Settings → API Tokens** in the Applivery Dashboard. #### Configuration Pass a `Configuration` object to `Applivery.start()` to customize behavior: ```kotlin val configuration = Configuration( postponeDurations = listOf(2.hours, 30.minutes, 5.minutes), enforceAuthentication = false, downloadAction = BuildDownloadAction.IMMEDIATE ) Applivery.start(APPLIVERY_TOKEN, configuration = configuration) ``` | Property | Type | Description | | --- | --- | --- | | `postponeDurations` | `List` | Options shown to users to postpone an available update. Maximum 3 options. | | `enforceAuthentication` | `Boolean` | If `true`, users must log in before using the SDK. Default: `false`. | | `downloadAction` | `BuildDownloadAction` | `IMMEDIATE` installs the update as soon as the download completes. `DEFERRED` shows a notification and lets the user decide when to install. | #### Update Management ```kotlin // Check for updates manually Applivery.getInstance().checkForUpdates() // Automatically check when app returns from background Applivery.getInstance().setCheckForUpdatesBackground(true) // Download the latest update without installing immediately val callback = object : DownloadLastUpdateCallback { override fun onSuccess(update: CachedAppUpdate) { update.install() // install when ready } override fun onError(error: Throwable) { /* handle error */ } } Applivery.getInstance().downloadLastUpdate(callback) // Enable background auto-download Applivery.getInstance().enableDownloadLastUpdateBackground(callback) // Trigger immediate download + install (follows configured downloadAction) Applivery.getInstance().update() ``` :::warning `enableDownloadLastUpdateBackground` and `setCheckForUpdatesBackground` are mutually exclusive. Enabling one disables the other. ::: #### Feedback ```kotlin // Enable/disable screenshot-triggered feedback Applivery.getInstance().enableScreenshotFeedback() Applivery.getInstance().disableScreenshotFeedback() // Show feedback UI programmatically Applivery.getInstance().feedbackEvent() ``` #### User Management ```kotlin // Bind a user for analytics and feedback tracking Applivery.getInstance().bindUser(email, firstName, lastName, tags) // Remove the bound user Applivery.getInstance().unbindUser() // Get current user Applivery.getInstance().getUser(getUserCallback) ``` #### Required Permissions The SDK requires the following runtime permissions. Request them in your App before the features that need them are used: | Permission | Used for | | --- | --- | | `POST_NOTIFICATIONS` | Showing notifications during update downloads and screen recording | | `READ_MEDIA_IMAGES` | Screenshot detection for feedback (full access required on Android 14+) | | `SYSTEM_ALERT_WINDOW` | Screen recording for feedback | #### UI Customization Create a `res/values/applivery.xml` file to override default colors and strings: ```xml #FF0241E3 #FF0241E3 #FF010258 A new version is available. Update now? This version is outdated. Please update to continue. ``` --- ## SDK Users Source: https://docs.applivery.com/en/app-distribution/sdk/sdk-users/ Description: Applivery SDK Users — bound and temporal users, how to bind/unbind them, authentication enforcement, and tracking App usage and feedback. TL;DR: Applivery SDK users are automatically created records for devices running apps with the SDK, allowing developers to track usage and enforce authentication. Key topics: SDK user types, Binding and unbinding users, Authentication enforcement, User visibility in Applivery Dashboard, Applivery, SDK, iOS, Android, Swift, Kotlin The Applivery SDK creates and tracks user records automatically for every Device that runs an App with the SDK integrated. These records appear in the Applivery Dashboard and allow you to get insights into who installs your Apps, who reports feedback, and how Builds are adopted across your user base. SDK users come in two types depending on how they originate: **SDK users** (bound, named identities) and **Temporal SDK users** (anonymous, device-based). Both count as employees against your Workspace's employee limit. :::info Both SDK users and Temporal SDK users count toward your Workspace's **Store Employees** quota. ::: --- ### Types of SDK Users | | SDK User | Temporal SDK User | |---|---|---| | **Origin** | Created programmatically via `bindUser()` | Created automatically by the SDK on first device launch | | **Duration** | Permanent | Expires after 30 days of inactivity across all Apps in your organization | | **Identifier** | Email address you provide. E.g. `jane@example.com` | Device ID. E.g. `6effd10a-5b00-45ec-b02d-580b53a5775c` | | **Description** | Named employees with a known identity, linked to the session via `bindUser()` | Unknown users automatically created to track unique Devices. Unique across your Workspace based on device ID. | :::info **Inactivity** is defined as the last time a user opened any App from your organization with the SDK integrated. The 30-day timer resets on each open. ::: --- ### SDK Users (Bound) When you call `bindUser()` with an email address, Applivery links the current device session to a named identity. This allows you to: - See who downloaded or installed each Build. - Attribute feedback reports and bug submissions to a specific person. - Track update adoption per named user. - Control app access by user identity when authentication enforcement is enabled. Bound users appear with their email address in the Applivery Dashboard, making it easy to correlate SDK activity with your own user base. ### Temporal SDK Users (Anonymous) When a Device runs the SDK for the first time without a `bindUser()` call, Applivery automatically creates a Temporal SDK User record identified by the Device's unique ID. These records allow basic device-level analytics (installations, update adoption) even when no named identity is available. Temporal SDK users expire after 30 days of inactivity. If the same device opens the App again after expiry, a new Temporal SDK User record is created. --- ### Binding a User Call `bindUser` after your App's own authentication flow completes, so the identity is known before any Applivery interactions occur. **iOS (Swift)** ```swift AppliverySDK.shared.bindUser( email: "user@example.com", // Required firstName: "Jane", // Optional lastName: "Doe", // Optional tags: ["beta", "ios-team"] // Optional — used for filtering in the Dashboard ) { // onComplete callback — called when binding is confirmed } ``` **iOS (Objective-C)** ```objc [[AppliverySDK shared] bindUserWithEmail:@"user@example.com" firstName:@"Jane" lastName:@"Doe" tags:@[@"beta", @"ios-team"] onComplete:nil]; ``` **Android (Kotlin)** ```kotlin Applivery.getInstance().bindUser( email = "user@example.com", firstName = "Jane", lastName = "Doe", tags = listOf("beta", "android-team") ) ``` ##### `bindUser` parameters | Parameter | Type | Required | Description | |---|---|---|---| | `email` | String | Yes | The user's email address. Used as the primary identifier in the Applivery Dashboard. | | `firstName` | String | No | The user's first name. Displayed alongside the email in reports and feedback. | | `lastName` | String | No | The user's last name. | | `tags` | Array of Strings | No | Custom labels for grouping or filtering users in the Dashboard. E.g. `["qa", "ios"]`. | --- ### Unbinding a user Call `unbindUser` when your App's user logs out, so subsequent SDK interactions are no longer attributed to that identity. **iOS (Swift)** ```swift AppliverySDK.shared.unbindUser { // onComplete callback } ``` **iOS (Objective-C)** ```objc [[AppliverySDK shared] unbindUserWithOnComplete:nil]; ``` **Android (Kotlin)** ```kotlin Applivery.getInstance().unbindUser() ``` :::info After unbinding, the SDK session returns to anonymous mode until `bindUser` is called again. ::: --- ### Retrieving the current user You can read back the currently bound user's profile at any point: **iOS (Swift)** ```swift AppliverySDK.shared.getUser { userInfo in // userInfo is an NSDictionary, or nil if no user is bound print(userInfo ?? "No user bound") } ``` **Android (Kotlin)** ```kotlin Applivery.getInstance().getUser(object : GetUserCallback { override fun onSuccess(user: AppliveryUser?) { // user is null if no user is bound } override fun onError(error: Throwable) { /* handle */ } }) ``` --- ### Authentication enforcement If your Publication requires users to log in before accessing the App, you can enforce this at the SDK level. When `enforceAuthentication` is set to `true` in the SDK configuration, users must authenticate via Applivery (or your Workspace's SSO) before the App becomes usable. **iOS** ```swift let config = AppliveryConfiguration( enforceAuthentication: true ) AppliverySDK.shared.start(token: "YOUR_TOKEN", configuration: config) ``` **Android** ```kotlin val config = Configuration( enforceAuthentication = true ) Applivery.start(APPLIVERY_TOKEN, configuration = config) ``` :::info When enforcement is enabled, and the user has not authenticated, Applivery will present a login prompt. If `enforceAuthentication` is `false` (the default), users can dismiss the login prompt and continue using the App anonymously. ::: --- ### User visibility in the Dashboard SDK users are visible per app in the Applivery Dashboard or in the Directory section under the Settings menu. For each user, you can see: - Email address and display name (for bound users). - Tags assigned via `bindUser`. - Devices associated with the user. - Download history — which Builds were installed. - Feedback submissions attributed to the user. Anonymous users appear with a Device identifier rather than an email address. --- ### SDK users vs. other user types Applivery has several distinct user types. Understanding the differences helps avoid confusion: | User Type | Who they are | How they authenticate | Where they appear | |---|---|---|---| | **Collaborators** | Team members managing the App (developers, QA leads) | Applivery account or SSO | Dashboard → Team | | **Store Employees** | End users with access to App Store Publications | Applivery account, SSO, password, or OTP | App → Users (Store) | | **SDK Users** | Users of an App with the SDK integrated | Via `bindUser` in the App code | App → Users (SDK) | | **OTP Users** | External users with time-limited Publication access | One-time password sent by email | App → Publication → OTP Allowlist | SDK users are the only type created programmatically from within the App itself. All other types are managed through the Applivery Dashboard or API. --- ## Troubleshooting Source: https://docs.applivery.com/en/app-distribution/troubleshooting/ Description: Solve app distribution problems: installation errors, signing issues, device compatibility, & network problems. Ensure smooth app delivery. TL;DR: This guide helps developers troubleshoot common app distribution issues like installation errors and device compatibility problems to ensure smooth app delivery. Key topics: Installation errors, Signing and provisioning, Device compatibility, Network issues Identify and resolve the most common issues in App Distribution — from installation failures and signing errors to device compatibility problems and network-related issues. Each article walks through the symptoms, likely causes, and steps to fix the problem so you can get back to distributing quickly. --- ## App Installation Issues Source: https://docs.applivery.com/en/app-distribution/troubleshooting/unable-to-download-install-application/ Description: Diagnose and resolve common iOS app installation issues like stuck downloads, greyed-out icons, and integrity verification failures. Get your apps installed! TL;DR: Fix common iOS app installation problems by checking network connectivity, provisioning profiles, signing certificates, and device UDIDs. Key topics: Network connectivity issues, Provisioning profile problems, Signing certificate issues, Code signature verification failures, iOS, Applivery, Apple Developer Portal, Xcode, UDID ![unable to install](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/92554d69-31a0-4b97-b3ff-b5298dbd6f85.png) :::info The issues described here are specific to **iOS**. Android installation problems are typically caused by the "Unknown sources" setting — see [Unknown sources in Android](https://docs.applivery.com/en/app-distribution/platforms/android/unknown-sources/) for guidance. ::: * * * ### Quick diagnosis: what are you seeing? | Symptom | Most likely cause | | --- | --- | | Progress bar appears but doesn't move | Network connectivity issue | | App install stuck on "Waiting…" | Network connectivity issue | | App icon turns dark grey and is not tappable | Certificate or provisioning profile problem | | Alert: _"Unable To Install — integrity could not be verified"_ | Code signature failure | * * * ### Progress bar appears but doesn't move **Cause:** The Device cannot reach Applivery's download servers. This is almost always a network issue. **Resolution:** 1. Make sure the Device has a stable internet connection — switch between Wi-Fi and mobile data to rule out a connection-specific problem. 2. Cancel the download and try again. 3. If the issue persists, try on a different network. * * * ### App install stuck on "Waiting…" **Cause:** iOS queued the installation but cannot proceed — most commonly a network timeout during the download, or an overloaded device state. **Resolution:** 1. Make sure the Device has a stable internet connection and try again. 2. If the problem persists, power the Device off completely, wait at least 5 minutes, power it back on, and retry. 3. If it still gets stuck, use the [iOS installation debugger](https://docs.applivery.com/en/app-distribution/platforms/apple/debug-ios-app-installation/) to capture more details about where the process is failing. * * * ### App icon turns dark grey and is not tappable This symptom means iOS started the installation but stopped before completing it. The cause is always related to the App's signing configuration. Work through the following checks: #### Missing device UDID (Ad-hoc distribution only) If the App was signed with an **Ad-hoc** certificate, the Device's UDID must be listed in the provisioning profile. If it isn't, iOS will silently fail to install. **Resolution:** 1. In the Applivery Dashboard, open the Build details and note the Device's UDID. 2. Add the UDID to your provisioning profile in the [Apple Developer Portal](https://developer.apple.com/account/). 3. Download the updated provisioning profile, re-sign the App, and upload the new Build to Applivery. #### Expired provisioning profile Provisioning profiles have a maximum validity of one year. An expired profile will prevent installation even if the signing certificate is still valid. **Resolution:** 1. Renew the provisioning profile in the [Apple Developer Portal](https://developer.apple.com/account/). 2. Rebuild the App with the updated profile and upload the new Build to Applivery. #### Expired signing certificate Both Ad-hoc and Enterprise signing certificates expire. An expired certificate invalidates all Builds signed with it, even if the provisioning profile is still valid. **Resolution:** 1. Renew or create a new signing certificate in the [Apple Developer Portal](https://developer.apple.com/account/). 2. Update your Xcode signing configuration, rebuild the App, and upload the new Build to Applivery. #### Other signing issues If none of the above applies, there may be a mismatch between the certificate, profile, and bundle identifier. **Resolution:** 1. Verify that the bundle identifier in your Xcode project matches the one in the provisioning profile exactly. 2. Check that the certificate used to sign the Build is the one associated with the provisioning profile. 3. Use the [iOS installation debugger](https://docs.applivery.com/en/app-distribution/platforms/apple/debug-ios-app-installation/) to capture the specific error. * * * ### Alert: _"Unable To Install — integrity could not be verified"_ **Full message:** _Unable To Install "App Name": This App cannot be installed because its integrity could not be verified._ **Cause:** Apple checked the App's code signature after download and found it invalid. This typically means the provisioning profile embedded in the App does not match the signing certificate, or the profile has expired. **Resolution:** 1. Check the provisioning profile associated with the Build — ensure it is not expired and matches the signing certificate used. 2. Rebuild the App with a valid profile and certificate combination and upload the new Build to Applivery. 3. If the problem persists, use the [iOS installation debugger](https://docs.applivery.com/en/app-distribution/platforms/apple/debug-ios-app-installation/) to capture the exact failure point. --- ## Device Management Source: https://docs.applivery.com/en/device-management/ Description: Manage and secure corporate devices across Apple, Android, and Windows with Applivery Device Management — enroll devices, apply policies, push apps, and automate lifecycle workflows. TL;DR: Applivery Device Management gives IT teams a unified platform to enroll, configure, and secure corporate devices across Apple, Android, and Windows. Key topics: Device Management, MDM, Device Enrollment, Policy Configuration, Remote Commands, Applivery, Apple MDM, Android Enterprise, Windows MDM Applivery Device Management gives IT teams everything they need to enroll, configure, and secure corporate devices — across Apple (iOS, macOS), Android, and Windows — from a single cloud dashboard. With full compliance with the Apple MDM protocol, Android Enterprise, and Windows MDM, it covers the entire device lifecycle: from enrollment and policy configuration to app deployment, script execution, remote commands, and automated lifecycle workflows. --- ## Android Source: https://docs.applivery.com/en/device-management/android/ Description: Applivery Android Device Management — Android Enterprise for GMS Devices and AOSP MDM for rugged and industrial Devices without Google Mobile Services. Applivery supports two Android management tracks: **Android Enterprise MDM** for GMS-enabled Devices, and **AOSP MDM** for rugged, kiosk, and industrial Devices that ship without Google Mobile Services. Both are managed from the same Dashboard — no separate tooling required. With Android Enterprise, you can deploy Apps through Managed Google Play, enforce security Policies, configure Kiosk Mode, manage OEM-specific settings, and run remote commands. With AOSP MDM, you get the same Device Management capabilities — silent App distribution, Policies, Kiosk Mode, and remote commands — without any dependency on Google services or accounts. Android Device Management in Applivery includes enrollment methods, App Management, Policies, OEM configurations, remote commands, AOSP support, and troubleshooting. --- ## Android Enterprise MDM Source: https://docs.applivery.com/en/device-management/android/android-enterprise-mdm/ Description: Android Enterprise MDM in Applivery — key features, management sets, and how to manage Android Devices at scale with full Device Management control. TL;DR: Applivery provides a powerful Android Enterprise MDM solution with comprehensive features and support for various management sets, enabling effective management of Android devices in the workplace. Key topics: Android Enterprise, Mobile Device Management, Applivery MDM, Android Device Policy, Managed Google Play, Applivery, Google, Android Management API, Google Play API Applivery provides full support to the [Android Enterprise](https://www.android.com/enterprise) ecosystem, a Google-led initiative to enable the use of Android Devices and Apps in the workplace. The program offers APIs (mainly the Android Management API and Google Play API) and other tools for developers to integrate support for Android into their enterprise mobility management (EMM) solutions. Applivery has become **one of the most powerful EMM (Enterprise Mobility Management solution)** as described and certified by Google under the [Android Enterprise EMMs Solutions Directory](https://androidenterprisepartners.withgoogle.com/provider/#!/40bMPraLqpk8Cx65JrDp). We are **one of the very few companies worldwide providing support to the main 4 management sets and the only one that has created such an easy-to-use interface to interact with the Google APIs.** Below you will discover the most important concepts about Android Enterprise and Applivery MDM solution for Android. ### Android Device Management - Key Features **Policy Templates** A comprehensive library of pre-configured Policy templates to save operational time.​ **Kiosk Mode​** Safely limits the operation of a Device to a predefined selection of Apps and features.​ **Policy Enforcement** Enforce security Policies like password complexity and encryption. **Work Profile BYOD** Securely access work data on personal Devices with Work Profile BYOD. **Usage Analytics​** Location tracking and App usage to provide a deep understanding of how Devices are used.​ **Remote Support​** Designed to empower IT support teams to remotely troubleshoot, diagnose and resolve issues.​ **Smart Zero-touch​** Dynamic and automated enterprise Device provisioning and configuration process.​ **Managed OS Updates​** Ensure that Devices remain up-to-date, secure, and compliant with organizational standards.​ **SSO Integrations​** Access Devices, Apps, and corporate Resources with a single set of credentials.​ **Advanced App Distribution​** Save time by automating App Distribution, and try our best-in-class CI&CD tool.​ * * * **Explore Device Management** Best-in-class MDM Solution, easy-to-use admin experience in a cloud-based platform, made for Android, Apple, and Windows Devices. Below you will discover the most important concepts about Android Enterprise and Applivery MDM solution for Android. ### Management Sets Applivery supports the following Android Enterprise management sets: - **Work Profile:** Enables platform-level separation of work Apps and data. Enterprises have control over all data and security Policies within the Work Profile. Outside the Work Profile, the Device remains suitable for personal use—ideal for BYOD deployments. - **Full Device Management:** Provides full MDM and App Management for granular control over Company-Owned Devices. Choose from 80+ settings to enforce and benefit from Android’s full suite of App Management features. This option is designed for Devices intended primarily for corporate use - **Dedicated Device:** Transforms Company-Owned Devices into purpose-built Devices. Lock them down to a single App or suite of Apps to serve specific employee or customer-facing scenarios. Enforce an extended range of security Policies to prevent users from escaping Apps and accessing the lock screen. - **Mobile App Management (MAM):** Benefit from Android’s full suite of enterprise App Management features combined with basic Device security. Distribute public and private Apps, curate the Play Store on users’ Devices, and restrict access to work Apps if a Device doesn’t meet minimum password Policies. ### Android Device Policy All Android Devices that an organization manages through the Applivery console must install the Android Device Policy during setup. Android Device Policy is an App supplied by Android that automatically applies the management Policies set in your EMM console to Devices. The installation of that App will be different depending on the management scenario: - **Work Profile and MAM:** Employees or IT Admin will be responsible for the installation of the Android Device Policy App from the Google Play Store. However, Applivery will guide the process by email. - **Full Device and dedicated Device Management:** The Android Device Policy App will be automatically installed during the Device setup. ### Managed Google Play Managed Google Play is an enterprise version of Google Play that facilitates certain App Management capabilities for Android Enterprise solutions. It combines the familiar user experience and App Store features of Google Play with a set of management capabilities designed specifically for enterprises. It provides the following features: - Public App search. - Basic Private App publishing. - Web App publishing. - App organization. On **managed Devices**, Managed Google Play is the user’s Enterprise App Store. The interface is similar to Google Play—users can browse Apps, view App details, and install them. Unlike the public version of Google Play, users can only install Apps from the Managed Google Play that their organization approves for them. ![managed-google-play-iframe | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/04e75d0b-f1c4-4b8e-8fae-a6332fe0ef25.png) **Start Your Free Trial** Try Applivery completely free and without limits for 14 days. All of your Device management tools in one place: Devices, Apps, Data, Security, & more. **Schedule a Demo** Speak with our experts to learn how Applivery can streamline your Mobile Device Management. --- ## Android Open Source Project (AOSP) Source: https://docs.applivery.com/en/device-management/android/aosp/ Description: Applivery AOSP MDM for rugged, kiosk, and industrial Android Devices without Google Mobile Services — silent App distribution and robust security. TL;DR: Applivery provides full MDM for AOSP and non-GMS Android devices, offering comprehensive management, silent app distribution, and robust security without Google services. Key topics: AOSP MDM solution components, Key device management capabilities, App distribution for non-GMS devices, Device security and usability features, Management sets and provisioning, Applivery, AOSP, Android Open Source Project, Google Mobile Services, GMS, Android Enterprise, Google Play, Applivery DPC, DevicePolicyManager APIs, Applivery Self-Service, Pushy, Android Device Policy, Zebra, Bluebird, Samsung Knox, Google Workspace Applivery provides full MDM for **AOSP (Android Open Source Project)** and other non-GMS Android Devices, bringing the same Device Management capabilities to rugged terminals, kiosks, and industrial hardware that ship without Google Mobile Services. AOSP MDM is the right choice for rugged Devices, industrial PDAs, point-of-sale terminals, digital signage, and any OEM Android build not certified to run Google services. Unlike Android Enterprise, it requires no Google account, no Android Enterprise setup, and no Managed Google Play organization. Everything is managed from the same Applivery Dashboard. ### The Applivery AOSP Solution Applivery's AOSP MDM solution is built around three components: - The **Applivery DPC** — an on-device agent that runs as Device Owner and applies every Policy set in the Dashboard through the native Android `DevicePolicyManager` APIs. - The **Applivery Self-Service** — hosts and silently installs APKs without any dependency on Google Play. - A **real-time command channel** powered by Pushy — dispatches remote commands to Devices and reports results back to the Dashboard. The Applivery DPC plays the same role that Android Device Policy plays in standard Android Enterprise deployments, but it does not depend on any Google service, account, or Play infrastructure. ### Key Capabilities **Policy Templates** A comprehensive library of pre-configured Policy templates ready to apply to any AOSP Device. **Kiosk Mode** Lock a Device to a single App or a curated suite of Apps, with full control over the navigation bar, status bar, and power button. **Policy Enforcement** Enforce security Policies such as password complexity, keyguard restrictions, factory-reset protection, and remote wipe. **Silent App Distribution** Install, update, and uninstall Apps silently on managed Devices — no Google Play Store required. **Wi-Fi & Certificate Management** Silently provision corporate Wi-Fi networks (Open, WPA, WPA-Enterprise with EAP-TLS, PEAP, and TTLS) and distribute supporting CA and client certificates. **Remote Support** Lock, reboot, reset password, clear App data, and disenroll Devices in real time from the Applivery Dashboard. **Factory Provisioning** Pre-install the Applivery DPC in an OEM image and provision Devices automatically at first boot, with no user interaction. **Status Reporting** Periodic reports on installed Apps, Device settings, software build, memory, storage, network, and hardware information. **Always-On VPN** Force all Device traffic through a corporate VPN with optional lockdown mode and per-package exemptions. **OEM Configurations** Apply OEM-specific managed configurations on supported AOSP hardware — Zebra, Bluebird, Samsung Knox, and more. ### Management Sets Applivery supports two management sets for AOSP Devices: - **Full Device Management** — provides full MDM and App management for granular control over company-owned AOSP Devices. Choose from 80+ settings to enforce, including password complexity, keyguard restrictions, Wi-Fi configuration, runtime permissions, hardware controls, and more. - **Dedicated Device** — transforms company-owned AOSP Devices into purpose-built terminals. Lock them down to a single App or a curated suite of Apps, and enforce an extended range of security Policies — power button, navigation bar, status bar, system error dialogs, and Settings access — to prevent users from escaping the locked experience. ### The Applivery Self-Service Because AOSP Devices do not have access to Google Play, all App distribution goes through the [**Applivery Self-Service**](https://docs.applivery.com/en/device-management/android/policies/agent/#self-service-portal). It is Applivery's replacement for Managed Google Play on AOSP Devices, and it provides: - Private App distribution — upload APKs directly from the Dashboard. - Silent install, update, and uninstall with no user interaction required. - Per-App managed configuration applied silently through the DPC. - Per-App runtime permission Policy. - Block uninstall and disable user controls. - Compatibility checks and automatic rollout to all enrolled Devices that match the targeting rules. ### Get started To begin managing AOSP Devices with Applivery, you do **not** need to set up Android Enterprise, link a Google Workspace account, or create a Managed Google Play organization. Everything you need is on the Applivery side. **QR-code provisioning** is the only supported enrollment method, for fleet rollouts and one-off enrollments alike. The enrollment token **cannot be injected through ADB**. Once enrolled, each Device appears in **Device Management > Devices** with its display name, model, Android version, and the Policy that was applied. From there, you can manage Apps, run commands, edit the Policy, and review status reports. ### Feature list The Applivery DPC operates as Device Owner using the native Android APIs, so every feature below works on any AOSP build that ships those APIs — regardless of whether Google services are present. #### Device security - **Device security challenge** — set and enforce a PIN, pattern, or password of a defined type and complexity. - **Advanced passcode management** — minimum length, letters, numerics, symbols, upper/lower case, history, expiration, and wipe threshold. - **Remote wipe and lock** — remotely lock and disenroll Devices. - **Compliance enforcement** — apply enforcement rules (block, then wipe) when Devices drift out of compliance. - **Default security Policies** — debug features and installs from unknown sources are blocked by default. - **Security Policies for dedicated Devices** — users cannot escape a locked-down Device. - **Hardware security management** — disable factory reset, safe boot, USB data transfer, physical media mount, NFC beam, and camera. - **Memory Tagging Extension (MTE) Policy** and **Common Criteria mode** on supported Devices. #### App Management - **Silent app distribution** — install, update, and uninstall Apps with no user interaction. - **Managed configuration management** — view and silently set managed configurations for any App that supports them. - **App catalog management and allowlisting** — configure the work Apps catalog by allowlisting or blocklisting Apps. #### Device Management - **Runtime permission Policy management** — set a default response (Prompt / Grant / Deny) and override per App per permission. - **Wi-Fi configuration management** — silently provision enterprise Wi-Fi (Open, PSK, EAP-TLS, PEAP, TTLS). - **Wi-Fi security management** — identity, client certificates, CA certificates, domain suffix match, SAN matching. - **Advanced Wi-Fi management** — lock down Wi-Fi configurations on managed Devices. - **Account management** — block users from adding or modifying accounts. - **Accessibility services management** — control which accessibility services can be enabled. - **Location sharing management** — force HIGH\_ACCURACY, SENSORS\_ONLY, BATTERY\_SAVING, or OFF. - **Factory reset protection management** — protect Devices from theft or disable as needed. - **Advanced app control** — block uninstall, disable force-stop and data clearing through Settings. - **Screen capture management** — block screenshots and screen sharing. - **Disable cameras**. - **Reboot the device remotely**. - **System radio management** — control mobile network, roaming, calls, SMS, tethering, Wi-Fi timeout, and Bluetooth. - **System audio management** — mute, block volume changes, block microphone unmute. - **System clock management** — control clock, timezone, and automatic settings. - **Advanced dedicated device features** — disable keyguard, status bar, notifications, and quick settings; force screen on; prevent Toasts, system alerts, and overlays. #### Device usability - **Lock screen messages** — custom message on the lock screen. - **Policy transparency management** — short and long support messages shown when users hit a restriction. - **System update Policy** — automatic, windowed, or postponed OTAs. - **Kiosk mode management** — pin one or several Apps to the screen. - **Keyguard feature management** — disable camera, biometrics, fingerprint, face, trust agents, notifications, and shortcuts. - **MAC address retrieval** — silently fetch the device MAC address for inventory. - **Advanced lock task mode management** — control home button, recents, global actions, notifications, status bar, and keyguard while in kiosk mode. - **Advanced system update Policy** — freeze periods for blocking OTAs during specified date ranges. ### COPE Permissions on AOSP Devices The Applivery DPC on AOSP runs as **Device Owner** only. There is no Work Profile and no COPE personal usage flow, so the permission limits documented for [COPE Devices](https://docs.applivery.com/en/device-management/android/cope-permission-limits/) do not apply — every restriction you configure takes effect at the full Device level. If you need a Work Profile / COPE split, use the standard [Android Enterprise MDM](https://docs.applivery.com/en/device-management/android/android-enterprise-mdm/) flow on Devices with Google services. ### Always-On VPN Force all Device traffic through a corporate VPN, with optional lockdown mode and per-package exemptions. **Navigate to Policies** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), head to **Policies** 1. Choose the Policy where you want to add the configuration. **Add Always-On VPN Configuration ** In the left-hand menu, select **Network** and search for **Always-On VPN Package** 2. ![always-on vpn package](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/f1d22d30-18cf-4cbe-a229-72e66f2c567d.png) | Setting | Description | | --- | --- | | **VPN Package** | Package name of the VPN App to use as the always-on VPN. | | **Lockdown Mode** | When enabled, all traffic is blocked if the VPN is not connected. Prevents data from leaking outside the tunnel. | :::info The VPN App must be force-installed through the Policy before the Always-On VPN setting takes effect. ::: ### Current limitations - **Basic Launcher is not available.** It depends on Android's native Device Policy Controller. Single App kiosk and the [Advanced Launcher](https://docs.applivery.com/en/device-management/android/policies/kiosk-mode/) both work, and the Advanced Launcher needs Android 8 or later. - **Managed Google Play web apps do not work**, since there are no Google services behind them. - **Remote Support is not available** on AOSP Devices. It is in development. :::info **A useful detail about lock task on AOSP.** The DPC adds **every App in the Policy** to the lock task allowlist, and brings the one marked as kiosk to the foreground. That means you can ship your own launcher as an APK, set it as the kiosk App, and get multi-app access even on hardware where the Advanced Launcher is not an option. ::: :::info **In development** - **Remote Support & Control** — remotely view and control AOSP Devices directly from the Applivery Dashboard. - **Work Profile** — Work Profile support on AOSP Devices, enabling a clear separation between corporate and personal data. ::: --- ## App Management Source: https://docs.applivery.com/en/device-management/android/app-management/ Description: Android App Management in Applivery — distribute and maintain Apps across enrolled Devices, manage installations, updates, and enforce App Policies. TL;DR: Android App Management in Applivery provides a centralized platform for organizations to distribute, deploy, and maintain apps on enrolled Android devices. Key topics: Android app management, Applivery platform, Mobile app distribution, App deployment, App policies, Android, Applivery Android App Management in Applivery enables you to distribute, deploy, and maintain Apps across enrolled Android Devices at scale. You can manage App installations, control update behavior, enforce App-specific Policies, and configure App permissions through Managed Google Play. You can distribute Android Apps in different ways — public Play Store Apps, private Apps, and self-hosted APKs — and manage App behavior within your Policies. --- ## App Permissions Source: https://docs.applivery.com/en/device-management/android/app-management/app-permissions/ Description: Centrally manage Android App permissions using Applivery Managed Properties for granular control, enhanced security, and reduced user intervention. TL;DR: Centrally manage Android app permissions with Applivery's Managed Properties to enhance security, ensure compliance, and reduce user intervention. Key topics: app permissions, android management, managed properties, Applivery, device policies, Android Managing App permissions on Android Devices is a critical part of Enterprise Mobility, ensuring security, compliance, and predictable behavior across corporate fleets. With Applivery, organizations can centrally configure permissions for any managed App using Managed Properties, applying granular control aligned with business, security, and regulatory needs. ### Accessing App permission settings Once in the [**Applivery Dashboard**](https://dashboard.applivery.io), go to any of your **Policies** 1. From the left side menu, go to **Apps** 2 and select the **App** 3 whose permissions you want to manage. A side panel will open showing the App’s Managed Properties, including the **Permissions** 4 section. ![app permissions](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/4c430ecd-d686-4137-b999-6273f66ae2b6.png) Applivery provides two complementary ways to control permissions. #### Default Permission Policy This option sets the global behavior for all permissions required by the App: - **Prompt**: The user is asked whether to allow or deny each permission. - **Grant**: All required permissions are automatically granted. - **Deny**: All required permissions are automatically denied. Use this option when you want a simple, uniform rule applied across the entire App. #### Permission Grants (Granular Control) For more advanced cases, you can configure specific permissions individually: **Add a new permission rule** Click **\+ Add element** to add a new permission rule. **Choose the Permission** Choose the Permission from the dropdown list (e.g., camera, location, contacts). **Set the Policy** Set the Policy for that specific permission: \- **Prompt**: User decides whether to allow or deny. \- **Grant**: The permission is automatically granted. \- **Deny**: The permission is automatically denied. You can add as many granular permissions as needed—ideal for complex Apps that require differentiated access. :::info Some permissions behave differently depending on the management mode. **Location**, for example, can be pre-granted silently on Fully Managed and Dedicated Devices, but not inside the work profile on COPE or BYOD. See [Location Management on Android Devices](https://docs.applivery.com/en/device-management/android/policies/location-management/) for the full picture. ::: ### Why use granular permission management? With Applivery, organizations gain: - Stronger security, by blocking unnecessary or risky permissions. - Better compliance, ensuring Apps behave within Policy limits. - A more predictable and controlled deployment. - Reduced user intervention, thanks to automated permission handling. - Flexible adaptation to any App’s operational needs. Configuring App permissions with Managed Properties in Applivery provides precise control and minimizes risk, ensuring that Apps on corporate Devices operate securely and in full alignment with organizational requirements. ### AOSP Devices Support App permission management works the same way on AOSP — same Default Permission Policy (Prompt / Grant / Deny) and Per-App Permission Grants, same configuration steps. The DPC applies them using `DevicePolicyManager.setPermissionGrantState(...)`, no Google services required. Granular grants apply to Apps targeting **API 23 or above**. --- ## App Updates Source: https://docs.applivery.com/en/device-management/android/app-management/app-updates/ Description: Control Android App updates across managed Devices with Applivery — configure flexible update Policies to ensure security and minimize disruptions. TL;DR: Manage Android app updates with Applivery using High Priority, Postpone modes, and configurable update policies for enhanced security and control. Key topics: Android App Management, Mobile Device Management, Applivery Configuration, Google Play Services Updates, Applivery, Google Play Services, Android Keeping Apps on your Android Devices up to date is essential—not only to access the latest features but also to ensure security and optimal performance. Updates often include security patches that protect against vulnerabilities, bug fixes that enhance stability, and optimizations that make Apps run more efficiently. In corporate environments or when managing a large number of Devices, manually handling these updates can be time-consuming and impractical. This is where Applivery becomes invaluable. ### Control App updates and update time Regularly updating applications on your organization’s Devices ensures that users benefit from the newest functionalities, enhanced security, and greater reliability. App updates are managed by Google through the Google Play Services, and Applivery can not force the update of an App (you can read more about this [here](https://developers.google.com/android/management/control-app-updates)). Many factors may affect the update timings. - **Default update behavior:** In the default setting, applications automatically update when specific conditions are fulfilled: - The Device connects to a Wi-Fi network. - The Device is in charging mode. - The Device is not in active use. - The application scheduled for an update is not open in the foreground. Google Play usually conducts checks for application updates daily. Therefore, it might take a maximum of 24 hours for an application update to enter the update queue. Once an application is queued, it will automatically update the next time the above conditions are satisfied. You can override the update settings to further customize the App update behavior on the Devices you manage: - **High Priority:** This mode guarantees that your App stays up-to-date, updating it immediately upon approval by Google Play. In case your Device is offline when an update is released, it will update automatically the moment you reconnect to the internet. :::warning If the App is in use when the update is ready to install, the App will be closed during the update, which could affect your users. ::: - **Postpone mode:** Use this option if you want to pause updates for an App that prevents the App to automatically updating for an initial 90 days after it first became out of date. After this 90-day period, the latest available version of the App is automatically installed using the default update mode. After the App is updated to the latest available version, a new 90 day postponement period will begin from the next time that the developer publishes a new version of the App. :::info Postpone mode does not prevent your users from manually updating the App. During the 90-day postponement period, your users can manually update the App by visiting the Google Play Store on their Devices. ::: To modify the update mode, go to any of your **Policies** 1, look for the **Apps** 2 section from the left side menu, and then click the **App** you want to modify 3 the update mode. Find the **Auto Update Mode** 4 option under the right side appearing slide and choose your preferred option. ![app auto update](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/b673fdaa-0be6-45e6-9bae-c07970c438c7.png) #### App auto update Policy As an alternative, for default configurations under **Auto Update Mode**, you can specify when updates should occur by configuring the **App Auto Update Policy**. You can find this setting by navigating to your Policy, selecting **Restrictions** from the left-hand menu, opening the **Apps** tab, and locating the **App Auto Update Policy** 5 configuration. ![app auto update policy](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/50c10534-529d-4a88-b3bc-b158e3ef07b3.png) Here, you’ll have several options to tailor App updates to your needs: - **CHOICE TO THE USER:** This option gives the end user full control over automatic updates. The Policy administrator does not impose any restrictions, allowing the user to decide when and how to update Apps. - **NEVER**: This mode completely disables automatic updates. Apps will not update on their own; the only way to update an App is manually through the App Store. - **Wi-Fi ONLY:** Apps will update automatically only when the Device is connected to a Wi-Fi network. This helps avoid using mobile data for large updates. - **ALWAYS**: Apps update automatically as soon as a new version is available, regardless of the network connection (Wi-Fi or mobile data). This is the most aggressive option and may incur mobile data charges if not monitored. Managing App updates is a key part of maintaining a secure and efficient Android environment, especially across large Device fleets.  By leveraging different update modes along with user-control options, you can strike the right balance between security and operational flexibility. A strategic approach to updates ensures Devices are protected against the latest threats, benefit from performance improvements, and minimize disruptions to end-user productivity. Ultimately, a well-defined update management Policy gives you complete control over your Android ecosystem, keeping every App up to date and fully optimized without compromising efficiency or security. ### AOSP Devices Support On AOSP Devices, App updates work differently — there is no Google Play and no Play Services involved. Updates are entirely driven by the Applivery Dashboard. **Upload a new version** Upload a new version of the App (with a higher `versionCode`) to the [Applivery Self-Service](https://docs.applivery.com/en/device-management/android/policies/agent/#self-service-portal), or update the externally-hosted APK URL. **Policy sync** The Applivery DPC detects the new version on the next Policy sync. **Download and install** The DPC downloads and installs the updated APK. The App keeps its user data unless you also explicitly clear it with the \*\*Clear app data\*\* remote command. There is no concept of "Play Store auto-update mode" on AOSP. You decide when a version becomes available by uploading it — the DPC then enforces the install automatically across all enrolled Devices assigned to that Policy. :::info Apps that fail to install (due to signature mismatch, ABI incompatibility, or minimum SDK not met) are flagged as non-compliant in the next Device status report. ::: --- ## Block & Allow Apps Source: https://docs.applivery.com/en/device-management/android/app-management/block-allow-apps/ Description: Block or allow Apps on managed Android Devices through Applivery Policies — control which Apps users can access to enforce security and compliance. TL;DR: Learn how to block or allow apps on managed Android devices using Applivery to improve security and productivity. Key topics: mobile device management, app security, app management, Applivery, Google Play, Package Name, System App, Android Whether you’re aiming to enhance security or streamline productivity, the ability to manage which applications can or cannot run on enrolled Devices is crucial. - **App blocking** involves the selective restriction of certain applications from executing on managed Devices. This can be particularly useful to mitigate security risks. By creating a block list, administrators can prevent specified Apps from launching, thereby safeguarding sensitive data. - Conversely, App allowing, often referred to as **whitelisting**, centers around permitting only a predefined list of applications to operate on enrolled Devices. This method is employed when organizations seek to optimize productivity by ensuring users have access to only the essential tools. By creating an App whitelist, administrators can ensure that only approved applications are available for use, minimizing potential security vulnerabilities. ### Allow a List of Apps **Navigate to Policies** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), go to any of your **Policies** 1. **Access App Management** From the left side menu, go to **Apps** 2 and click the **\+ Add App** button 3. **Add Apps to Whitelist** Through any of the available tabs (Google Play, Package Name, or System App), you can search for and add the applications that will be part of your whitelist of applications. **Select Installation Mode** It will only be necessary to select the desired installation mode: - **Preinstalled**: The App is automatically installed and can be removed by the user. - **Force installed**: The App is automatically installed and cannot be removed by the user. - **Available**: The App is available to install. - **Required for setup**: The App is automatically installed and can’t be removed by the user, and will prevent setup from completion until installation is complete. ![add app](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/e9a2cba9-1862-4ab8-8594-0c14c5ea4f20.png) ### Block a List of Apps **Navigate to Policies** Just like if you were configuring a whitelist of Apps, in the [**Applivery Dashboard**](https://dashboard.applivery.io/), go to any of your **Policies**. **Access App Management** From the left side menu, go to **Apps** and click the **\+ Add App** button. **Block Apps** This time, when choosing the install type of the application, you will need to select the **Blocked** option. The App will be blocked, and users won’t be able to install it. If the App was installed under a previous Policy, it will be uninstalled. ![block app](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ab69dfc4-4ab9-4a66-a552-a67e0eebf939.png) --- ## Google Chrome Managed Properties Source: https://docs.applivery.com/en/device-management/android/app-management/chrome-managed-properties/ Description: Everything you can configure in Google Chrome for Android through Applivery: deployment, managed properties, URL filtering, kiosk mode and on-device checks. TL;DR: Deploy Chrome in an Android Policy and configure its managed properties in the same place. Over 150 properties are available, list values need serialized JSON strings, and chrome://policy confirms what actually landed. Key topics: Chrome deployment, Managed properties categories, Value formats, Verification with chrome://policy, Chrome in kiosk mode, Applivery, Google Chrome, Android, Android Enterprise, Managed Google Play, Chrome Enterprise Chrome is usually the browser your Android fleet actually runs on, which makes it one of the highest-leverage Apps you can configure centrally. Applivery manages it the same way it manages any other Managed Google Play App: you deploy it through a Policy and, inside that same Policy, you set its **managed properties** — the mechanism Google uses to expose Chrome Enterprise policies on Android. From there you control URL filtering, privacy, security and general browser behavior without ever touching a Device. ### How Chrome management works in Applivery Chrome does not have its own dedicated configuration screen in Applivery. It is managed with the same generic mechanism used for any Managed Google Play App that exposes a managed configuration schema: - **App deployment.** You add Chrome to a Policy like any other Google Play App, usually as a force-installed App, since most Android Enterprise Devices already ship with it. - **Managed properties.** Google defines a configuration schema for Chrome — the Chrome Enterprise policies, in their Android variant — and publishes it on Google Play. Applivery detects that schema automatically and renders it as an editable form inside the Policy, so nobody at Applivery has to maintain a separate list. - **Applied on the Device.** The Applivery DPC applies the values through `DevicePolicyManager.setApplicationRestrictions(...)`. This works the same on Android Enterprise (AMAPI) Devices and on AOSP Devices with no Google services, as long as the App declares its restrictions schema. :::info The list of available properties is defined by Google and Chrome, not by Applivery. Applivery only detects and exposes that schema — which is why the same mechanism that works for Chrome works for any other managed App. See [Managed App Properties](https://docs.applivery.com/en/device-management/android/app-management/managed-apps-properties/) for the generic version of this flow. ::: ### Configuration **Open the Policy** Go to the [**Applivery Dashboard**](https://dashboard.applivery.io/) and open the Policy where you want to manage Chrome. **Add the App** Go to the **Apps** section in the left-hand menu and click **\+ Add App**. **Select Google Chrome** Search for **Google Chrome** in the Managed Google Play list and select it. A side panel opens with every managed property available for that version of Chrome. ![chrome managed properties](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/737cb7e5-9081-40a6-bd47-5891cf258483.png) **Fill in the properties** Set the fields you need. The categories below walk through what is available. **Save and deploy** Click **Save changes** and deploy the Policy to the relevant Device group. Changes apply automatically, usually within a few minutes. ### Available managed property categories Chrome exposes a large slice of its Chrome Enterprise policies on Android — over 150 distinct properties — though a smaller subset than on desktop. The most important exception: **Chrome for Android does not support browser extensions**, so every extension-related policy (`ExtensionInstallForcelist`, `ExtensionInstallAllowlist`, `ExtensionInstallBlocklist`, `ExtensionSettings`, `ExtensionInstallSources`, `ExtensionAllowedTypes`, `ExtensionDeveloperModeSettings`, `BlockExternalExtensions`, `EnterpriseHardwarePlatformAPIEnabled`) does not apply on Android and will not appear as configurable. What follows groups the properties most relevant to an MDM rollout by function. It is a functional summary of what each one does, not a transcription of Google's own documentation. #### 1\. Web access control

Property

What you can configure

URLBlocklist

Blocked URL patterns, up to 1,000. ["*"] blocks everything.

URLAllowlist

Exceptions to URLBlocklist. Takes precedence over the block.

IncognitoModeUrlBlocklist / IncognitoModeUrlAllowlist

Block and exception lists specific to incognito mode, independent of the general ones.

HttpAllowlist

Hosts exempt from the forced HTTPS upgrade.

HSTSPolicyBypassList

Hosts that skip HSTS preload.

SafeBrowsingAllowlistDomains

Domains excluded from Safe Browsing checks.

LookalikeWarningAllowlistDomains

Domains excluded from the "looks like another site" warning.

CertificateTransparencyEnforcementDisabledForUrls / ...ForCas

Exceptions to Certificate Transparency enforcement.

AllHttpAuthSchemesAllowedForOrigins

Origins where every HTTP authentication scheme is allowed, ignoring AuthSchemes.

SSLErrorOverrideAllowed / SSLErrorOverrideAllowedForOrigins

Whether users can continue past an SSL warning, globally or for specific origins.

:::warning Applivery has its own page with the exact syntax for these filters. Read [URL Filters](https://docs.applivery.com/en/device-management/android/troubleshooting/url-filtering/) before writing your rules. The format is `[scheme://][.]host[:port][/path][@query]`. ::: #### 2\. Web content permissions and behavior

Property

What you can configure

DefaultCookiesSetting, CookiesAllowedForUrls, CookiesBlockedForUrls, CookiesSessionOnlyForUrls, BlockThirdPartyCookies

Cookie behavior by default, per site, and for third parties.

DefaultGeolocationSetting, GeolocationBlockedForUrls, PreciseGeolocationAllowedForUrls

Site access to the user's location.

DefaultNotificationsSetting, NotificationsAllowedForUrls, NotificationsBlockedForUrls

Web push notifications.

DefaultJavaScriptSetting, JavaScriptAllowedForUrls, JavaScriptBlockedForUrls

JavaScript execution, globally or per site.

DefaultJavaScriptJitSetting and its per-site variants

JIT compilation in the JS engine — performance against attack surface.

DefaultJavaScriptOptimizerSetting and its per-site variants

Advanced JS engine optimizations.

DefaultPopupsSetting, PopupsAllowedForUrls, PopupsBlockedForUrls

Pop-up windows.

DefaultSensorsSetting and its per-site variants

Access to motion and light sensors.

DefaultSerialGuardSetting, SerialAllowAllPortsForUrls, SerialAskForUrls, SerialBlockedForUrls

Serial port access through the Web Serial API.

DefaultWebBluetoothGuardSetting

Access to nearby Bluetooth devices.

DefaultWebUsbGuardSetting, WebUsbAllowDevicesForUrls, WebUsbAskForUrls, WebUsbBlockedForUrls

Access to connected USB devices.

DefaultIdleDetectionSetting and its per-site variants

User idle detection through the Idle Detection API.

DefaultClipboardSetting, ClipboardAllowedForUrls, ClipboardBlockedForUrls

Site access to the clipboard.

DefaultAutomaticDownloadsSetting and its per-site variants

Automatic download of multiple files.

AutoplayAllowed, AutoplayAllowlist

Automatic media playback.

PaymentMethodQueryEnabled

Whether sites can check if the user has saved payment methods.

ScreenCaptureAllowed and the *CaptureAllowedByOrigins policies

Permission to share a screen, window or tab from a website.

WebXRImmersiveArEnabled

Augmented reality sessions through WebXR.

LocalNetworkAccess*, LocalNetworkAllowedForUrls, LoopbackNetworkAllowedForUrls and their block counterparts

Site access to the local network or to the Device itself (loopback). Tied to Chrome's Local Network Access restriction.

#### 3\. Privacy and browsing data

Property

What you can configure

IncognitoModeAvailability

Allow, disable or always force incognito mode.

BrowsingDataLifetime

Maximum retention per data type — history, passwords, autofill and others — in hours.

SavingBrowserHistoryDisabled

Turns off browsing history storage.

SyncTypesListDisabled

Excludes specific data types (bookmarks, passwords, tabs) from sync.

HistoryClustersVisible

Shows or hides the history view grouped by topic.

NTPContentSuggestionsEnabled

Content suggestions on the new tab page.

UrlKeyedAnonymizedDataCollectionEnabled

Sending anonymized URLs to Google to improve search and browsing.

ReduceAcceptLanguageEnabled

Reduces the Accept-Language header for privacy.

DomainReliabilityAllowed

Sending domain reliability diagnostics.

MetricsReportingEnabled

Sending anonymous usage and crash reports.

FeedbackSurveysEnabled

Product surveys built into Chrome.

RestrictAccountsToPatterns

Which Google accounts are visible inside Chrome, by name pattern.

#### 4\. Passwords, autofill and authentication

Property

What you can configure

PasswordManagerEnabled

Whether Chrome can save new passwords.

PasswordLeakDetectionEnabled

Checks whether entered credentials have appeared in a breach.

PasswordSharingEnabled

Sharing saved passwords with family group members.

ThirdPartyPasswordManagersAllowed

Whether a third-party password manager configured in Android can be used instead of Chrome's.

AutofillAddressEnabled / AutofillCreditCardEnabled

Autofill for addresses and payment cards.

BrowserSignin

Whether the user can sign in to Chrome with their Google account. Android does not support the forced mode.

AndroidEntraSsoEnabled

Automatic sign-in to Microsoft properties through the Entra ID authentication broker.

AuthSchemes, AuthServerAllowlist, AuthNegotiateDelegateAllowlist, AuthAndroidNegotiateAccountType, DisableAuthNegotiateCnameLookup, NtlmV2Enabled, GloballyScopeHTTPAuthCacheEnabled

Corporate integrated authentication (Kerberos, NTLM, Negotiate) against internal servers.

AutoSelectCertificateForUrls

Automatic client certificate selection by site pattern.

WebAuthenticationRemoteDesktopAllowedOrigins

Remote desktop App origins allowed to make WebAuthn requests.

AllowWebAuthnWithBrokenTlsCerts

Allows WebAuthn on sites with faulty TLS certificates.

OverrideSecurityRestrictionsOnInsecureOrigin

Exempts specific origins from secure context restrictions, useful for internal Apps without TLS.

#### 5\. Security and Safe Browsing

Property

What you can configure

SafeBrowsingProtectionLevel

Safe Browsing level: off, standard or enhanced.

SafeBrowsingExtendedReportingEnabled

Sending extra data to Google to improve threat detection.

SafeBrowsingProxiedRealTimeChecksAllowed

Real-time checks through a proxy that does not expose the user's IP.

DisableSafeBrowsingProceedAnyway

Stops the user from continuing past a malicious site warning.

AdsSettingForIntrusiveAdsSites

Blocks ads on sites flagged for intrusive advertising.

DownloadRestrictions

Restriction level for downloads considered dangerous.

DisableScreenshots

Blocks screenshots taken through shortcuts or extensions.

SafeSitesFilterBehavior

Adult content filter based on Google's SafeSearch API.

ForceGoogleSafeSearch

Forces SafeSearch on Google Search.

ForceYouTubeRestrict

Forces a minimum level of YouTube restricted mode.

CACertificates, CACertificatesWithConstraints, CADistrustedCertificates, CAHintCertificates, CAPlatformIntegrationEnabled

Trusted root certificate management — adding, constraining or distrusting.

HttpsOnlyMode, HttpsUpgradesEnabled, EncryptedClientHelloEnabled

HTTPS enforcement and TLS ClientHello encryption (ECH).

PreferSlowCiphers, PreferSlowKexAlgorithms

Preference for compliance-oriented cryptographic algorithms, such as CNSA.

SitePerProcessAndroid

Isolates each site in its own process (Site Isolation) on Devices with more than 1 GB of RAM.

#### 6\. Built-in generative AI features Chrome ships several AI features — Gemini, AI Mode, smart autofill — that you can also control through managed configuration:

Property

What you can configure

AIModeSettings

Availability of Google's AI mode in the address bar and new tab page.

GeminiSettings

General availability of the Gemini integration in Chrome.

GeminiActOnWebSettings, GeminiActOnWebAllowedForURLs, GeminiActOnWebBlockedForURLs

Whether Gemini can act directly on web pages on the user's behalf, optionally restricted by URL.

FindAndFillWithGeminiSettings

The "Find and fill with Gemini" feature.

FindsSettings

Chrome Finds, AI-assisted search over page content.

AutofillPredictionSettings

Form autofill assisted by generative AI.

SearchContentSharingSettings

Whether page content can be shared with AI Mode or Lens from the side panel.

ThirdPartyAiChatSettings

Third-party AI integrations in the address bar, when the default search engine is not Google.

GenAILocalFoundationalModelSettings

Download and use of the local AI model for on-device inference.

:::info All of these AI policies fall back to `GenAiDefaultSettings` when left undefined. If your organization has a general stance on generative AI, set that default first and then fine-tune each feature. ::: #### 7\. Browsing, bookmarks and search

Property

What you can configure

HomepageLocation

Homepage URL.

HomepageIsNewTabPage

Uses the new tab page as the homepage.

ShowHomeButton

Shows the home button in the toolbar.

BookmarkBarEnabled / EditBookmarksEnabled

Bookmark bar visibility, and whether the user can edit bookmarks.

ManagedBookmarks

Deploys a predefined bookmark folder, with subfolders, that the user cannot modify.

The DefaultSearchProvider* family (Enabled, Name, SearchURL, SuggestURL, ImageURL, Encodings, AlternateURLs and their *PostParams variants)

Configures or forces your own default search engine instead of leaving the choice to the user.

SearchSuggestEnabled

Search suggestions in the address bar.

ContextualSearchEnabled

The Touch to Search feature.

TranslateEnabled

Built-in page translation.

PrintingEnabled

Whether printing from Chrome is allowed.

QRCodeGeneratorEnabled

The built-in QR code generator.

ShoppingListEnabled

Price tracking for products seen in the browser.

EnableMediaRouter

Google Cast availability.

ListenToThisPageEnabled

Read-aloud for web pages.

SharedClipboardEnabled

Sending text between desktop Chrome and an Android Device linked by account.

#### 8\. Session, account and cloud management

Property

What you can configure

TosDialogBehavior

Skips the Terms of Service dialog on first use. Applies only to Chrome Custom Tabs (CCT) on Fully Managed Devices.

CloudManagementEnrollmentToken

Token for Chrome to enroll in Chrome Enterprise Core, Google's cloud management, alongside management through Applivery and AMAPI.

CloudPolicyOverridesPlatformPolicy, CloudUserPolicyMerge, CloudUserPolicyOverridesCloudMachinePolicy

Precedence rules between cloud policies (Chrome Enterprise Core) and platform policies, the ones arriving through Applivery.

PolicyAtomicGroupsEnabled, PolicyDictionaryMultipleSourceMergeList, PolicyListMultipleSourceMergeList

Merge rules when the same policy arrives from more than one management source.

:::info This block only matters if your organization also manages Chrome from the Google Admin console (Chrome Enterprise Core) on top of Applivery. If Applivery is your only management source, you normally do not need to touch these properties. ::: #### 9\. Network, proxy and performance Chrome also exposes a broad set of infrastructure policies: DNS (`DnsOverHttpsMode`, `DnsOverHttpsTemplates`, `BuiltInDnsClientEnabled`), proxy (`ProxySettings`, per-proxy connection limits), WebRTC (`WebRtcEventLogCollectionAllowed`, `WebRtcUdpPortRange`) and component updates (`ComponentUpdatesEnabled`). They matter mostly in environments with a mandatory corporate proxy or restrictive network policies. They are not listed row by row here because they are rarely used in a standard MDM rollout, but they follow exactly the same managed properties mechanism as everything else. #### Internal rendering engine policies Chrome also publishes a considerable number of internal rendering engine policies — temporary web compatibility flags, back/forward cache behavior, Service Workers, CORS — aimed at web platform migrations rather than MDM administration. They are not listed here because they have little practical relevance for an IT admin. If you ever need one, you configure it exactly like the rest: search for it by name in Chrome's managed properties form inside the Applivery Policy. :::info The form you actually see in Applivery for the Chrome App is generated dynamically from the schema Google declares on Play, so it can vary slightly depending on the published Chrome version. Before assuming a very specific field is available, check it directly in the Dashboard when you select the App. ::: ### Value formats: watch out for lists and booleans When you fill in managed properties for Chrome, keep two things in mind: - **List values** — such as `URLBlocklist` or `URLAllowlist` — must be entered as a **serialized JSON string**, not as a native array. For example, `["facebook.com"]` as text, not as a set of separate fields. This is empirically verified for Chrome on Android through `chrome://policy`, with `Status: OK`. - **Boolean values** — such as `SavingBrowserHistoryDisabled` — and **integer or enum values** — such as `IncognitoModeAvailability` or `SafeBrowsingProtectionLevel` — are sent as the numeric value or `true`/`false` defined by Chrome's schema, not as free text. :::warning If a list field does not apply, or the Device seems to ignore it, check the format first — serialized JSON string — before assuming the property is unsupported. ::: ### Verify the configuration with chrome://policy Once the Policy is deployed, the most reliable way to confirm Chrome received the configuration is on the Device itself: **Open Chrome** Open Chrome on the managed Device. **Go to chrome://policy** Navigate to `chrome://policy`. **Find your property** Look for the property you configured, `URLBlocklist` for example. **Check the status** Confirm **Status** shows **OK**. A parse error or "Ignored" means the value could not be applied — usually a formatting problem, or a property that is not supported in that version of Chrome. **Show the value** Click **Show value** to confirm the applied content matches what you configured in Applivery. :::info `chrome://policy` is Chrome's own source of truth, independent of Applivery. If the status is correct there, the configuration reached the Device properly. ::: ### Chrome in kiosk mode Chrome can also act as the browser behind an Applivery **web App in kiosk mode**. Add Chrome from the Google Play tab with the **Force install** install type, then set it as the browser for the web App inside the Policy. That lets you display a specific URL full screen, as the Device's only App. See [Web Apps](https://docs.applivery.com/en/device-management/android/app-management/web-apps/) and [Kiosk Mode](https://docs.applivery.com/en/device-management/android/policies/kiosk-mode/) for the remaining options, including the basic launcher, the advanced launcher and AOSP support. ### Troubleshooting

Symptom

Likely cause

The list field blocks nothing

The value is not serialized as a JSON string.

chrome://policy shows a parse error

Wrong value format for the field type — list against boolean against integer.

An expected property is missing from the Applivery form

It may not be available in the Chrome version published on Play for that Device, or it may need a minimum Android version. Check in the Dashboard before assuming support is missing.

Changes never reach the Device

Check the Policy was actually deployed to the right Device group, not just saved.

--- ## Connect your Google Play Console Source: https://docs.applivery.com/en/device-management/android/app-management/connect-google-play-console/ Description: Connect your Google Play Console account to Applivery MDM for advanced private App management, deployment, and control. TL;DR: Connect your Google Play Console to Applivery MDM to gain advanced control over private app management and deployment. Key topics: Google Play Console integration, Applivery MDM configuration, Private app management, Managed Google Play, Google Play Console, Applivery MDM, Google, Android :::warning Connecting a Google Play Console account requires Google Mobile Services and is **not available on AOSP Devices**. On AOSP, private App Distribution is handled through the [Applivery Self-Service](https://docs.applivery.com/en/device-management/android/policies/agent/#self-service-portal) — no Google Play account needed. See [AOSP Android Management](https://docs.applivery.com/en/device-management/android/aosp/) for details. ::: Applivery MDM relies on Google’s Managed Google Play for Apps Management and distribution. The standard Managed Google Play will be sufficient for your use case if you want to use public Google Apps already generally available in Google Play. It will also enable you to deploy and manage Private Apps in a very straightforward –but limited– way. However, if you need to manage Private Apps in a very advanced way, sometimes you would prefer to use your own Google Play Console account to manage your Apps. That could be the case if you want to: - Have full control over the Google Play Console Account. - Connect your own CI & CD pipelines to automate Private Apps Deployment. - Share your Private Apps with other organizations. **Log in to Google Play Console** Go to the [Google Play Console](https://play.google.com/console) and log in using your credentials. Once logged in, select one of your Developer Accounts. ![developer-account | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/02d8387b-824b-445b-bab8-feecf8e90c64.png) **Configure App Settings** Once inside the Google Play Console, select one of your Apps and go to **Setup > Advanced Settings> Managed Google Play**. Under the Organizations section, you will see the list of Organizations that have access to that App. ![managed-google-play | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ecdad579-5a63-4f50-bbe5-b2dba80213fd.png) **Add Applivery Organization** Click the **Add organization** button to add your Applivery MDM organization. The form will request your name and the Applivery Organization ID. Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), navigate to the **Settings** section, and from the left-hand menu select **Android Setup**. At the top, you’ll find the Applivery Enterprise ID. ![enterprise id](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/8f73b2cb-7461-49bb-8e7f-845bd3d8cb25.png) **Save Changes** Click **Add** and then **Save changes**. Now your Private App will be visible in the Applivery MDM Managed Google Play, and you will be able to select it as any other application from the **Apps** section of your Policies. Just click the **\+ Add App** button and search for the name of the App or the Package name. :::info Google could take **up to 72 hours** to make your Private Apps visible across the new organizations. We recommend planning this configuration for any critical deployment. ::: --- ## Google Play Customization Source: https://docs.applivery.com/en/device-management/android/app-management/customize-managed-google-play-layout/ Description: Customize the Managed Google Play layout with App collections to simplify access on Android Devices and reduce security risks. TL;DR: Customize Managed Google Play through Applivery to organize work apps into collections, making it easier for employees to find and install the tools they need. Key topics: Managed Google Play, App Management, Android Device Management, Applivery, Google :::warning Managed Google Play layout customization requires Google Mobile Services and is **not available on AOSP Devices**. AOSP Devices do not have access to Google Play — Apps are distributed through the [Applivery Self-Service](https://docs.applivery.com/en/device-management/android/policies/agent/#self-service-portal) instead. ::: Customizing the layout of Managed Google Play lets organizations create a structured and user-friendly App storefront for their Android fleet. IT admins can organize approved Apps into collections, pages, and clusters, ensuring employees can quickly find and install relevant tools. This tailored approach boosts productivity and clarity, enabling businesses to present work Apps by category and simplify navigation—providing a branded, intuitive experience for end users across all managed Devices. ### Play Store setup Once in the [**Applivery Dashboard**](https://dashboard.applivery.io), go to any of your **Policies** 1. From the left-side menu, go to **Apps** 2 and click the **\+ Add App** button 3. ![add app](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ab8de9c1-6b8b-42a8-83d9-706ee93132d5.png) This will open your **Managed Google Play iFrame**. Once it loads, click **Organize Apps** 4 to start arranging your App layout, then select **Create a collection** 5. ![organize Apps](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/0fe43eb7-5630-4804-9efd-f49fabc36b0f.png) Enter the name you want for the collection and click **Next**. Then, select the applications you’d like to include and click **Add Apps** 6. Your collection will now appear in the list of created collections. Finally, click **Save**. ![create collection](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/f48655b6-a215-4b81-9796-053576abe0e6.png) Once the Policy is saved, employees accessing Managed Google Play from their Devices will see a dedicated **Work Apps** section. There, they’ll find the collections you’ve created and can directly download the applications included in each one. ![device play store](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/b2fdc7a2-1bdb-47ce-9432-56f378498b93.png) Collections in Managed Google Play allow organizations to centralize and simplify access to work-related applications. This feature helps administrators ensure employees can easily find the tools they need, boosting productivity and minimizing security risks. With just a few steps, you can create a more organized, secure, and efficient workspace. :::tip Regularly review and update your Managed Google Play collections to ensure employees have access to the most relevant and up-to-date Apps. ::: --- ## Default Applications Source: https://docs.applivery.com/en/device-management/android/app-management/default-applications/ Description: Set the default browser, dialer, SMS, wallet or launcher on managed Android Devices from your Applivery Policy, and stop users from changing them. TL;DR: Set the default browser, dialer, SMS, assistant, wallet or launcher from your Android Policy in Applivery, using a prioritized list of candidate Apps. Key topics: Default Applications, Android Enterprise Policies, Application types and scopes, Status reporting and non-compliance, Applivery, Android, Android Enterprise, Android Management API (AMAPI), Google, Google Play Store Android lets the user pick which App handles core system roles: which browser opens a link, which App places a call, which one receives SMS. On a corporate fleet that choice is rarely something you want to leave open. If half your Devices open corporate links in a browser you do not manage, or a technician answers work calls from a personal dialer, you lose both consistency and control. **Default Applications** let you decide those roles centrally. You define which App should handle each system role, Applivery pushes it through the Android Management API (AMAPI) `defaultApplicationSettings` Policy field, and the user can no longer change it while the setting stays active. Typical uses: - Force a corporate browser, such as Chrome, as the default browser. - Fix the dialer or the SMS App on company Devices. - Set the default voice assistant or digital wallet across a managed fleet. - Pin the launcher (Home) on Fully Managed Devices. :::warning Do not confuse this with **Persistent Preferred Activities**. AMAPI has an older mechanism, `persistentPreferredActivities`, that also pins an intent handler by default — used for kiosk scenarios, for example. Google states explicitly that `defaultApplicationSettings` and `persistentPreferredActivities` must **not** be configured for the same intent domain, such as web browsing, because the result is unpredictable. ::: ### How it works Each default App you set is one entry in the `defaultApplicationSettings` array of the Policy, and every entry is built from three elements:

Element

What it does

Type (defaultApplicationType)

The system role you want to pin — browser, dialer, SMS, and so on. See the table below for every supported type.

Applications (defaultApplications)

A prioritized list of candidate Apps, by packageName. AMAPI picks the first one on the list that is installed on the Device and valid for that role.

Scopes (defaultApplicationScopes)

Where the setting applies: Fully Managed, Work Profile, personal profile, or a combination.

The prioritized list is what makes this practical across mixed hardware. List your preferred App first and a fallback second, and each Device resolves to whichever one it actually has. For a non-system App to become the default, the fingerprint of its signing certificate on the Device must match the one obtained from the Google Play Store, or one of the entries declared in `signingKeyCerts` for that App in the Policy. ### Supported default application types

Type

Description and requirements

DEFAULT_ASSISTANT

Voice assistant App. Only valid for SCOPE_FULLY_MANAGED. Requires Android 16+ on Fully Managed Devices.

DEFAULT_BROWSER

Default browser. Requires Android 16+.

DEFAULT_CALL_REDIRECTION

Call redirection App. Not applicable to SCOPE_PERSONAL_PROFILE. Requires Android 16+.

DEFAULT_CALL_SCREENING

Call screening App. Not applicable to SCOPE_PERSONAL_PROFILE. Requires Android 16+.

DEFAULT_DIALER

Phone dialer. Supported on Fully Managed Devices from Android 14/15, and across every management mode from Android 16.

DEFAULT_HOME

Launcher / home screen. Only valid for SCOPE_FULLY_MANAGED. Requires Android 16+.

DEFAULT_SMS

SMS App. Not applicable to SCOPE_WORK_PROFILE. Supported on company-owned Devices from Android 16.

DEFAULT_WALLET

Digital wallet App. Cross-profile role. Supported on company-owned Devices from Android 16.

:::info Some roles, such as `DEFAULT_WALLET`, apply across profiles. On a company Device with a Work Profile you can set the default App either in the Work Profile or in the personal profile, but not in both at the same time. ::: ### Scopes - `SCOPE_FULLY_MANAGED`: applies to Fully Managed Devices (Device Owner). - `SCOPE_WORK_PROFILE`: applies to the Work Profile, both on company Devices with a Work Profile (COPE) and on personal Devices with a Work Profile (BYOD). - `SCOPE_PERSONAL_PROFILE`: applies to the personal profile on company-owned Devices with a Work Profile. When you set a default App for `SCOPE_FULLY_MANAGED` or `SCOPE_WORK_PROFILE`, that App needs a matching entry in the **Applications** section of the Policy, with an `installType` other than `BLOCKED`. When the target scope is `SCOPE_PERSONAL_PROFILE`, you can only set preinstalled system Apps as defaults. ### Compatibility by management mode and Android version

Management mode

Android 14 – 15

Android 16+

Fully Managed

DEFAULT_DIALER only

All supported types

Company-owned with Work Profile (COPE)

Not supported

Work Profile: BROWSER, CALL_REDIRECTION, CALL_SCREENING, DIALER, WALLET.
Personal profile: BROWSER, DIALER, SMS, WALLET.

Personally-owned with Work Profile (BYOD)

Not supported

Work Profile: BROWSER, CALL_REDIRECTION, CALL_SCREENING, DIALER.
Personal profile: not supported.

### Before you start - A Device running Android 14 or later. Android 16+ is recommended, since it unlocks every default App type. - A compatible Android Enterprise management mode — Fully Managed, COPE, or BYOD with a Work Profile — depending on the type of default App you want to set. - The candidate Apps added to the **Applications** section of the Policy with an `installType` other than `BLOCKED`, except for preinstalled system Apps in the personal profile. - The exact `packageName` of every candidate App. - Confirmation that the same Policy has no `persistentPreferredActivities` entry for the same intent domain, to avoid conflicts. ### Configuration **Navigate to Policies** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), go to **Policies** 1 and select the Android Policy you want to modify. **Add the candidate Apps** In the **Apps** 2 section of the Policy, add every App you plan to use as a default — browser, dialer, and so on — with an `installType` other than `BLOCKED`, such as `AVAILABLE` or `FORCE_INSTALLED`. ![android apps](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/06e7e486-ca35-4452-a128-8c7c9c414ee0.png) **Access All properties** From the left-hand menu, click the **All properties** 3 section. **Find Default Application Settings** In the search field, type `defaultApplicationSettings` to locate the **Default Application Settings** configuration object. **Define the default App** Set the three values for this entry: - **Scope**: Fully Managed, Work Profile, or Personal Profile. - **Type**: Assistant, Browser, Call Redirection, Call Screening, Dialer, Home, SMS, or Wallet. - **Package Name**: the package name of the App you want as the default for the type you just selected. ![default app settings](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/e097a0c8-25e8-432f-9947-3ff4529989d1.png) Repeat for every role you want to pin. **Enable status reporting (optional)** If you want feedback on which defaults actually landed, enable `defaultApplicationInfoReportingEnabled` inside `statusReportingSettings`. **Save and sync** Save the Policy and sync it with your Devices, either automatically on the next check-in or by forcing a manual sync from the Device detail page. ### Example Policy This Policy sets Chrome as the default browser and defines a prioritized dialer list, with status reporting enabled: ```json { "applications": [ { "packageName": "com.android.chrome", "installType": "AVAILABLE" }, { "packageName": "com.google.android.dialer", "installType": "AVAILABLE" }, { "packageName": "com.samsung.android.dialer", "installType": "AVAILABLE" } ], "statusReportingSettings": { "defaultApplicationInfoReportingEnabled": true }, "defaultApplicationSettings": [ { "defaultApplicationType": "DEFAULT_BROWSER", "defaultApplications": [ { "packageName": "com.android.chrome" } ], "defaultApplicationScopes": [ "SCOPE_FULLY_MANAGED", "SCOPE_WORK_PROFILE" ] }, { "defaultApplicationType": "DEFAULT_DIALER", "defaultApplications": [ { "packageName": "com.google.android.dialer" }, { "packageName": "com.samsung.android.dialer" } ], "defaultApplicationScopes": [ "SCOPE_FULLY_MANAGED", "SCOPE_WORK_PROFILE", "SCOPE_PERSONAL_PROFILE" ] } ] } ``` Here, AMAPI tries to set `com.google.android.dialer` as the default dialer. If that App is not installed on the Device, it falls back to `com.samsung.android.dialer`, following the priority order of the `defaultApplications` list. ### Status reporting From Android 16 onwards, Device status reports include a `defaultApplicationInfo` field whenever `defaultApplicationInfoReportingEnabled` is turned on in `statusReportingSettings`. For each application type, the report tells you: - `packageName`: the App currently set as the default for that type, whether it was pinned by the Policy, set by the system, or chosen by the user. - `defaultApplicationSettingAttempts`: the outcome of each attempt to apply the Apps on your prioritized list. This is what you read when a higher-priority App did not take effect and you need to know why. On Fully Managed Devices the report covers every application type. On Devices with a Work Profile it covers only the types supported for that profile. ### Non-compliance reasons

Reason

What it means

API_LEVEL

The feature is not supported on the Device's Android version.

MANAGEMENT_MODE

The feature is not supported for the Device's management mode, or none of the scopes set in the Policy applies to that mode (specific reason DEFAULT_APPLICATION_SETTING_UNSUPPORTED_SCOPES).

APP_NOT_INSTALLED

None of the Apps on the prioritized list is installed on the Device.

INVALID_VALUE

At least one App is installed but the setting cannot be applied for another reason — the App is not valid for that role, for example. For the personal profile a generic INVALID_VALUE is reported, without revealing the install state of personal Apps.

### Important considerations - Never configure `defaultApplicationSettings` and `persistentPreferredActivities` for the same intent domain, such as web browsing, in the same Policy. The behavior becomes unpredictable. - Every candidate App must exist in the **Applications** section of the Policy with an `installType` other than `BLOCKED`, except for system Apps in the personal profile. - For non-system Apps, the signing certificate on the Device must match the one from the Google Play Store or an entry declared in `signingKeyCerts`. - Actual support depends on the Android version and the management mode of each Device. Check the compatibility table above before you roll anything out. - For cross-profile roles such as `DEFAULT_WALLET`, you cannot pin the default in the Work Profile and in the personal profile at the same time. - Once the Policy applies, the user cannot change the default App for that role manually while the setting stays active. ### Verification and troubleshooting **Sync the Device** After saving the Policy, sync the Device manually from its detail page in Applivery, or wait for the next check-in. **Check the status report** If you enabled `defaultApplicationInfoReportingEnabled`, review the Device status report to confirm which App ended up as the default for each type. **Test it on the Device** Trigger the matching action on the Device — open a link, start a call — and confirm it runs straight into the configured App, with no App chooser in between. **Read the non-compliance details** If the behavior is not what you expected, check the Device's non-compliance details (`API_LEVEL`, `MANAGEMENT_MODE`, `APP_NOT_INSTALLED`, `INVALID_VALUE`) to identify the cause. **Re-check the App** Confirm the candidate App is genuinely installed and that its `installType` in the Policy is not `BLOCKED`. Default Applications turn a user preference into a managed setting. Combined with a prioritized candidate list, they give you one predictable behavior across a fleet that mixes hardware, Android versions and management modes, and they take the guesswork out of which App handles the roles your organization actually depends on. --- ## Forced Install Apps Source: https://docs.applivery.com/en/device-management/android/app-management/forced-install-apps/ Description: Auto-install Android Apps on managed Devices using Managed Google Play or Applivery Self-Service — ensure consistent configurations across your organization. TL;DR: Automatically install and manage apps on Android devices using Applivery and Managed Google Play for streamlined mobile device management. Key topics: Managed Google Play, Automatic app installation, Android Enterprise, Applivery MDM, App Management Policies, Android, Google Play Store, Applivery **Automatic App installation** allows IT admins to remotely deploy applications to managed Android Devices without requiring user interaction. With Applivery, applications can be installed silently and efficiently across any size fleet—ideal for ensuring all employees have the critical tools they need for work, security compliance, or kiosk environments. Apps are assigned within Policies and pushed directly from the Dashboard, simplifying rollout and reducing support needs. Admins gain total control over which Apps are installed, updated, or removed, and can automate deployments for new Devices, role changes, or updates, guaranteeing consistent configurations across the organization. Applivery supports both [system](https://docs.applivery.com/en/device-management/android/app-management/system-apps/) and [third-party](https://docs.applivery.com/en/device-management/android/app-management/private-app-managed-google-play/) Apps, with advanced features to configure [managed properties](https://docs.applivery.com/en/device-management/android/app-management/managed-apps-properties/), automate updates, and enforce App compliance—making Device management effortless and robust for enterprise environments. ### Managed Google Play The secret behind automatic App installation in Android Enterprise—and of course with Applivery—is **Managed Google Play**. Think of it as a special version of the Google Play Store, designed specifically for your organization. With Managed Google Play, **you control** which Apps are available to your employees and how they get installed. Applivery connects directly to your Managed Google Play account, allowing you to manage and distribute Apps **centrally and automatically**—no manual installs needed! ### How to set up automatic App installation **Make sure your Devices are enrolled** To ensure everything runs smoothly, your Android Devices must already be registered and managed under Android Enterprise in Applivery. This means your [Android Enterprise account is properly set up](https://docs.applivery.com/en/device-management/android/get-started/) and your Devices are enrolled—whether they’re Company-Owned Devices, Work Profiles, or otherwise. **Add and approve your Apps in Managed Google Play** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io), go to any of your **Policies** 1. From the left side menu, go to **Apps** 2 and click the **\+ Add App** button 3. ![add app](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/9b2dbdc5-97ff-4784-8761-3631da886f4f.png) The **Managed Google Play iFrame** will open, allowing you to select from the following App types: - **Public Apps** 4: If the Apps are available on the regular Google Play Store, simply search for them and approve them directly from the Managed Google Play section in your Applivery Dashboard. Once approved, you can manage and assign them to your Devices. - **Private Apps** 5: For Apps developed internally for your company, you can upload them as [**private Apps**](https://docs.applivery.com/en/device-management/android/app-management/private-app-managed-google-play/) to Managed Google Play directly from Applivery. Only your organization will have access to these Apps. - **Web Apps** 6: You can also turn your favorite websites into [**Web Apps**](https://docs.applivery.com/en/device-management/android/app-management/web-apps/) within Managed Google Play, then deploy them automatically to Devices as if they were native Apps. ![managed google play](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/c6b3442b-ea74-43cb-a699-2eb8165ee18d.png) **Assignment and install type** The install type decides whether the App lands on the Device on its own, whether the user can get rid of it, and whether setup waits for it. These are Android Enterprise install types, so the behavior below is Android's, not Applivery's.

Install type

Installed automatically

Behavior

Force installed

Yes

Installed regardless of any maintenance window, and the user cannot remove it.

Preinstalled

Yes

Installed automatically, but the user can remove it afterwards.

Available

No

Offered in Managed Google Play for the user to install. This is the default when no install type is set.

Blocked

No

Cannot be installed, even if the user searches for it in Managed Google Play. If it was installed under a previous Policy it is uninstalled, and its instant app functionality is blocked too.

Required for setup

Yes

Installed automatically and not removable, and Device setup does not finish until the install completes.

Kiosk

Yes

Set as the preferred home intent and allowlisted for lock task mode. Setup waits for it, the user cannot remove it, and the status bar is disabled automatically. Only one App per Policy can use it.

:::warning **Preinstalled is sent once, and never re-sent.** If the App later disappears from the Device — the user removed it, or anything else — the Policy does **not** put it back. That is the logical consequence of letting the user remove it in the first place. To recover missing **Preinstalled** Apps, switch them temporarily to **Force installed**, let the Devices sync, and switch them back. Returning them to **Preinstalled** does not uninstall anything. ::: ![app install type](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/26bd603c-e61e-4e5f-8f85-2d17976891e2.png) :::info Keep in mind that there’s also an important **Policy-level setting** that affects how the **Available** installation option behaves. The **Play Store Mode** controls which Apps are visible to users in the Play Store and how the Device handles Apps that are removed from the Policy. By default, it is set to **WHITELIST**, meaning only Apps included in the Policy are available, and any App not in the Policy will be automatically uninstalled. You can also set it to **BLACKLIST**, where all Apps are available by default, and only the Apps you explicitly mark as **Blocked** will be restricted or removed from the Device. ::: Applivery’s automatic App installation via Managed Google Play makes managing Android Devices much easier. By setting Apps as **mandatory**, you can ensure that your business applications are deployed quickly, efficiently, and consistently across all Devices. ### AOSP Devices Support :::warning Automatic App installation through **Managed Google Play** requires Google Mobile Services and is **not available on AOSP Devices**. ::: On AOSP Devices, Apps are force-installed through the [**Applivery Self-Service**](https://docs.applivery.com/en/device-management/android/policies/agent/#self-service-portal) instead. To force-install an App: Refer to our documentation, How to Distribute Private Android Apps via MDM, and follow the steps described there. **Add the Apps to a Policy** Refer to our documentation, [How to Distribute Private Android Apps via MDM](https://docs.applivery.com/en/device-management/android/app-management/private-app-distribution/), and follow the steps described there. **Define the Install Type** Set Install Type to **Force Installed** or **Kiosk**. The DPC will silently download and install the APK during the next Policy sync. The install types available on AOSP are:

Install Type

Behavior

Force Installed

App is installed silently at first sync and kept installed. Users cannot uninstall it.

Kiosk

App is force-installed and pinned to the screen in Single App kiosk mode.

There is no **Available** or **Blocked** concept through Google Play on AOSP — Apps not in the Policy are simply not distributed to the Device. --- ## Managed App Properties Source: https://docs.applivery.com/en/device-management/android/app-management/managed-apps-properties/ Description: Configure managed App properties on Android Devices using Applivery MDM — customize App behavior remotely and ensure a consistent user experience for IT admins. TL;DR: Configure Android app settings remotely with Applivery's Managed Properties feature for consistent and secure user experiences. Key topics: Managed Properties, Applivery, Android App Configuration, MDM Policies, Android, MDM, SSL When managing Android Devices with Applivery, it’s not just about installing or blocking Apps. Many applications allow you to adjust their behavior through what are known as **Managed Properties**. These properties let you preconfigure certain aspects of Apps (such as URLs, permissions, default behavior, etc.) even before the user opens them for the first time. Everything is done from the Applivery Dashboard—no need to touch the Device. ### What are Managed Properties? **Managed Properties** are configuration options that an App offers when it is managed through an MDM system. For example, an email App might allow you to preconfigure the server, port, and whether SSL is required. Applivery automatically detects these properties in compatible Apps and allows you to modify them from the Dashboard. ### How to configure them? **Navigate to Policies** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), go to any of your **Policies 1.** Select the **Apps** 2 section in the left-hand menu, and click the **\+ Add App** button 3. ![add app](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/052e37a7-4cf2-49e3-898d-e51a7b2d2db2.png) **Choose an App** Choose an **App** 4 from the list, and when you click on it, a side menu will appear displaying all the **configurable properties available** 5. **Configure Managed Properties** Simply fill in the fields based on the settings you want to apply. **Save and Deploy** Once you’re done, click the **Save changes** button 6 and deploy the Policy to the selected group of Devices—the settings will be applied automatically. ![managed properties](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/d51b87c2-6a45-4054-b011-5c80db8eaee9.png) Managed Properties are a powerful tool for customizing how Apps behave on managed Devices, without relying on the end user. They help save time, reduce configuration errors, and ensure a more consistent and secure user experience. All from the Applivery Dashboard, with just a few clicks. ### AOSP Devices Support Managed App properties are fully supported on AOSP — same steps, same experience. The Applivery DPC applies them at install time using `DevicePolicyManager.setApplicationRestrictions(...)`, no Google services required. Any App that exposes a managed configuration schema (`` in its manifest) works the same way. --- ## Configure Microsoft Defender Source: https://docs.applivery.com/en/device-management/android/app-management/microsoft-defender/ Description: Configure Microsoft Defender for Android on managed devices using Applivery's Managed Properties — no user interaction required. TL;DR: Add Microsoft Defender to your Android Policy in Applivery, configure its Managed Properties, and deploy — Defender will be set up automatically on enrolled Devices before the User ever opens it. Key topics: Microsoft Defender for Android configuration, Managed Properties, Android Enterprise security, Microsoft Defender, Android, Applivery, Managed Google Play, Device, App, Policy Microsoft Defender for Android supports remote configuration through [Managed Properties](https://docs.applivery.com/en/device-management/android/app-management/managed-apps-properties/), which means you can control its behavior directly from the Applivery Dashboard — no user interaction required. The configuration is pushed to the Device before the User opens the App for the first time. **Add Microsoft Defender to your Policy** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), go to any of your **Policies** 1 or [create a new one](https://docs.applivery.com/en/device-management/general-settings/create-policies/)**,** and select the **Apps** 2 section from the left-hand menu. Click **\+ Add App** 3 and search for **Microsoft Defender: Antivirus** from the Managed Google Play tab. ![add app](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/052e37a7-4cf2-49e3-898d-e51a7b2d2db2.png) **Configure Managed Properties** Once you select the App, a side panel will open with all available Managed Properties. ![microsoft defender managed properties](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/706bc0f3-ef80-409a-8a9b-55aaf529f0ba.png) Fill in the parameters according to your organization's needs:

Parameter

Default

Description

Anti-Phishing

1 (enabled)

Protects against malicious URLs. Available on Fully Managed and Dedicated Devices only.

VPN

1 (enabled)

Routes Device traffic through Defender for real-time threat inspection.

Microsoft Defender

1 (enabled)

Main protection toggle. Disabling this turns off all active Defender features.

Defender on Personal Profile (COPE)

Not configured

Extends Defender protection to the personal profile on COPE-enrolled Devices.

Hide URLs in Reports

Not configured

Prevents URLs from being logged in Defender's security reports.

:::info Keep **Anti-Phishing** and **Defender Protection** set to `1`. Disabling either would leave Devices without active threat detection and phishing coverage. ::: :::warning Anti-Phishing and VPN protection only apply to **Fully Managed** and **Dedicated** Devices. On COPE Devices, use the **Defender on Personal Profile** setting to extend coverage to the personal profile. ::: **Save and deploy** Click **Save changes** and deploy the Policy to your target Devices. Defender will be fully configured automatically — before the user opens the App for the first time. --- ## Distribute Private Apps using App Distribution Source: https://docs.applivery.com/en/device-management/android/app-management/private-app-distribution/ Description: Deploy private Android Apps through Managed Google Play with step-by-step instructions for IT admins — including update modes and troubleshooting. TL;DR: Distribute internal Android apps securely on managed devices using Applivery, bypassing public app stores and maintaining full control over app versions and access. Key topics: app-distribution, android-enterprise, mobile-device-management, Applivery, Android Enterprise, Google Play Applivery App Distribution enables organizations to securely **manage and distribute Private Apps on Fully Managed Android Devices** without relying on external App Stores such as Google Play. By combining App Distribution with Device Management in an Android Enterprise (Fully Managed) deployment model, administrators can maintain full control over application versioning, access permissions, and deployment workflows from a centralized Dashboard. :::info **AOSP Devices** can also distribute private Apps through the [**Applivery Self-Service**](https://docs.applivery.com/en/device-management/android/policies/agent/#self-service-portal) using the same workflow — no Google Play account needed. ::: This approach is especially valuable when: - Distributing internal or enterprise-only applications. - The App is not intended for publication in Google Play. - Strict control over build versions and staged rollouts is required. - Applications must be deployed to specific Device Groups, Segments, or Policies. With Applivery, Private Apps can be created and configured directly within the platform, updated through controlled build uploads, distributed automatically via Policies, and managed alongside other enterprise Resources and configurations—ensuring a secure, compliant, and fully integrated Android Enterprise mobility strategy. **Create your first App** You can follow the instructions on how to create your first application by following [this link](https://docs.applivery.com/en/app-distribution/getting-started/create-first-app/). **Upload your first build** You can follow the instructions on how to upload your first build by following [this link](https://docs.applivery.com/en/app-distribution/getting-started/upload-first-build/). **Add your App to a Policy** Now, navigate to any of your **Policies** 1. From the left side menu, go to **Apps** 2 and click the **\+ Add App** 3 button. Then select the **Applivery** 4 tab and select the **App** 5 you just uploaded. After selecting the App, you will be able to choose the specific Build according to your requirements and define the installation type. ![add app from app distribution](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/cee02304-6fa6-495b-8f56-793d5f9f093a.png) :::warning This feature requires the [Applivery MDM Agent](https://docs.applivery.com/en/device-management/android/policies/agent/) to be enabled at the Policy level, the App to have been opened at least once, and all permissions to be granted. ::: Managing and distributing Private Apps through Applivery App Distribution provides organizations with a secure, centralized, and fully controlled deployment workflow. By creating your application, uploading Builds, and assigning the App through Policies or direct Device deployment, you can ensure that the right users receive the right version at the right time. This approach eliminates dependency on external App Stores, simplifies version management, and enables controlled rollouts across your Device fleet. With Applivery’s integrated Device Management capabilities, Private App distribution becomes a seamless part of your overall Enterprise Mobility strategy, improving operational efficiency while maintaining governance and security. --- ## Distribute Private Apps Using Managed Google Play Source: https://docs.applivery.com/en/device-management/android/app-management/private-app-managed-google-play/ Description: Upload private Android Apps to Managed Google Play. Create, update, and control App updates for your organization's Devices. TL;DR: Learn how to manage and distribute private Android apps using Applivery MDM through Google's Managed Google Play Console. Key topics: Private App Management, Applivery MDM, Google Play Console, Android App Distribution, App Updates, Applivery, Android, Google Play Services, Fastlane, Bitrise :::warning Distributing private Apps through Managed Google Play requires Google Mobile Services and is **not available on AOSP Devices**. On AOSP, private Apps are distributed directly through the [**Applivery Self-Service**](https://docs.applivery.com/en/device-management/android/policies/agent/#self-service-portal). See [AOSP Android Management](https://docs.applivery.com/en/device-management/android/aosp/) for details. ::: Applivery Device Management allows you to manage and distribute your Private Apps in three different ways: - As a Self-hosted Private App managed outside the Google Play Console (you can read more [here](https://docs.applivery.com/en/app-distribution/platforms/android/self-hosted-private-apps/)). - As a Self-hosted Private App managed through Applivery App Distribution (you can read more [here](https://docs.applivery.com/en/device-management/android/app-management/private-app-distribution/)). - As a Private App managed through the [Google Play Console](https://play.google.com/console). It provides two options: 1. Use Google’s Managed Google Play Console account that will be created automatically when uploading Private Apps through your Managed Google Play. 2. Use your own Google Play Console for advanced configuration, automation requirements, and more flexibility. You can read more about how to connect your existing Google Play Console Developer Account with Applivery [here](https://docs.applivery.com/en/device-management/android/app-management/connect-google-play-console/). We will go through the third scenario (3.1), using Google’s Managed Google Play Console account. ### Create and upload a Private App **Navigate to Policies and Apps** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io), go to any of your **Policies** 1. From the left side menu, go to **Apps** 2 and click the **\+ Add App** button 3. ![add app](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/99357efb-6f20-4548-a9c9-d0df179cd02e.png) **Access Managed Google Play and Private Apps** Then select the **Google Play** 4 tab. Once inside your Managed Google Play, go to the **Private Apps** 5 side menu option. ![private app managed google play](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/f6616a2f-af35-4c99-b7b8-7b2cc2ad8712.png) **Upload Your App** Now, click the **+** 6 circle button to start creating and uploading your first Private App. Choose a name for your App and browse your drive to select an APK file. :::warning Please note that you are going to upload a new Private App to the Google Play Console, so Google will reserve and block the package name of your App (i.e.: `com.applivery.kioskapp`) for this Organization, and you will no longer be able to use it again in any other App or organization. We highly recommend carefully choosing the package name or even adding a suffix for testing purposes. ::: ![Add app to policy](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/17c88c43-4fc1-4cdf-86a3-8fbab0a0b2b4.png) :::warning Once uploaded, **your App may take between 2 and 48 hours to become fully available** in your account. Please note that this timeframe depends on Google’s review and publishing process. ::: ### Update a Private App or make advanced edits You will probably want to update your private applications from time to time or make advanced edits to change the icon, description, language, or any other aspect of your application. These operations can be done from Applivery through the Google Play Console. #### Upload a new version of your Private Apps **Navigate to Policies and Apps** From one of your **Policies** 1, go to **Apps** 2 and click the **\+ Add App** button 3. ![add app](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/4a3a6078-c736-446e-89d3-98cc38b57ea9.png) **Access Managed Google Play and Select App** Then select the **Google Play** 4 tab. Once inside your Managed Google Play, go to the **Private Apps** 5 side menu option and select one of the **Apps** 6. ![private app management](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/9125925f-c4b5-4603-81f6-d286d076cb62.png) **Edit App and Upload New Version** Then click **Edit** 7 beside the Select button. ![edit private app](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/b351e7ca-6d22-4627-a580-60838ee7b725.png) Last, click **edit** 8 again beside the APK file name and select a file from your file system. Google Play will analyze the package and, once finished, will allow you to press the **Save** 9 button to start uploading the file. :::warning Please note that you **must increase the version number and version code of your App** before uploading a new version. In any other case, the upload will be rejected. ::: ![Save private app](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/8a9c4303-cc2c-4d24-87e7-b7c7c65ae8c9.png) #### Control App updates and update time Regularly updating applications on your organization’s Devices ensures that users benefit from the newest functionalities, enhanced security, and greater reliability. App updates are managed by Google through the Google Play Services, and Applivery can not force the update of an App (you can read more about this [here](https://developers.google.com/android/management/control-app-updates)). Many factors may affect the update timings. - **Default update behavior:** In the default setting, applications automatically update when specific conditions are fulfilled: - The Device connects to a Wi-Fi network. - The Device is in charging mode. - The Device is not in active use. - The application scheduled for an update is not open in the foreground. :::warning Google Play usually conducts checks for application updates daily. Therefore, it might take a maximum of 24 hours for an application update to enter the update queue. Once an application is queued, it will automatically update the next time the above conditions are satisfied. ::: You can override the update settings to further customize the App update behavior on the Devices you manage: - **High Priority:** This mode guarantees that your App stays up-to-date, updating it immediately upon approval by Google Play. In case your Device is offline when an update is released, it will update automatically the moment you reconnect to the internet. :::warning If the App is in use when the update is ready to install, the App will be closed during the update, which could affect your users. ::: - **Postpone mode:** Use this option if you want to pause updates for an App that prevents the App from automatically updating for an initial 90 days after it first became out of date. After this 90-day period, the latest available version of the App is automatically installed using the default update mode. After the App is updated to the latest available version, a new 90-day postponement period will begin from the next time that the developer publishes a new version of the App. :::warning Postpone mode does not prevent your users from manually updating the App. During the 90-day postponement period, your users can manually update the App by visiting the Google Play Store on their Devices. ::: **Navigate to App Settings** To modify the update mode, go to any of your **Policies** 1, look for the **Apps** 2 section from the left side menu, and then click the App you want to modify 3 the update mode. **Modify Auto Update Mode** Find the **Auto Update Mode** 4 option under the right side appearing slide and choose your preferred option. ![app auto update](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/6f48187c-e33b-4b98-8491-52de8da31681.png) #### Make advanced edits You can also fully customize the aspect of your App in your Managed Google Play from the **Make Advanced Edits** button that you will find below your Private Apps. You will be redirected to the **Google Play Console,** where you can fully customize every aspect of your App and even upload new versions in a more advanced way (or even automated) through tools such as [Fastlane](https://docs.applivery.com/en/app-distribution/ci-cd/fastlane/) or [Bitrise](https://docs.applivery.com/en/app-distribution/ci-cd/bitrise/). ![applivery-mdm-google-play-console-edits](https://www.applivery.com/wp-content/uploads/2021/12/applivery-mdm-google-play-console-edits-1024x651.png "applivery-mdm-google-play-console-edits | Applivery") --- ## System Apps Source: https://docs.applivery.com/en/device-management/android/app-management/system-apps/ Description: Manage Android System Apps in Applivery — enable or disable pre-installed Apps on managed Devices through Policies, including Kiosk Mode configurations. TL;DR: Learn how to manage Android system apps within Applivery policies for greater control over device functionality, especially in kiosk mode. Key topics: Applivery policies, Android system app management, Kiosk mode configuration, Applivery, Android, MDM With Applivery, you can also manage Android System Apps. This functionality provides greater control over any App on the Devices within your Android fleet. It is particularly useful for kiosk mode configurations, where you want users to have access only to a specific set of Apps. ### Adding System Apps to Policies **Navigate to Policies** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io), go to any of your **Policies** 1. From the left side menu, go to **Apps** 2 and click the **\+ Add App** button 3. ![add app](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/478927ae-7df5-4139-9bbe-d00b5963177b.png) **Select System App** Then select the **System App** 4 tab. You will see a drop-down menu where you can select the system App you want to manage or paste it. :::info Once you enable the **Application Reports Enabled** configuration under the **Reporting** section at the Policy level, **the full list of Apps**—including system Apps—**will be available** under **Devices > Apps**. This makes it easier to find the required package names. ::: ![system Apps](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/b0327e12-b31f-4601-9022-a47e6108c719.png) **Confirm Selection** Once you’ve selected the App, click **Select**. **Choose installation type** Finally, choose an installation type that suits your needs and add the App to the list of managed applications within your Policy. --- ## Untrusted App Installs Source: https://docs.applivery.com/en/device-management/android/app-management/untrusted-app-installs/ Description: Allow Android App installs from unknown sources by configuring Applivery Policies and Device settings — bypass default security restrictions. TL;DR: Learn how to enable app installations from unknown sources on Android devices using Applivery MDM policies and device settings. Key topics: Android security settings, Applivery MDM policies, Untrusted Apps Policy configuration, Play Store Mode configuration, Granting device permissions, Android, Google Play Store, Applivery, IT admin ![unknown sources](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/f7f20415-e62e-423e-a8f1-3959358b1680.jpeg) Android’s operating system includes a built-in security feature that blocks the installation of Apps from sources outside the Google Play Store. This means that if you’re trying to install an App downloaded from a source other than the Google Play Store, you may encounter various warning messages. By default, the permission to install Apps from sources other than the Google Play Store is disabled. This means that no device will be able to download, configure, or install an unauthorized App unless explicitly allowed through a Policy. ![blocked by it admin](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/4b385066-06c6-4166-85c4-fc640e1a6029.png) :::danger Blocked by your IT admin. If you have questions, contact your IT admin. If a user attempts to enable this setting on their Device, they will encounter a block message from their IT admin and will not be able to enable it. ::: :::info These messages can be customized using the [Short Support Message](https://docs.applivery.com/en/device-management/android/policies/personalized-support-messages/) property. ::: ### Configuring your Policy Once in the [**Applivery Dashboard**](https://dashboard.applivery.io), go to any of your **Policies** 1. From the left side menu, select **Restrictions** 2, locate the **App** section, then search for the **Advanced Security Overrides** > **Untrusted Apps Policy** 3 configuration. :::warning For Devices with Work Profiles, untrusted App installations can only be allowed within the Personal Profile. Alternatively, they can be enabled across the entire Device. ::: ![untrusted Apps](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/8a240bee-067c-4e1b-b057-b07d098a7159.png) Now, locate the **Play Store Mode** 4 configuration (not to be confused with Personal Play Store Mode) and set it to **Blacklist**. With this configuration, **all Apps are available**, and any App that should not be on the Device must be explicitly **marked as BLOCKED** in the applications Policy. ![play store mode](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/d11bf46e-7d7f-4251-8e20-6c6d347b32ca.png) ### Additional Device-side configurations As mentioned earlier, the permission to install Apps from sources other than the Google Play Store is disabled by default. Even if the installation of Apps from unknown sources is allowed through Policy, the user must still grant the necessary permissions directly on their Device. To learn how to grant these permissions, please refer to our documentation on [installing Apps from unknown sources](https://docs.applivery.com/en/app-distribution/platforms/android/unknown-sources/). --- ## Web Apps Source: https://docs.applivery.com/en/device-management/android/app-management/web-apps/ Description: Add Web Apps to Android Devices using Applivery MDM — deploy browser-based shortcuts through Policies, including Kiosk Mode configurations. TL;DR: Learn how to easily create and configure web apps on Android devices using Applivery for streamlined deployment and management, including kiosk mode setup. Key topics: Web app creation, Applivery configuration, Android device management, Kiosk mode setup, URL access control, Applivery, Android, Google Chrome, Google Play Web Apps can be easily added to the Home Screen of Android Devices, providing quick access to your favorite web pages or links. ### Add your web app to a Device policy **Navigate to Policies** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), go to any of your **Policies** 1. From the left side menu, go to **Apps** 2 and click the **\+ Add App** button 3. ![add app](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/64b3464d-a8e1-4afc-8429-bdcac4e7d6e7.png) **Add a Web App** On the left side menu of the **Google Play** tab, you will find a globe icon labeled **Web Apps** 4. Use the **+** button 5 placed at the lower right side of the screen to add your first Web App. ![web Apps](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/4200fb5c-9239-4a4e-aa02-da43ca2dfe52.png) **Configure Web App Details** - Assign a **title** to the Web App that will serve as the name displayed to Device users on the App icon. - Add the Web App **URL** to be launched when the Device user taps the App. - Choose the **display mode** that determines how the browser presents the content of the website. - Additionally, you have the option to provide an **icon** for your web App. This icon should be a rectangular JPG or PNG file with a resolution of 512×512. In case an icon is not specified, a default briefcase icon will be used. **Creation of the Web App** After incorporating all the necessary information, proceed by clicking on the **Create** button. This action will result in the addition of a new Web App. :::warning it might take a few minutes for it to become fully accessible. However, once it’s prepared, you can treat it like any other App by adding it to the list of Apps. ::: Choosing the **Force installed** install type puts the Web App icon on the Device's home screen and stops the user removing it. It is not a requirement: a Web App is distributed like any other App, so **Available** works too — the user then adds it themselves from the managed Play Store. :::info **The `FORCE_INSTALLED` requirement applies to the browser, not to the Web App.** A Web App is a shortcut that needs a browser installed to open it, so Chrome is the one that has to be force installed. The Web App itself can be available. ::: ![configure web app](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/26c9a744-07c8-4f7a-bb97-7dbae3ce04db.png) ### Web Apps in kiosk mode To display your Web App in kiosk mode, you’ll need to include a navigator. You can opt for the Google Chrome App from the **Google Play** tab and choose the **Force installed** install type. Additionally, change the install type of your Web App to **Kiosk**. ![chrome force install](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/06b83d66-5a47-4f45-a566-45d2fdaa5e37.png) Once you’ve included Google Chrome in your list of Apps, click on it to proceed. This action will show a side menu, where you will be able to configure the [**App’s Managed properties**](https://docs.applivery.com/en/device-management/android/app-management/managed-apps-properties/). To restrict access to a list of URLs, navigate to the **Block access to a list of URLs** configuration, where you’ll have two options: - Block a list of URLs by following this format: `["blocked URL1", "blocked URL2"]`. - Alternatively, block access to all URLs except the one specified in **Allow access to a list of URLs** by defining `["*"]`. If you want to enable Device users to open your Web App, it’s crucial to configure the **Allow access to a list of URLs** setting with your Web App’s specific URL. ![chrome configurations](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/d26014b2-3979-4eaf-bab9-0b832bc2a0a5.png) --- ## MDM Commands Source: https://docs.applivery.com/en/device-management/android/commands/ Description: Android MDM Commands in Applivery — execute remote commands, manage Device Policies, and control Android Devices at scale. TL;DR: Applivery's Android MDM Commands simplify device control with remote execution, policy enforcement, and real-time monitoring capabilities. Key topics: Android MDM Commands, Applivery, Remote Device Management, Device Policy Enforcement, Android, MDM Commands Android MDM Commands let you perform real-time remote actions on managed Android Devices — locking a Device, resetting a password, wiping data, rebooting, or refreshing the Device's configuration without requiring physical access. Each remote command available for Android includes when to use it and what happens on the Device when it's executed. --- ## eSIM Management Source: https://docs.applivery.com/en/device-management/android/commands/esim-management/ Description: Manage eSIM profiles on Android Devices with Applivery — provision and remove eSIMs remotely using Android 15 Commands. TL;DR: Manage Android eSIM profiles easily with Applivery and Android 15 for streamlined device deployment and enhanced security. Key topics: Android eSIM management, Applivery integration, Android 15 features, eSIM provisioning, eSIM removal, Android, Android 15, Applivery, eSIM, ICCID, EID, eUICC, Work Profile, Android Management API :::warning eSIM management uses the Android Management API (AMAPI) and requires Google Mobile Services. This feature is **not available on AOSP Devices**. ::: Android 15 streamlines the process of adding, removing, and provisioning eSIM profiles on both Company-Owned and managed BYOD Devices. This means IT admins can now take advantage of a more unified and consistent experience across Device types, helping organizations reduce operational complexity and improve deployment efficiency. Applivery integrates seamlessly with these new capabilities, allowing admins to centrally manage eSIMs across their Android fleet. By using Applivery, you can remotely: - Install and provision new eSIM profiles. - Remove or replace existing eSIMs. - Request a Device's EID to provision eSIMs on Work Profile Devices. - Wipe downloaded eSIMs as part of a Device wipe. - Automate eSIM workflows for Device onboarding or user transitions. - Maintain a consistent and secure mobile connectivity experience without the need for physical SIM handling. ### Adding an eSIM to your Device **Navigate to Devices** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), select any of your **Devices**. **Open Action Menu** Click the **Action** 1 button and choose **Add eSIM** 2 from the dropdown menu. ![action esim](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/aeacd6a9-aceb-492e-b15f-2dd4785ac613.png) A modal window will open, where you can provide: - The eSIM **activation code**. - The eSIM **activation state**. ### Removing an eSIM from your Device Similarly to adding an eSIM, click the Action button — but this time, select **Remove eSIM** 3 from the dropdown menu. **Navigate to Devices** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), select any of your **Devices**. **Open Action Menu** Click the **Action** button and choose **Remove eSIM** 3 from the dropdown menu. ![action remove esim](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/6c7fe8fe-aae6-4508-8132-214db8564bad.png) A modal window will open, where you can provide the **ICCID** of the eSIM to remove. ### Requesting the Device EID (Work Profile Devices) Before you can provision an eSIM on a **personally-owned Device with a Work Profile**, you usually need the Device's **EID** (eUICC Identifier) — the unique identifier of the Device's eSIM chip that mobile carriers use to generate an eSIM profile. The **Request info** Command retrieves this EID. Because Work Profile Devices are personally owned, the user must approve sharing this information before it can be returned. **Navigate to Devices** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), select the Work Profile **Device** you want to query. **Open Action Menu** Click the **Action** button and choose **Request info** from the dropdown menu. The Command returns one of the following statuses: - **Succeeded**: the Device info was delivered and the EID (one per eUICC chip) is returned. - **Pending user action**: the user hasn't completed the required approval yet. - **User declined**: the user declined to share the Device info. - **Unsupported**: the requested info isn't supported — for example, the Device doesn't support eSIM. :::info Requesting the EID is supported only on personally-owned Devices with a Work Profile running **Android 13 or later**. Source: [Android Management API](https://developers.google.com/android/management/reference/rest/v1/enterprises.devices/issueCommand). ::: ### Wiping downloaded eSIMs When you wipe a Device from **Settings > Danger zone**, you can enable the **Additionally wipe all downloaded eSIMs** option to remove eSIM profiles as part of the wipe. - On **Company-Owned Devices**, this removes **all** eSIMs on the Device. - On **personally-owned Work Profile Devices**, this removes **only** the managed eSIMs added through Applivery (via the Add eSIM Command). :::info Wiping downloaded eSIMs is supported on Devices running **Android 15 or later**. ::: ### Additional Policy configurations With the latest Android Management API updates, Applivery now supports a new Policy-level configuration that gives administrators greater control over eSIM management on corporate Devices. The **User-Initiated Add eSIM Settings** configuration allows IT administrators to control whether end users can add eSIM profiles on Company-Owned Android Devices. Its purpose is to enable or restrict user-initiated eSIM additions, helping maintain security and compliance by ensuring that only authorized eSIM profiles are added. :::info Ensure your Devices are running Android 15 or later to take full advantage of these eSIM management features. ::: --- ## Lost Mode Source: https://docs.applivery.com/en/device-management/android/commands/lost-mode/ Description: Remotely lock and secure lost Android Devices with Applivery's Lost Mode — protect company data and facilitate Device recovery. TL;DR: Applivery's Lost Mode enables remote locking and securing of Android devices, displaying contact information, and tracking location for device recovery. Key topics: Android Device Management, Mobile Security, Remote Device Control, Lost Mode Configuration, Applivery, Android :::warning Lost mode uses the Android Management API (AMAPI) and requires Google Mobile Services. This feature is **not available on AOSP Devices**. ::: Android now allows employers to remotely lock and secure a lost Device by enabling lost mode. This lock method also allows to optionally display of a message on the Device screen with useful contact information, allowing IT managers and departments to better protect organization and employee data while attempting to recover the Device. :::warning The target Device must be running in **Fully Managed** mode; the Work Profile is supported on Android 13 and above, and Fully Managed Devices on Android 11 and above. ::: ### Enable Lost Mode To enable lost mode on an Android Device, simply navigate to any of your **Devices** and then click the **Action** button 1. Next, choose **Start Lost mode** 2. ![action lost mode](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/de98cc21-11a7-43d5-8ba0-63db61386b7f.png) A modal view will request the following information: - **Lost message:** A message that will be displayed on the screen when attempting to unlock the Device. - **Phone number:** A phone number that can be called to return the Device. - **Email address:** An email address that can be used to arrange the return of the Device. - **Street address:** Full address where the Device can be returned. - **Organization name:** Optionally, you can also provide your company name. Fill them out and click **Enable**. :::info A Device cannot be placed into lost mode if: - The Device password has been reset by an IT admin in the last 12 hours. - The employee manually exited lost mode in the last 12 hours. - It is a Work Profile on a Company-Owned Device, and the Work Profile is paused. ::: Once enabled, a series of events will take place: #### Alert State ![lost mode](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/8922dd18-db32-4c9e-b8ab-7a8d66344514.png) The Device rings for up to 5 minutes, allowing the user to find their Device and take the Device out of lost mode. The location of the Device is not reported during this time. If the Device is accessed in the alert state, two options are presented: - **This is my device:** Allows the employee to enter their password and take the Device out of lost mode. If this occurs before the 5-minute period ends, no location data is sent from the Device to the admin. - **I found this Device:** Enables someone other than the employee to stop the Device from ringing. This moves the Device into the lost state. :::info Device location will only be sent after 5 minutes from entering the Alert state. ::: #### Lost State ![lost state](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/f8f7b8af-c672-40c9-80a8-bfc6d4ef404b.png) The Device stops ringing and sends location updates every minute. If the Device is accessed in the lost state, up to three options are shown: - **Unlock:** Allows the employee to enter their passcode and take the Device out of lost mode. - **Call owner:** Starts a phone call to the number provided in the start lost mode parameters. This option is hidden if no phone number is provided. - **Emergency:** Allows access to the emergency dialer. ### Stop Lost Mode To disable the lost mode, just click the **Action** button and then choose **Stop lost mode** 3. Confirm the action by clicking **Stop lost mode** again. ![action stop lost mode](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/dc2b1e78-d11e-4fa9-b314-d2dc91fdfe7e.png) --- ## Remote Commands Source: https://docs.applivery.com/en/device-management/android/commands/remote-commands/ Description: Remotely manage Android Devices with Applivery MDM Commands — lock, reset password, reboot, factory reset, and eSIM management. TL;DR: Applivery MDM enables IT admins to remotely manage Android devices with commands like lock, reset password, reboot, and eSIM management, enhancing security and control. Key topics: Android Device Management, Remote Commands, Applivery MDM, Android Management API, Applivery, Android Devices, Google Applivery MDM leverages the [Android Management API](https://developers.google.com/android/management/introduction) (AMAPI) to provide robust remote Command capabilities for managing Android Devices. By relying on AMAPI’s extensive features, Applivery ensures seamless execution of remote actions, enabling IT administrators to maintain control and enforce security Policies effectively across their Device fleet. This integration simplifies Device management by allowing remote intervention without the need for physical access. ### Lock **Available for Fully Managed Devices**, this Command forces an Android Device to lock its screen immediately by simulating the expiration of the screen timeout. It’s useful for ensuring Device security in situations that require an instant lock. **Navigate to the Device** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), navigate to any of your **Devices** and click the **Action** button 1. **Select Lock** From the dropdown menu, select **Lock** 2. ![action lock](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/b39b8524-f8f6-4616-9606-b2f440c71793.png) A modal window will appear asking you to enter the **Duration** in seconds. This sets how long the Command will remain active. It will expire if the Device doesn’t execute the Command within this time. There is no maximum limit for the duration. ### Reset password **Available for Fully Managed Devices**. Resetting the password is useful when a user has forgotten it, when the Device changes users, if there are suspicions of unauthorized access, or when new security Policies are applied. It is also recommended for lost or stolen Devices to prevent unauthorized access and protect sensitive information. **Navigate to the Device and click the Action button** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), navigate to any of your **Devices** and c**l**ick the **Action** button 1. **Select Reset password** From the dropdown menu, select **Reset password** 2. ![action reset password](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/71e3ab2d-7daa-4a95-b385-ab749e009df1.png) A modal window will prompt you to specify the **Duration** parameter in seconds. This defines how long the Command remains valid; if the Device does not execute the Command within this time, it will expire. There is no maximum duration limit. You can configure additional settings to enhance security and control following a password reset: - **Don’t allow other admins to change the password again until the user has entered it:** This ensures that no other admin can modify the password once it has been reset, forcing the user to enter the new password before any further changes are allowed. - **Don’t ask for user credentials on Device boot**: Allows the Device to boot without immediately prompting the user to enter the new password after a restart. - **Lock the Device after password reset**: Automatically locks the Device following the password reset, increasing security until the user enters the new password. - **Set new password**: Allows you to directly specify the new password to be applied to the Device. For Android 14 Devices, the new password must be at least 6 characters long if it is numeric; otherwise, the Command will fail with an `Invalid value` error. :::info If you do not enable the **Set new password** option, the Command will, by default, **disable the Device password**. ::: :::warning **On a Device already locked with an unknown password, this Command cannot work.** Since Android 8, the old reset method throws a security exception, so the DPC has to use a reset token that was both **provisioned beforehand** and **activated** — activation meaning the user unlocked the Device at least once after the token was provisioned. Tokens that were never activated live only in memory and are lost on reboot. It is a platform limitation that affects every MDM equally, not something specific to Applivery. In those cases, check whether the lock came from Google's Find My Device, which can set a new PIN remotely. ::: #### Troubleshooting: Reset password fails instantly If you send a Reset password command and it fails almost immediately — even though the device appears online and connected to Wi-Fi — the device is likely in a **Before First Unlock (BFU)** state. **What is the BFU state?** When `encryptionPolicy` is set to `ENABLED_WITH_PASSWORD` in your policy, the device requires the PIN to be entered at boot before the encrypted storage can be decrypted. If the device was restarted and the user cannot enter their PIN, it gets stuck in BFU. In BFU state, the entire Android user space is frozen — including Android Device Policy, the component responsible for communicating with Applivery. The device can see the Wi-Fi network at the OS level (which is why it appears connected in the Dashboard), but the MDM layer is completely dormant: no process is running that can receive or execute commands from Applivery. This is why the Reset password command fails instantly — the device never receives it. **Resolution** There is no remote solution in this scenario. Physical access to the device is required: - **Physical PIN entry**: if there is any chance the user remembers their PIN, this is the simplest path forward. - **Factory reset from recovery mode**: hold the hardware button combination at boot to access recovery mode and perform a factory reset. The device will lose all local data but will become manageable again. **Prevention** To avoid this scenario, set `encryptionPolicy` to `ENABLED_WITHOUT_PASSWORD` in your Android policy. This still enforces full-disk encryption on the device, but does not require the PIN at boot — meaning Android Device Policy starts normally after a reboot, and remote commands like Reset password will work as expected. :::info For a full explanation of all available encryption values and how to choose between them, see [Encryption Policy](https://docs.applivery.com/en/device-management/android/policies/encryption-policy/). ::: ### Reboot **Available for Fully Managed Devices**. Sending a restart Command is useful in several key situations. It helps resolve performance issues by freeing up RAM, applies system updates that require a reboot to take effect, and fixes minor errors such as unresponsive Apps or driver conflicts. It’s also recommended when a Device has been running for extended periods without restarting, which can impact stability. Additionally, when new security settings or Policies are applied through Applivery, a restart may be necessary for these changes to take effect. **Navigate to the Device** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), navigate to any of your **Devices** and c**l**ick the **Action** button 1. **Select Reboot** From the dropdown menu, select **Reboot** 2. ![action reboot](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/4502dfc1-300b-4211-af3d-56930cdd539f.png) A modal window will prompt you to specify the **Duration** parameter in seconds. This defines how long the Command remains valid; if the Device does not execute the Command within this time, it will expire. There is no maximum duration limit. ### eSim These Commands provide the ability to remotely add or remove eSIM profiles on **compatible Android Devices** (Android 15 and above), removing the reliance on physical SIM cards. This simplifies Device setup and maintenance, allowing for faster deployment and better control over mobile network access, all managed remotely from a centralized Dashboard. **Navigate to the Device** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), navigate to any of your **Devices** and c**l**ick the **Action** button 1. **Select Add eSim or Remove eSim** From the dropdown menu, select either **Add eSim** 2 or **Remove eSim** 3. ![actions esim](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/7b5cbbda-cb98-4fb2-ab7e-bd7340457aab.png) #### Add eSim When you select the Add eSIM Command, a modal window will prompt you to specify additional configurations, such as the **eSIM activation code** and **activation state**, as well as the **Duration** parameter described in previous commands. #### Remove eSim When you select the Remove eSIM command, a modal window will prompt you to specify additional configurations, such as the **ICCID of the eSIM** to remove, as well as the **Duration** parameter described in previous commands. #### Request info (Device EID) **Available for personally-owned Devices with a Work Profile** (Android 13 and above). This Command retrieves the Device's **EID** (eUICC Identifier) — the unique identifier of the eSIM chip that mobile carriers need to provision an eSIM profile. Because these Devices are personally owned, the user must approve sharing the information before it can be returned. Select **Request info** from the **Action** menu. The Command reports one of these statuses: - **Succeeded**: the Device info was delivered and the EID (one per eUICC chip) is returned. - **Pending user action**: the user hasn't completed the required approval yet. - **User declined**: the user declined to share the Device info. - **Unsupported**: the requested info isn't supported — for example, the Device doesn't support eSIM. :::info All of these Commands above can also be executed from the Device’s **Commands** tab. ::: ### Disable **Available for all management modes**, this command allows you to remotely disable an Android Device by locking it down and disabling all Apps and features. While disabled, the Device becomes inaccessible for regular use, helping to prevent unauthorized access and enhance security in cases of loss, theft, or Policy enforcement. Additionally, it can be used to restrict device usage outside of scheduled working hours. The Device can be re-enabled later to restore full functionality. **Navigate to the Device** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), navigate to any of your **Devices** and c**l**ick the **Action** button 1. **Select Disable** From the dropdown menu, select **Disable** 2. ![action disable](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/02eb930e-c7a7-4e3f-8a29-074233c47d26.png) ### Relinquish ownership **Available for COPE (Company-Owned, Personally Enabled) Devices**, this command allows you to remotely remove the Work Profile and all corporate management Policies from a Device. It effectively returns the Device to a personal-use state while preserving any data, Apps, and settings associated with the user’s Personal Profile(s). This action is particularly useful in scenarios such as offboarding employees, transferring ownership of a Device, or repurposing Devices for non-corporate use. It ensures that corporate data is securely wiped, without impacting the user’s personal content. Once executed, the Device will no longer be managed by Applivery and will behave as a standard, unmanaged Android Device. **Navigate to the Commands tab** Go to the **Commands** 1 tab of any of your Android COPE Devices. **Select Relinquish ownership** Select **Relinquish ownership** 2. ![action relinquish ownership](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/947ba4e2-82bb-4ec0-bb3b-b2f468deec22.png) A modal window will prompt you to specify the **Duration** parameter in seconds. This defines how long the Command remains valid; if the Device does not execute the Command within this time, it will expire. There is no maximum duration limit. :::info All of the Commands mentioned above can also be executed from the **Danger zone** section within the **Settings** tab, depending on the Device’s management mode. ::: ### AOSP Devices Support On AOSP Devices, remote commands are dispatched through **Pushy** (not AMAPI) and executed by the Applivery DPC against the native Android APIs. Commands are acknowledged on receipt and again on completion, so the Dashboard always shows the full lifecycle. The following commands are supported on AOSP:

Command

Effect

Lock device

Locks the device immediately.

Reset password

Resets the lock-screen password. Sub-options: Don’t ask for credentials on boot, Lock after reset, Set new password.

Reboot

Reboots the device.

Clear app data

Clears data and cache for one or more managed packages.

Disenroll

Removes the Applivery DPC as Device Owner and clears stored state from the device.

Commands are accessible from the device detail page under the **Action** menu or the **Commands** tab. :::warning eSIM management, Lost mode, and Relinquish ownership are AMAPI-based commands and are **not available on AOSP Devices**. ::: --- ## COPE Permission Limits Source: https://docs.applivery.com/en/device-management/android/cope-permission-limits/ Description: Permission limitations on Android COPE (Corporate-Owned, Personally Enabled) Devices — Work Profile restrictions and user privacy explained. TL;DR: Android COPE devices have permission limitations where corporate policies mainly affect the work profile, leaving the personal profile largely under user control. Key topics: COPE device management, Android permissions, Work profile limitations, EMM policies, Android, COPE, EMM, Applivery, Bluetooth In modern Enterprise Mobility Management (EMM), the COPE model (Corporate-Owned, Personally Enabled) has become a preferred option for organizations that want full ownership of the Device while still allowing personal use. This mixed-use scenario provides flexibility for employees but also introduces technical limitations that directly affect the way managed properties and App-level permissions behave on Android COPE Devices. Because COPE Enrollment separates the Device into two distinct spaces—a Fully Managed Work Profile and a Personal Profile outside corporate control—certain Policies, restrictions, and permission grants simply **cannot be applied at the Device level**. This differs significantly from Fully Managed, dedicated, or work-managed deployments, where the enterprise has broader administrative control. ### Key limitations #### Permissions apply only to the Work Profile Any permission granted, denied, or required through managed properties affects Apps inside the Work Profile only. Administrators cannot enforce permissions on Apps in the Personal Profile. #### Sensitive permissions cannot be pre-granted by IT Even within the Work Profile, permissions such as camera, location, or microphone cannot always be auto-granted. The user must manually approve them. #### Factory reset cannot be blocked Users retain the ability to reset the entire device to factory settings. In COPE mode, EMM solutions—including Applivery—cannot disable or restrict this option. #### Location control is limited Administrators can request or restrict location access **only within the Work Profile**. They cannot force Device-wide location tracking or enforce continuous location access. See [Location Management on Android Devices](https://docs.applivery.com/en/device-management/android/policies/location-management/) for how location control differs across management modes. #### Phone and SMS permissions are not manageable Calls and SMS belong to the Personal Profile by design; therefore, related permissions cannot be restricted, granted, or controlled from the Work Profile. #### Global Device-level restrictions cannot be enforced Policies related to screen lock requirements, disabling the camera, controlling Bluetooth, or modifying system network settings apply only to the Work Profile and do not affect personal usage. #### Sensitive Personal-Profile permissions cannot be controlled Access to contacts, call logs, SMS, shared storage, and other privacy-sensitive Resources cannot be automatically granted or denied by the EMM—either in the Personal Profile or, in some cases, even within the Work Profile. ### Summary table | Permission | Can it be pre-granted or blocked? | | --- | --- | | `ACCESS_FINE_LOCATION` / `ACCESS_COARSE_LOCATION` | ❌ | | `CAMERA` | ❌ | | `RECORD_AUDIO` | ❌ | | `READ_EXTERNAL_STORAGE` / `WRITE_EXTERNAL_STORAGE` | ❌ | | `READ_CONTACTS` | ❌ | | `READ_CALL_LOG` / `WRITE_CALL_LOG` / `PROCESS_OUTGOING_CALLS` | ❌ | | `READ_SMS` / `SEND_SMS` / `RECEIVE_SMS / READ_MMS` | ❌ | | `READ_CALENDAR` / `WRITE_CALENDAR` | ❌ | | `BODY_SENSORS` / `ACTIVITY_RECOGNITION` | ❌ | | Block Factory Reset | ❌ | These limitations arise from Android’s privacy-by-design approach for COPE Enrollment. The OS intentionally ensures that personal data, activity, and system-level capabilities remain under user control, preventing administrators from silently configuring or restricting certain behaviors—even on company-owned hardware. On COPE Devices managed through Applivery, Policies and permissions apply fully and exclusively to the Work Profile, while the Personal Profile remains protected from administrative control. This also means that certain actions—such as blocking factory resets, enforcing Device-wide restrictions, or automatically granting sensitive permissions through managed properties—are not technically possible. Understanding these constraints is essential when designing corporate Policies, ensuring that management strategies are aligned with COPE’s actual capabilities and Android’s built-in privacy protections. --- ## Android Enrollment Source: https://docs.applivery.com/en/device-management/android/enrollment/ Description: Android Device Enrollment in Applivery — manual, Smart Enrollment, Zero-Touch, and Samsung Knox Mobile Enrollment for fully managed Devices. TL;DR: Learn how to easily enroll your Android devices in Applivery for secure mobile device management. Key topics: Android device enrollment, Applivery MDM, Mobile device management, Android, Applivery, MDM Enrolling an Android Device in Applivery registers it with the MDM platform and applies your organization's Policies, Apps, and configuration automatically. Applivery supports multiple Android Enterprise enrollment methods to cover both corporate-owned and BYOD scenarios. Choose the right enrollment method for your deployment: QR code, Zero-touch, Smart Enrollment, or COPE. --- ## Manual Enrollment Source: https://docs.applivery.com/en/device-management/android/enrollment/manual-enrollment/ Description: Manually enroll Android Devices in Applivery MDM by scanning a QR code — ideal for small fleets or one-off Device setup without zero-touch provisioning. TL;DR: Learn how to enroll Android devices into Applivery MDM using manual, smart, or zero-touch enrollment methods and understand the different management options available. Key topics: Android enrollment methods, Android Enterprise management options, Manual enrollment process, Work profile setup, Fully managed device setup, Android Enterprise, Applivery, Google Workspace, Google Admin Console, Android Device Policy App Once you have your [Android Enterprise](https://docs.applivery.com/en/device-management/android/get-started/) configured and you have [setup your first Android Policy](https://docs.applivery.com/en/device-management/general-settings/create-policies/), you can start enrolling your Android Devices. Let’s take a look at it. ### Enrollment options Applivery supports multiple ways to enroll your Android Devices: - Manual enrollment through a QR code or alphanumeric code. - Automatic enrollments through [Smart Enrollments](https://docs.applivery.com/en/device-management/android/enrollment/smart-enrollment/). - [Android Zero-touch](https://docs.applivery.com/en/device-management/android/enrollment/zero-touch-enrollment/), designed for automated enrollment. ### Management options As part of Android Enterprise, there are several ways to manage your Devices, depending on the use case: - **Company-Owned Devices:** Also known as **Fully Managed,** this is the operating mode that provides full control over the Device. It requires a factory reset (wiping) of the Device to start a clean enrollment. - **Company-Owner, Personally-Enabled**: They are Company-Owned Devices that employees can use for both personal and work purposes. - **Dedicated Devices**: Company-Owned Devices assigned to a specific employee or task, used solely for work purposes, and Fully Managed by the organization. - **Bring Your Own Device (BYOD):** Also known as **Work Profile**, it refers to personal Devices that employees use for work. The corporate space will be fully encrypted, and you will have full control over it. Devices can be enrolled and unenrolled in/from the Work Profile without requiring a factory reset ### Manual enrollment (code or QR) :::warning If [Google Workspace](https://docs.applivery.com/en/device-management/integrations/sso/google-workspace/) is configured as your IDP and you experience any issues during the enrollment process, you will need to review your configuration in the [Google Admin Console](https://admin.google.com/). ::: Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), navigate to **Devices** and click **\+ Enroll device**. Fill out the form as follows: **Configure Enrollment Settings** - **Platform:** Make sure to choose **Android** under Platform. - **Management mode:** Choose between a Fully Managed and Work Profile, as described above. - **Device Employee:** User who owns the Device. You can create a new employee by introducing the email address. - **Policy:** Choose the Policy to apply to the Device. You can do so under Policies if you haven’t created it yet. Alternatively, you can create a new Policy here and configure it later. - **Tags**: Define tags to organize, group, and filter Devices efficiently. - **Display name (optional):** A friendly name to easily identify the Device among the others. - **Expire after:** The expiration time of the enrollment token that will be generated. - **Send instructions email to employee (optional):** Choose whether you want to send a notification to the user, including the enrollment instructions that will vary depending on the enrollment mode. ![android manual enrollment](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/e19274d1-2deb-4547-8cf4-6e6c68eb5667.png) :::info You can also create [bulk enrollments](https://docs.applivery.com/en/device-management/general-settings/bulk-enrollment/). To do this, simply open the dropdown menu next to **\+ Enroll device** and select **\+ Enroll multiple devices**. An enrollment will be created for each selected Device Employee. If a Device Employee’s email is not found, a new Device Employee will be automatically created. ::: **Enroll the Device** Once the enrollment is created, it will be added to the list of Devices. Click on it to display the enrollment details and instructions. ![android manual enrollment instructions](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/190b3f10-aeeb-4a78-bbc4-9e161064ec48.png) :::warning The instructions will vary based on the enrollment mode and the type of Device. However, in most cases, you will need to use a QR code to enroll the Device. In summary, enrollment requires the following steps. ::: **Fully Managed** 1. Turn on your wiped or factory-reset Device. 1. **Option 1**: On the Welcome screen, select your language. 2. **Option 2**: Tap 6 times over the **Welcome** message until accessing the QR Reader option. 2. Connect to your **Wi-Fi** and then choose **NEXT**. 3. Accept the **Google Terms and Conditions** and then choose **NEXT**. 4. On the Google sign-in screen, enter **afw#setup** instead of a Gmail account and then choose **NEXT**. 5. On the Enroll this Device screen, allow your Device to **scan a QR code or choose to enter the enrollment code manually**. 6. Lastly, please follow all the steps on your Device screen carefully to complete the enrollment. **Work Profile** 1. Go to **Settings > Google > Set up Work Profile**. Alternatively, you can open a provided URL or scan a QR code. 2. Wait for the opening of the **Android Device Policy App**. In case it’s not yet installed on your Device, wait for the download/install of the Android Device Policy App on your Device. It will be opened automatically once installed. 3. In some Android versions, you will be prompted to introduce an enrollment code or **scan a QR code** to complete the Work Profile setup. 4. Lastly, please follow all the steps on your Device screen carefully to complete the enrollment. ![manual enrollment instructions for Work Profile](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/948e0225-e309-49c4-9189-3f90096c3910.png) --- ## Samsung Knox Mobile Enrollment (KME) Source: https://docs.applivery.com/en/device-management/android/enrollment/samsung-knox-mobile-enrollment/ Description: Integrate Samsung Knox Mobile Enrollment (KME) with Applivery for automated Device provisioning and Enrollment at scale. TL;DR: Automate Samsung device enrollment using KME and Applivery Smart Enrollments by configuring a KME profile with a simplified JSON configuration from Applivery. Key topics: Mobile Device Management, Android Enrollment, Samsung Knox Mobile Enrollment, Samsung, Applivery, Android [Samsung Knox Mobile Enrollment](https://www.samsungknox.com/en/solutions/it-solutions/knox-mobile-enrollment) (KME) is a powerful onboarding framework that allows organizations to provision Samsung Devices automatically and at scale. It ensures that every corporate Device—new or freshly reset—configures itself with the correct management settings as soon as it connects to the internet. When combined with [Applivery Smart Enrollments](https://docs.applivery.com/en/device-management/android/enrollment/smart-enrollment/), KME enables a fully automated, secure, and hands-off provisioning flow, making Device deployment faster, more consistent, and error-free. **Obtain the JSON configuration** The first step is to collect the JSON configuration needed for Samsung KME. This JSON contains the enrollment parameters required for Applivery to configure the Device automatically during provisioning. Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), go to **Automation** 1, select **Smart Enrollments** 2, and choose **Android** as the platform from the left-hand menu. ![create android Smart Enrollment](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/b48047d9-9cc3-408f-b326-5c419862a01f.png) :::info Samsung Knox Mobile Enrollment supports **Device Owner**, **Dedicated Device**, and **COPE** enrollment modes. ::: :::info You can learn more about Android Smart Enrollments by following [this link](https://docs.applivery.com/en/device-management/android/enrollment/smart-enrollment/). ::: On the Smart Enrollment you want to use, click the **three-dots menu** 3 on the right side and select **Zero-touch**. Next, select the **Copy JSON** 4 button to copy the JSON block. ![Zero-touch json](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/1fa5585e-0120-4b79-9e21-0ba1fba67161.png) ##### Validate the JSON configuration Once you’ve copied the JSON code, you must validate its structure and prepare it for KME use. Open a JSON validator, such as [jsonlint](https://jsonlint.com/), and paste the copied JSON into it. Validate the structure and ensure there are no syntax errors. If errors appear, revise the JSON for missing commas, quotation marks, or brackets. ##### Remove non-required JSON sections Samsung KME requires a simplified version of the JSON. Some fields generated by Applivery Smart Enrollment must be removed before uploading. - Review the validated JSON code. - Identify elements not required for the KME integration. - Remove unnecessary sections carefully without altering the structure. The resulting JSON should look similar to the provided example: ```json { "com.google.android.apps.work.clouddpc.EXTRA_ENROLLMENT_TOKEN": "YOUR_TOKEN_HERE" } ``` **Configure KME Portal** ##### Create a new KME profile You will now create a [Samsung KME profile](https://signin.samsungknox.com/auth?redirectUrl=https://signin.samsungknox.com/) that includes the Applivery configuration. First, navigate to the **Profiles** 5 section, then click the **Create profile** 6 in the upper-right corner. ![kme-create-profile | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/afa3d203-583f-4f36-9ec4-49fc23d18910.png "kme-create-profile | Applivery") Name the profile according to the deployment type (DO, COPE, Dedicated, etc.) and select the **EMM** checkbox and optionally **Knox Service Plugin**. Then, click **Next**. ![kme-profile | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/32d9a6ef-8b94-4011-a49c-b36638b3665e.png "kme-profile | Applivery") Fill in the **Company name**, **Support email**, and **Support phone number** fields. Then, under **EMM Information**, from the dropdown select **Other**. For **Link to agent APK**, use `https://play.google.com/managed/downloadManagingApp?identifier=setup`. Then click **Next**. ![kme-emm-info | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/9a89e837-07df-4bed-aae4-fe6d80c1e8bd.png "kme-emm-info | Applivery") On the next page, locate the **DPC Extras** section and paste the cleaned JSON directly into the field. Complete any additional settings your organization requires, including: - **System Apps** for corporate profile. - **Enrollment screens** configuration. - **Legal agreement** (optional). Once completed, click **Next**. ![dpc-extras | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/e156282b-affb-4d6f-aa07-6de6c6fdc997.png "dpc-extras | Applivery") ##### Assign the profile to Devices Verify that all settings—including the Applivery JSON—have been correctly added, then click **Create and assign** to save the profile. Finally, assign your new profile to the Samsung Devices you want to manage. Select the Devices you want to provision, choose the profile you created and assign it, and confirm the assignment to push the configuration. ![assign-device | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/024de2e2-37b7-46d1-8eb1-3a5b267686df.png "assign-device | Applivery") Once assigned, any Device that is **factory-reset** or **turned on for the first time** will automatically trigger Samsung KME as soon as it connects to the internet, starting a fully automated Applivery enrollment. Your KME provisioning workflow is now ready for deployment! --- ## Smart Enrollments Source: https://docs.applivery.com/en/device-management/android/enrollment/smart-enrollment/ Description: Automate Android Device Enrollment with Smart Enrollments. Define rules, assign Policies based on user/device data (IMEI, serial number, SSO). TL;DR: Android Smart Enrollments automate device enrollment and policy assignment based on predefined rules and conditions, enabling zero-touch experiences. Key topics: Smart enrollment configuration, Applying conditions and rules, Deploying smart enrollments, Auxiliary fields, Android, MDM, SSO, IMEI, Serial Number, Applivery If you have ever dreamed of automating 100% of the Device Enrollment process and conditional Policy assignment based on user data (name, email, User Groups) or the Device data (IMEI, Serial Number, etc), **Smart Enrollments** are the tool you were looking for. ### Introduction Smart Enrollments are the most efficient way to manage Device Enrollments in an unattended manner since they will allow you to **define a set of rules and conditions that must be met for a Device to be enrolled** and, in addition, will allow you to **conditionally assign Policies** based on these rule sets. Smart Enrollments are useful for: - Limit Device enrollment: - Based on user authentication through [SSO integrations](https://docs.applivery.com/en/platform/authentication/sso/) (User Groups or email patterns). - Based on Device information (IMEI, Serial Number). - Conditionally assign different Policies based on rules. - Automate Android Enrollments to enable unattended Zero-touch experiences. ### Smart Enrollment configuration Let’s get started configuring your first Smart Enrollment. First, go to **Automation** 1, select **Smart Enrollments** 2, and choose **Android** 3 as the platform from the left-hand menu. Then click the **\+ Create Smart Enrollment** 4 button. ![create android Smart Enrollment](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/53b49e4c-29d7-4f10-8fac-4b191c42f881.png) **Configure Smart Enrollment** 1. **Name:** Choose a friendly name for your new Smart Enrollment. 2. **Description:** Choose a friendly description for your new Smart Enrollment. 3. **Management mode**: Specify the Device Management method to be applied during this Smart Enrollment process. 4. **Login providers**: The SSO providers configured at the Workspace level will be displayed. However, you can also configure the specific integration at the Smart Enrollment level by clicking **Override**. 5. **Policy:** Choose the Policy that will be applied to the Device from the Policies library. If you still don’t have any pre-defined Policies, just type a name, and a new empty Policy will be created. 6. **Target segment**: Choose the [Segment](https://docs.applivery.com/en/device-management/general-settings/segments/) that enrolled Devices will be assigned to. 7. **Tags**: Used for filtering and grouping. :::info When the login provider is configured as **Anonymous**, you can enable the **Auto-continue** option, which allows Devices to continue enrollment automatically when no user interaction is required. ::: ![Smart Enrollment form](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/033d2a9c-7f45-4f77-bf7a-23a81c92386b.png) **Configure Auxiliary Fields** 8. **Auxiliary fields**: By filling out this form, you will be able to configure device tags during enrollment. ![auxiliary fields](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/43dd8611-201d-483b-8028-74ce07e89da8.png) **Configure Display Name Pattern** 9. **Display name pattern**: Assign a display name by combining Device properties. ![interpolation tags](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/aad8c3c4-1394-4e55-8a1d-0346d312d058.png) If you click **Save** at this point, you will have finished setting up your basic Smart Enrollment and will be able to start enrolling Devices. **Auxiliary fields** By using Auxiliary fields, you can define a **flexible enrollment structure** that adapts to the organizational characteristics of your company. This allows users to enroll their Devices **according to specific requirements**, while enabling administrators to apply different configurations based on these selections. These Auxiliary fields can be used to generate Device tags during enrollment, which function as conditional parameters. You can create as many fields as needed and later associate them with the corresponding Policies for each scenario. After continuing, the user will be presented with the dropdown menus defined in the Auxiliary fields, based on the organization’s requirements. Once the required fields are selected, the user will authenticate using the method enabled by the organization, and the appropriate Policies will be applied according to the assigned tags. The Device will then complete the enrollment and apply the configurations in the background. **Applying conditions and rules** Now that you have your basic Smart Enrollment configured, you can add **Conditions** 5 and **Rules** 6 that will make it smarter. ![conditions and rules](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/8eb5b076-a8b7-4ecd-bb1e-bbf9fdf504c0.png) Use the **Add condition** option to enable enrollment limits based on user information (such as email patterns or groups) and Device information (IMEI, Serial number, and auxiliary fields). You can use conditional operators to make it as complex as you need. ![conditions](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/2755c5b4-6889-4a69-8fbe-d66f8e0fbbf7.png) You can also use the **Add additional rule** option to create groups of conditions, each of them with a target Policy. As you will see, each group of conditions will also have as many **Conditions** as you need. ![rules](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ee6c2fae-6b0d-405b-bb53-e3812bd75497.png) Once done, click **Save**. **Deploying Smart Enrollments** To complete the process, you will need to assign Smart Enrollments to your Android Devices. Simply click on the vertical dots next to any of your Smart Enrollments and select **View instructions** 7. This action will grant you access to the instructions side panel, where you can easily follow the provided steps. ![view instructions](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ad76e252-677a-4fac-b20c-1a3b734f5827.png) ### AOSP Devices Support Smart Enrollments are fully supported on AOSP Devices, and you configure them exactly the same way — same fields, same Auxiliary fields, same Conditions and Rules, and the same deployment steps described above. There is no separate setup and nothing extra to enable. For the full list of what Applivery manages on non-GMS hardware, see [Android Open Source Project (AOSP)](https://docs.applivery.com/en/device-management/android/aosp/). --- ## Zero-Touch Enrollment Source: https://docs.applivery.com/en/device-management/android/enrollment/zero-touch-enrollment/ Description: Set up Android Zero-Touch Enrollment (ZTP) in Applivery for bulk, automated provisioning of organization-owned Android Devices. TL;DR: Android Zero-Touch Enrollment streamlines the deployment of Android devices by automating configuration and enrollment. Key topics: Android Zero-Touch Enrollment setup, Integrating Applivery with Zero-Touch, Configuring devices in the Zero-Touch portal, Obtaining the JSON for DPC extras, Assigning configurations to devices, Google, Android, Applivery, Android Device Policy :::warning Zero-touch Enrollment is a Google service that requires Google Mobile Services (GMS) and is **not available on AOSP Devices**. To enroll AOSP Devices, use QR code provisioning. See [AOSP Android Management](https://docs.applivery.com/en/device-management/android/aosp/) for details. ::: Android Zero-touch Enrollment or Android Zero-touch Provisioning (ZTP) is a Device Enrollment method provided by Google that streamlines the Enrollment and easy deployment of organization-owned Android Devices in bulk. ### Advantages of Zero-touch - One-time setup. - Aids large-scale Enterprise Device rollout. - Allows resellers to add Devices to the Portal, easing the Enrollment process. - Admins can set up the Device with the necessary Apps and profiles, and it gets applied automatically on Device activation. ### Pre-requisites for Zero-touch - Android Zero-touch Enrollment is supported for Devices running Android 9.0 or later, purchased from [specified reseller partners](https://androidenterprisepartners.withgoogle.com/resellers/). - You need a Zero-touch Portal account, which can be obtained by contacting your reseller. :::warning A Google account (associated with your corporate e-mail) is required to set up the Android Zero-touch Portal. ::: #### Integrate Applivery with Zero-touch **Link Zero-touch to Applivery** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io), head to the **Settings** section and select the **Android** **Zero-touch** 2 from the left-hand menu. You will need to link your Zero-touch to Applivery and follow the on-screen steps. ![Zero-touch-portal-1](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/f2343bf2-dafb-415c-a717-a78c1d62a37f.png "Zero-touch-portal-1 | Applivery") **View Devices in the Zero-touch portal** Once the integration has been successfully completed, you just need to click on **View Devices in the Zero-touch portal** 2. ![view Devices in the Zero-touch portal](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/190464dd-d5f5-4e27-ab89-77940eec3460.png) **Add a new configuration** A new window will open in your browser, where you will find the **Configurations** 3 section. You can add a new configuration by simply clicking the **\+ Add configuration** 4 button placed on the right side of the screen. ![Zero-touch-portal-3](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/fd8734cc-3979-4fa2-a4d6-d364d22a6351.png "Zero-touch-portal-3 | Applivery") **Configure the DPC** :::warning At this stage, you need to provide a name for the configuration and fill in the required fields. Pay close attention when selecting **Android Device Policy** in the corresponding DPC field. Additionally, you can learn how to obtain the JSON for the **DPC extras** field [here](#obtain-the-json-for-the-dcp-extras-field). ::: ![Zero-touch-portal-4](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/c76d4f75-5b3b-435a-bd17-35c4512a2c6b.png "Zero-touch-portal-4 | Applivery") **Save the configuration** The last step in the Portal is to associate the created configuration with the Devices. To do that, just select the configuration that is to be automatically applied to the added Devices and click the **Save** button. ![Zero-touch-portal-5](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/eed7e7ec-dbf2-4256-a038-e1bac9175205.png "Zero-touch-portal-5 | Applivery") #### Adding the configuration to your Devices Once the configuration is created, navigate to the **Devices** section from the left-side menu. Here, you’ll find a list of Devices currently active with Zero-touch that need to be assigned a configuration. This ensures that automatic enrollment points to the correct configuration, allowing the Device to enroll properly. ![Zero-touch-Devices-1](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/35515e1c-c201-4c3a-8f7e-115c0047b12a.png "Zero-touch-devices-1 | Applivery") To assign a configuration, select **Edit** on the desired Device. Then, choose the appropriate configuration from the drop-down menu. ![Zero-touch-Devices-2](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/cd41d974-c7fb-492c-946d-cdd2147adb6d.png "Zero-touch-devices-2 | Applivery") From this point on, the Device will automatically enroll in Applivery after a factory reset, requiring no additional action. #### Obtain the JSON for the DCP extras field **Navigate to Android Smart Enrollments** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io), navigate to **Automation** 4, select **Smart Enrollments** 5, and choose **Android** 6 as the platform from the left-hand menu. **Select Zero-touch** Then, click on the **vertical dots** 7 located at the end of the Smart Enrollment you wish to configure within the Zero-touch Portal and select **Zero-touch** 8. ![Zero-touch](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/c54a4e42-c82b-4b77-9c62-41c6b94b65ef.png) **Copy the JSON** A modal view will appear, allowing you to input additional configurations and **Copy** 9 the necessary **JSON** for the DPC extras. ![copy json](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/4a6deb1e-84a1-403e-94b4-1142c7a90458.png) --- ## Feature List Source: https://docs.applivery.com/en/device-management/android/feature-list/ Description: Full list of Android Enterprise features supported by Applivery — Device Management, security, App control, and Enrollment options. TL;DR: Applivery supports all Android Enterprise features, providing comprehensive device management, security, and app control for Android devices. Key topics: Device Provisioning, Device Security, App Management, Device Management, Android Enterprise, Applivery, Google Play, Google, NFC, MDM, APK, AAB Applivery supports the complete set of Android Enterprise features. Since Applivery is fully compliant with all Android Enterprise Management modes, all Android Enterprise features are available by default. However, you can find the full Android Enterprise feature list [here](https://developers.google.com/android/work/requirements). ### Minimum Android versions The Applivery agent supports **Android 7.0 (API 24) and above**. Most features work from there, but a few need a newer release — worth checking before you size a deployment on older hardware.

Feature

Minimum version

Notes

General Device Management

Android 7.0 (API 24)

The agent baseline.

Advanced Launcher

Android 8

Applivery's own multi-app launcher.

Kiosk customization settings — System Navigation, Status Bar, Device Settings, Power Button Actions, System Error Warnings

Android 9

See Kiosk Mode.

Basic Launcher

—

Not available on AOSP Devices. It depends on Android's native Device Policy Controller.

:::warning **A feature below its minimum version is discarded silently.** The Device reports `nonComplianceReason: API_LEVEL` in its compliance checks, but nothing fails and nothing restarts — the setting simply has no effect. ::: ### Device Provisioning - **Fully Managed mode provisioning:** End users can provision a Fully Managed or dedicated Device by entering `afw#setup` in the Device’s setup wizard. - **NFC Device provisioning:** IT admins can “bump” new or factory-reset Devices with the Applivery NFC provisioning app to provision a Device (WIP). - **QR code Device provisioning:** IT admins can use the new or factory-reset Device to scan a QR code generated by the Applivery Dashboard to provision the Device. - **Smart Enrollments**: Automate Device Enrollment and Policy assignment based on predefined rules and conditions, enabling Zero-touch experiences. - **Work Profile provisioning:** End users can provision a Work Profile after downloading the Android Device Policy from Google Play. - **Zero-touch Enrollment:** Zero-touch Enrollment is a streamlined process for Android Devices to be provisioned for Enterprise Management. On first boot, Devices check to see if they’ve been assigned an Enterprise configuration. If so, the Device initiates the Fully Managed Device provisioning method and downloads the correct Device Policy controller App, which then completes the setup of the managed Device. ### Device security - **Device security challenge:** IT admins can set and enforce a Device security challenge (e.g., PIN/pattern/password) of a certain type and complexity on managed Devices. - **Work security challenge:** IT admins can set and enforce a security challenge for Apps and data in the Work Profile that is separate and has different requirements from the Device security challenge. - **Advanced passcode management:** IT admins can configure advanced password settings on Devices. - **Remote wipe and lock:** IT admins can use the Applivery Dashboard to remotely lock and wipe work data from a managed Device. - **Compliance enforcement:** If a Device is not compliant with security Policies, compliance rules put in place automatically restrict access to work data. - **Default security Policies:** Enforce the specified security Policies on Devices by default, without requiring IT admins to configure or customize any settings in the Applivery Dashboard. Some examples are access to debugging features blocked by default or installing Apps from unknown sources blocked by default. - **Security Policies for dedicated Devices:** Users can’t escape a locked-down dedicated Device to enable other actions. - **Verify Apps enforcement:** IT admins can enable Verify Apps on Devices. Verify Apps scans Apps installed on Android Devices for malware before and after they’re installed, helping to ensure that corporate data can’t be compromised by malicious Apps. - **Hardware security management:** IT admins can lock down hardware elements of a Device to ensure data loss prevention. Some examples are: IT admins can block users from mounting physical external media, block users from sharing data from their Device using NFC beam, or block users from transferring files over USB. ### App Management - **Silent App Distribution:** IT admins can silently distribute work Apps on users’ Devices without any user interaction. It includes installing, updating, and uninstalling Apps on managed Devices. - **Managed configuration management:** IT admins can view and silently set managed configurations for any App that supports managed configurations. - **App catalog management and whitelisting:** IT admins can configure the work Apps catalog from the Applivery Dashboard by whitelisting or blacklisting Apps. - **Programmatic App approval:** IT admins can search for Apps, approve Apps, and approve new App permissions without leaving the Dashboard. - **Basic Store layout management:** End users can use the Managed Google Play Store App on their Devices to install and update work Apps. By default, the Managed Google Play Store displays all Apps approved for a user in a single list. This layout is referred to as the basic Store layout. - **Google-hosted private App management:** IT admins can update Google-hosted private Apps through the Dashboard instead of through the Google Play console. - **Self-hosted private App management:** IT admins can configure and publish self-hosted private Apps. Unlike Google-hosted private Apps, the APKs / AABs are not hosted by Google Play. Instead, the Applivery helps IT admins host APKs in Applivery servers, and helps protect self-hosted Apps by ensuring they can only be installed when authorized by Managed Google Play. - **Web App management:** IT admins can create and distribute Web Apps in the Applivery Dashboard. ### Device Management - **Runtime permission Policy management:** IT admins can silently set a default response to all runtime permission requests made by work Apps. IT admins must be able to choose from the following options when setting a default runtime permission Policy for their organization: prompt (allows users to choose), allow, or deny. - **Runtime permission grant state management:** After setting a default runtime permission Policy, IT admins can silently set responses for specific permissions from any working App built on API 23 or above. - **Wi-Fi configuration management:** IT admins can silently provision enterprise Wi-Fi configurations on managed Devices, including SSID, Password, and multiple other advanced configurations. - **Wi-Fi security management:** IT admins can provision enterprise Wi-Fi configurations on Devices that include the following advanced security features (Identity, Certificates for client authorization, and CA certificates). - **Advanced Wi-Fi management:** IT admins can lock down Wi-Fi configurations on managed Devices to prevent users from creating new configurations or modifying corporate configurations. Users cannot modify any Wi-Fi configurations. - **Account management:** IT admins can ensure that only authorized corporate accounts can interact with corporate data, for services such as SaaS storage and productivity Apps, or email. Without this feature, users can add personal accounts to those corporate Apps that also support consumer accounts, enabling them to share corporate data with those personal accounts. IT admins can prevent users from adding or modifying accounts. - **Accessibility services management:** IT admins can control what accessibility services can be enabled on users’ Devices. While accessibility services are powerful tools for users with disabilities or who are temporarily unable to fully interact with their Device, they may interact with corporate data in ways that are non-compliant with corporate Policy. This feature allows admins to disable any non-system accessibility service. - **Location sharing management:** IT admins can prevent users from sharing location data with Apps in the Work Profile. Otherwise, the Work Profile location setting is user-configurable in Settings. - **Advanced location-sharing management:** IT admins can enforce a given location-sharing setting on a managed Device. This feature can ensure, for example, that corporate Apps always have access to high-accuracy location data, or that users don’t consume extra battery by restricting location settings to battery-saving mode. IT admins can set the Device location services to each of the following modes: high accuracy, sensors only (for instance, GPS, but not including network-provided location), battery saving (which limits the update frequency), and Off. - **Factory reset protection management:** Enables IT admins to protect Company-Owned Devices from theft by ensuring only authorized users can factory reset Devices. Admins can also disable factory reset protection entirely if it introduces operational complexities when Devices are returned to IT. - **Advanced app control:** IT admins can prevent the user from uninstalling or otherwise modifying managed Apps through Settings, for instance, force closing the App or clearing an App’s data cache. - **Screen capture management:** IT admins can block users from taking screenshots when using managed Apps. This includes blocking screen-sharing Apps and similar Apps (such as Google Assistant) that leverage the system screenshot capabilities. - **Disable cameras:** IT admins can disable the use of Device cameras by managed Apps. - **Reboot device remotely:** IT admins can remotely reboot managed Devices. - **System radio management:** IT admins can prevent users from modifying mobile network settings, configure if the Device permits cellular data while roaming, configure whether the Device can make outgoing phone calls, excluding emergency calls, configure whether the Device can send and receive SMS messages, prevent users from using their Device as a portable hotspot by tethering, set the Wi-Fi timeout to default, only while plugged in, or never and prevent users from configuring or modifying existing Bluetooth connections. - **System audio management:** IT admins can silently control Device audio features, including muting the Device, preventing users from adjusting volume settings, and preventing users from unmuting the Device microphone. IT admins can silently mute managed Devices, prevent users from modifying Device volume settings, and prevent users from unmuting the Device microphone. - **System clock management:** IT admins can control Device clock and timezone settings, and prevent users from modifying automatic Device settings. - **Advanced dedicated Device features:** disable the Device keyguard, disable the Device status bar, block notifications, and quick settings, force the Device screen to remain on while the Device is plugged in, and prevent the following system UIs from being displayed (Toasts, Phone activities, system alerts, system errors, and system overlays), enable the system recommendation for Apps to skip their user tutorial and other introductory hints on first start-up (skip first use hints). ### Device usability - **Managed provisioning customization:** IT admins can modify the default managed provisioning flow UX to include enterprise-specific features. Optionally, admins can display EMM-provided branding during provisioning. IT admins can customize the provisioning process by specifying the following enterprise-specific details: enterprise color (see `primaryColor`), enterprise logo (see `logo`), enterprise terms of service, and other disclaimers (see `termsAndConditions`). - **Lock screen messages:** IT admins can set a custom message that’s always displayed on the Device lock screen and does not require Device unlock to be viewed. - **Policy transparency management:** IT admins can customize the help text provided to users when they attempt to modify managed settings on their Device or deploy an EMM-supplied generic support message. Both short and long support messages can be customized, and are displayed in instances such as attempting to uninstall a managed App for which an admin has already blocked uninstallation. - **System update Policy:** IT admins can configure and apply over-the-air (OTA) system updates for Devices. - **Lock task mode management (Kiosk App):** IT admins can lock an App or set of Apps to the screen and ensure that users can’t exit the App. - **Persistent preferred activity management:** Allows admins to set an App as the default intent handler for intents that match a certain intent filter. For example, this would allow admins to choose which browser App automatically opens all web links, or which launcher App is used when the user hits the home button. - **Keyguard feature management:** IT admins can control the features available to users before unlocking the Device keyguard (lock screen) and the work challenge keyguard (lock screen). - **Advanced keyguard feature management:** IT admins can control advanced Device keyguard (lock screen) features. 5.12.1. IT admins can disable the following Device keyguard features: secure camera, all notifications, unredacted, trust agents, fingerprint unlock, and all keyguard features. - **Remote debugging:** The Android Management API doesn’t currently support this feature. - **MAC address retrieval:** Applivery MDM can silently fetch a Device’s MAC address, to be used to identify Devices in other parts of the enterprise infrastructure (for example, when identifying Devices for network access control). - **Advanced lock task mode management:** When a lock task mode is enabled on a Device, IT admins can use the Dashboard to perform the following tasks: home button, overview, global actions, notifications, system info /status bar, and keyguard (lock screen). - **Advanced system update policy:** IT admins can set a specified freeze period for blocking system updates on a dDvice. - **Work Profile Policy transparency management:** IT admins can customize the message displayed to users when removing the Work Profile from a Device. --- ## Get Started Source: https://docs.applivery.com/en/device-management/android/get-started/ Description: Set up Android Enterprise with Applivery for secure Device Management. Google Workspace and Gmail account configurations in 4 steps. TL;DR: Configure Android Enterprise with Applivery by setting up your Google account and integrating with Managed Google Play for device management. Key topics: Android Enterprise organization setup, Google account types for EMM, Google Workspace configuration, Applivery Android Enterprise registration, Managed Google Play integration, Applivery, Android Enterprise, Google Workspace, Gmail, Google Admin Console, Managed Google Play, MDM, EMM To begin managing Android Devices with Applivery, the first step is to set up an **Android Enterprise** organization. This links your company to Google’s Android management infrastructure, allowing Applivery to securely deploy Apps, apply Policies, and control Devices across your fleet. This registration is required before any Android device management features can be used, and it establishes the connection between your organization and Google’s Android Enterprise Mobility Management (EMM) services. ### Choosing the right Google account type Before starting the setup, it’s important to decide what kind of Google account you’ll use to register your organization. This choice affects how your environment is configured and what features will be available to you. #### Google Workspace (managed domain) If your organization uses **Google Workspace** (formerly G Suite), we strongly recommend using a managed account under your corporate domain (e.g., `user@yourcompany.com`). This setup offers the highest level of integration, centralized management, and scalability. To proceed with this option, a few requirements must be met: - The account you use must be an **Administrator** in Google Workspace — a **Super Admin** — with permission to authorize EMM integrations. - Your domain must already be **verified** in Google Workspace. - You’ll need to **enable third-party EMM integration** from the Google Admin Console. Enabling this integration allows Applivery to act on behalf of your organization when managing Devices, applying Policies, and deploying applications via Managed Google Play. :::tip Binding Applivery as a managed Google domain is also what unlocks domain-level identity control. Once it's set up, you can force Devices to be provisioned only with your company's accounts — see [Restrict Enrollment to a Corporate Domain](https://docs.applivery.com/en/device-management/android/policies/restrict-enrollment-to-corporate-domain/). ::: #### Gmail (unmanaged account) Alternatively, you can register your Android Enterprise setup using a personal **Gmail account** (e.g., `yourcompany@gmail.com`). This approach is quicker and easier, with no additional domain setup required — but it comes with limitations. Since it’s not connected to a corporate domain, this method is best suited for small teams, testing environments, or organizations that don’t use Google Workspace. It lacks advanced controls like domain-based app publishing or user management, but it still allows basic Android Device Management through Applivery. ### Configuring Google Workspace for Android Enterprise If you’ve chosen to use a **Google Workspace** (managed domain) account for your Android Enterprise setup, follow these steps to ensure your domain is properly configured and ready for integration with Applivery. **Verifying your domain in Google Workspace** Before you can link your organization with Android Enterprise, make sure your domain is verified in Google Workspace. To do this, log in to the [Google Admin Console](https://admin.google.com/) using a Super Admin account. From the Admin Console Dashboard, navigate to **Domains > Manage Domains**. If your domain hasn’t been verified yet, follow the prompts provided by Google to verify it, either by adding a DNS record or uploading an HTML file. Verifying your domain ensures that your organization is recognized by Google and enables you to take full advantage of enterprise-level management features, such as centralized App Distribution and Device Policies. ![domains](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/0e55aa0e-be26-4515-b370-2e15e1c8795f.png) **Enabling Third-Party EMM Integration** To allow Applivery to manage your Devices, you need to enable **third-party EMM integration** within the Google Admin Console. Navigate to **Devices** and access **Mobile & endpoints > Settings > Third-party integrations**, then select an Organizational Unit (OU). You can configure this setting at the parent level so that it applies to all child units, or you can customize it for individual child units if needed. You’ll see an option to **Enable third-party Android mobile management**. Turn this on to allow Applivery to integrate with Google Play for Work. ![enable-third-party-integration](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/687a28cf-cffc-439e-914b-28d1b3241fda.png) **Assigning admin roles for Android Enterprise** The Google account used for the Android Enterprise setup must have the appropriate permissions. If you’re not using a Super Admin account for the registration process, you’ll need to assign the necessary role. From the Admin Console, navigate to **Admin roles** and assign a role with the **Mobile Device Management** privileges, or give full **Super Admin** access if you want the setup to have complete control. Super Admin is recommended for a seamless setup, as it ensures no restrictions during the process. ![mobile-admin-privileges](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ff429f4c-29d1-4afc-91bc-761ab95de8f4.gif) ### Configuring Android Enterprise Once these configurations are complete, you’re ready to proceed with the registration process in Applivery. Here’s what happens next. **Configuring your account** In the [**Applivery Dashboard**](https://dashboard.applivery.io), go to the **Settings** section and locate the **Android Setup** section in the left-hand menu. Then follow the steps you will see on the screen. ![android enterprise](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/f8890981-780f-4f45-82bc-0bf20c16de20.png) Under point #2, your browser will redirect you to the **Google Play for Work** website. You have to log in using a Google Account. **Registering your Android Enterprise** ![](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/7fbbd68e-6110-4726-8a01-25855ebde2a4.png) Log in using your Google account and follow the next steps, where Google will ask you about the following information: - Name of the company. - Contact information for data protection: - Data Protection Officer: name,  email address, and phone number. - EU representative: name, email address, and phone number. - Accept Managed Google Play terms & conditions. ![](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/4a8f4d99-53a7-4668-b3b0-be34ed534936.png)![](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/1f7b82ed-3fea-472a-9011-303371255d2f.png) **Finish and return to Applivery's Dashboard** Once finished, click the **Complete registration** button. Your browser will be automatically redirected back to the **Applivery Dashboard,** where you can start configuring your Devices and Policies. --- ## Migrate from Managed Google Play Accounts to Managed Google Domain Source: https://docs.applivery.com/en/device-management/android/migrate-to-managed-google-domain/ Description: Upgrade an existing Android Enterprise binding from a Managed Google Play Accounts enterprise to a Managed Google Domain in Applivery — without re-enrolling your managed Devices. TL;DR: If your Android Enterprise is bound as a Managed Google Play Accounts enterprise, you can upgrade it to a Managed Google Domain from Applivery's Android Setup or the Managed Google Play catalog. The upgrade keeps the same Enterprise ID and doesn't re-enroll Devices, but it's one-way. Key topics: Android Enterprise identity models, Enterprise upgrade, Managed Google Domain binding, Google Workspace prerequisites, Android Enterprise, Managed Google Play, Managed Google Domain, Google Workspace, Applivery Android Enterprise supports two identity models for provisioning Devices: **Managed Google Play Accounts Enterprise** and **Managed Google Domain**. In the first, users are registered through _Managed Google Play Accounts_ — accounts provisioned directly by the EMM provider and not tied to an existing corporate domain. _Managed Google accounts_ aren't supported here, because structurally they aren't part of this model. In the second, your organization operates on a managed Google domain (for example, Google Workspace or Cloud Identity), so users authenticate with their corporate _managed Google accounts_ and that identity is associated directly with the managed Android Devices. In practice, this determines how much identity control you have. If you need to restrict provisioning to corporate identities from a specific domain, the Managed Google Domain is the model you need. Under a Managed Google Play Accounts enterprise, identity control is limited to the Managed Google Play Accounts scheme, with no way to apply domain-level restrictions. So, whenever you need to limit account sign-up on the Device to only those belonging to your corporate domain, Applivery must have been bound as a **Managed Google Domain**. :::info Since 2024, Google provisions a Managed Google Domain by default for all new organizations that register for Android Enterprise, as noted in the [official Android Enterprise documentation](https://support.google.com/work/android/answer/7042221). The Managed Google Play Accounts enterprise model remains as a fallback for specific cases — for example, organizations that can't or don't want to bind a managed Google domain. This migration applies to organizations already running the older model that want to move to the managed domain model. ::: ### Differences and benefits

Managed Google Play Accounts Enterprise

Managed Google Domain

User account type

Managed Google Play Accounts (limited accounts, created and managed by the EMM)

Managed Google accounts (full accounts, tied to the corporate domain)

Responsible for authentication

The EMM (Applivery)

Google

Tied to a corporate domain

No

Yes

Domain-based sign-up restriction

Not available

Available (Authentication Type: GOOGLE_AUTHENTICATED + managed domain)

Access to other Google services

Managed Google Play only

Full Google suite (Workspace, Cloud Identity, etc.)

Centralized user management

No

Yes (Google Admin Console)

Organization-wide SSO / MFA

No

Yes

Google's recommendation

Fallback only

Recommended and default since 2024

Migrating to a Managed Google Domain gives you: - **Domain-restricted provisioning** — you can require a corporate account (for example, force authentication with `@yourcompany.com` on the Device's first boot). - **Corporate-credential administration** — proper identity governance (roles, MFA, SSO) instead of relying on a loose Gmail account. - **Centralized management** of users, apps, and Devices alongside the rest of your Google products (Workspace, ChromeOS, Chrome browser) from the Google Admin Console. - **Reduced risk** from depending on a personal Gmail account for the binding — compromise, loss of access if the account owner leaves, and no corporate security controls. ### Before you start Check the following before you begin the migration: - Your organization must currently be registered as a **Managed Google Play Accounts enterprise** in Applivery. The upgrade only accepts enterprises with `enterpriseType: MANAGED_GOOGLE_PLAY_ACCOUNTS_ENTERPRISE`. If the binding is already a managed Google domain, the operation doesn't apply. - A **managed Google domain** must exist (or be created) for your organization — for example, through Google Workspace or Cloud Identity. - Your Applivery billing plan must include this feature. The API returns `5050 – Feature not allowed for your billing plan` if it doesn't. #### Configure the Google Workspace side These are the same requirements Applivery asks for when setting up an Android Enterprise directly on a managed domain, and they apply equally before migrating an existing enterprise. **Verify your domain** Your corporate domain must be **verified** in Google Workspace. Check and manage it from the [Google Admin Console](https://admin.google.com/), signed in with a **Super Admin** account, under **Domains → Manage domains**. If it isn't verified, Google will show you how (a DNS record or an HTML file upload). ![verify your domain](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/c6b8a356-e987-4cd4-9a13-13e9d36bb8cc.png) **Enable third-party EMM integration** For Applivery to manage Devices under the managed domain, enable third-party EMM integration in **Devices → Mobile & endpoints → Settings → Third-party integrations**. Select the relevant Organizational Unit (OU) — you can apply it at the top level or per OU — and turn on **Enable third-party Android mobile management**. ![third-party](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/142c86af-f4be-4cbb-aa91-6a6225231f60.png) **Confirm admin permissions** The Google account used in the process must have sufficient permissions — **Super Admin** is recommended. If you use a different account, assign it a role with **Mobile Device Management** privileges from **Admin roles** in the Google Admin Console. ![perms](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/fb96b54f-1e30-40b7-b9f1-66ed4c5e16cc.png) ### Migrate your Enterprise The upgrade keeps the same enterprise binding (the same Enterprise ID) and doesn't require re-enrolling Devices that are already managed. You can start it from two places in Applivery — both open Google's assistant to bind your account to the managed Google domain. #### Option 1 — From Android Setup **Open Android Setup** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), go to **Settings**, then **Android**, and open the **Setup** section. **Start the upgrade** Click **Start Upgrade**. Google's assistant opens so you can bind the account to your managed Google domain. ![android enterprise binding details](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/89502a08-a003-432c-8f26-43660817b4fd.png) #### Option 2 — From the Managed Google Play catalog **Open the Google Play catalog inside a policy** Go to **Policies**, select any Android policy, and open **Apps**. Click **\+ Add App**, then **Google Play**. **Choose Upgrade for free** In the Managed Google Play iFrame, click **Upgrade for free** to open Google's binding assistant. ![upgrade for free](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/4dcd6e2b-5358-4925-b724-943423e0fc51.png) #### Complete the upgrade in Google **Sign in with your Super Admin account** Open the URL from the previous step with the Google Workspace **Super Admin** account for your corporate domain. **Follow Google's assistant** Follow the assistant to bind the existing enterprise to the managed domain. Confirm the domain binding and accept the terms Google requests during the process. **Verify the result** Back in the Applivery Dashboard, go to **Settings**, then **Android**, open the **Setup** section, and confirm the enterprise now shows as bound to a managed domain. ### Known API errors

Code

Message

Cause

5050

Feature not allowed for your billing plan

Your billing plan doesn't include this feature

6002

Body Validation Error

The request body doesn't match the expected schema

5147

Enterprise upgrade is only available for managed Google Play Accounts enterprises (MANAGED_GOOGLE_PLAY_ACCOUNTS_ENTERPRISE)

The enterprise is already in Managed Google Domain mode

5095

Error From Emm Android Library

Error returned by the Android EMM library while processing the request

4002 / 4004

No auth token / Invalid Token

Authentication failure on the request

3001

Entity not found

The specified organization doesn't exist

If you hit an error code not listed here, contact Applivery support with your organization ID and the exact code. ### Additional considerations :::warning This process is **one-way**. Once you migrate to a Managed Google Domain, there is no equivalent downgrade endpoint to return to a Managed Google Play Accounts enterprise. ::: - Evaluate the impact on already-enrolled Devices before running the migration in production, and validate it first on a test enterprise or organization if you can. - After the migration, the **Required Account Email** field in the [Work Account Setup Config](https://docs.applivery.com/en/device-management/android/policies/restrict-enrollment-to-corporate-domain/) policy still accepts only one specific account, not a domain wildcard. Domain-level restriction comes from the nature of the binding (managed Google domain) combined with **Authentication Type: GOOGLE\_AUTHENTICATED**, not from that field. --- ## Android OEM Configs Source: https://docs.applivery.com/en/device-management/android/oem-configs/ Description: Android OEM Configs in Applivery — centrally manage manufacturer-level settings, security Policies, and Kiosk Mode for Android Devices. TL;DR: Android OEM Configs in Applivery provides centralized management of OEM-specific Android device settings, security policies, and kiosk mode configurations. Key topics: Android OEM Configs, Device Management, Applivery, Kiosk Mode, Security Policies, Android, OEM OEM Configs allow you to apply manufacturer-specific settings to Android Devices beyond what standard MDM Policies cover. Different OEMs expose different configuration options — Applivery lets you manage these through a structured interface within your Policies. OEM Configs let you apply manufacturer-specific settings from Applivery, with configuration options for each supported manufacturer. --- ## Bluebird BOS™ OEMConfig Source: https://docs.applivery.com/en/device-management/android/oem-configs/bluebird-oemconfig/ Description: Configure Bluebird BOS™ OEMConfig with Applivery — enforce Policies and manage Bluebird Devices remotely from the Dashboard. TL;DR: Remotely manage and configure Bluebird devices using BOS™ OEMConfig through Applivery, leveraging Android Enterprise for policy enforcement. Key topics: Bluebird BOS™ OEMConfig, Applivery integration, Android Enterprise configuration, Remote device management, Device policy enforcement, Bluebird, BOS™ OEMConfig, Applivery, Android Enterprise ![bluebird-logo](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/513cd1ec-0fc1-4495-a7c7-61a953ffd61c.png) **BOS™ OEMConfig** is Bluebird's enterprise-grade configuration tool that enables IT administrators to remotely manage and fine-tune Device behavior at a system level. Through integration with Applivery, BOS™ OEMConfig leverages Android Enterprise's managed configurations framework to apply granular controls over Bluebird-specific hardware and software components. Administrators can define and enforce advanced Device Policies — including network parameters, application management, security restrictions, and kiosk mode behavior — all from a centralized management Dashboard. This integration ensures full compliance, consistent Device performance, and streamlined control across the entire Bluebird Device fleet. ### Getting started Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), go to any of your **Policies** 1. From the left side menu, go to **Apps** 2 and click the **\+ Add App** button 3. ![](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/78ce8831-975c-4a2c-95bc-ac7105fa36f8.png) Search for the **BOS™ OEMConfig** App and select the one from **Bluebird Inc.** (package name: `com.bluebird.android.oemconfig`). Set the **Install Type** to **Force Installed** to ensure the App is automatically installed on any Device associated with the Policy. Once the App appears in the list, click on it to expand all the **managed properties** and configure them according to your requirements. ![bos oemconfig](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/d50e9c1d-0eca-4a95-b830-d94074c283a1.png) :::warning The OEM-specific settings described in this document are defined and maintained by their respective OEM vendors, and may change periodically. Since these configurations are managed externally, the options and values displayed in the Applivery Dashboard may occasionally differ slightly from those shown in this documentation. ::: **App Management** | Settings | Description | | --- | --- | | Install APK | Enter the URLs (separated by commas) that allow direct APK downloads. The Device will automatically download and install the Apps from these links. | | Uninstall Application | Specify the package names of Apps to be removed from the Device. | | Sets Default Launcher | Specify the package name of the application that should be configured as the default launcher. | | Unknown Source | Allow app installations from unknown sources by enabling this option. Not supported on Android 8 or later. | | Verify Apps Over USB | Enable this option to display the **Verify Apps over USB** setting on the Device. | | Initialize App Status | Activating this option initializes the App state by enabling all applications that were previously disabled. | | Disabled App List | Enter a comma-separated list of package names for Apps to be disabled. Disabled Apps will be hidden from the launcher and cannot be used. | | Enabled App List | Enter a comma-separated list of package names for Apps to be enabled. These Apps will appear in the launcher and will be accessible to users. | | Disable App Update | Enter a comma-separated list of package names for Apps that should have automatic updates disabled. Apps included in this list will remain on their current version and will not be updated automatically. | **Wi-Fi Configuration** | Settings | Description | | --- | --- | | Add Network | Specify a list of new Wi-Fi SSIDs to add to the Device.​ | | Network Name | Enter the SSID or Wi-Fi name. | | Hidden Network | Enable if the network does not broadcast its SSID. Not supported on Android 8 or lower. | | Direct Connect​ | Enable to try to connect to the Wi-Fi network immediately after adding it. | | Network Security​ | Define the security type. The available options are **NONE**, **WEP**, **PSK**, **EAP**, or **FT-PSK**. | | Password | Enter the password required to authenticate the network. | | Proxy | Configure a proxy server. The available options are **NONE**, **STATIC** and **PAC**. | | IP Settings​ | Specify IP assignment. The available options are **DHCP** or **STATIC_IP**.​ | | Host/Uri​ | Enter the proxy host address.​ | | Port​ | Enter the proxy port number.​ | | User ID​ | Enter the user ID for EAP authentication.​ | | EAP​ | Choose the Extensible Authentication Protocol for the network. The available options are **PEAP**, **TLS**, **TTLS**, **PWD**, **SIM**, **AKA**, **LEAP**, and **FAST**.​ | | Phase 2 | Select the Phase 2 authentication method. The available options are **NONE**, **PAP**, **MSCHAP**, **MSCHAPV2**, and **GTC**. | | Static IP Address | Enter the static IP address for the network.​ | | Static IP Gateway​ | Enter the network's gateway IP address.​ | | DNS List | Enter DNS1 and DNS2 addresses as a comma-separated list.​ | | Privacy (Randomized MAC)​ | Enable to connect using a randomized MAC address. Not supported on Android 9 or lower.​ | | R SSID​ | Specify the Wi-Fi SSIDs to remove from the Device.​ | | R SSID Security | Select the security type of the Wi-Fi network to be removed. The available options are **NONE**, **WEP**, **PSK**, **EAP**, and **FT-PSK**.​ | | Network Notification | Enable this option to show notifications whenever a public Wi-Fi network is available.​ | | WLAN Country Code | Choose the country code for the Wi-Fi network. | | Frequency Band | Choose the frequency band that the Device should use for the Wi-Fi network.​ | | Wi-Fi Auto Wakeup | Enable this option to allow the Device to automatically turn on Wi-Fi whenever it detects a saved network with strong signal quality.​ | | Wi-Fi Icon Visible | Show the Wi-Fi icon even when disconnected. Not supported on Android 8 or lower.​ | | Wi-Fi Operation Mode | Set the Wi-Fi operation mode. Supported only on Android 7 (EF501/EF401).​ | | Hide Wi-Fi Settings | Choose whether to hide Wi-Fi settings. The available options are **Off (show)**, and **On (hide)**.​ | | All Wi-Fi Privacy | Set global Wi-Fi privacy. The available options are **On (use device MAC)**, and **Off (use randomized MAC)**. | | Wi-Fi Calling Mode | Select the Wi-Fi calling mode. The available options are **UNKNOWN**, **Wi-Fi ONLY**, **CELLULAR PREFERRED**, **Wi-Fi PREFERRED**.​ | **Sound Configuration** | Settings | Description | | --- | --- | | Alarm Volume​ | Set the Device's alarm volume. Minimum: 0, Maximum: 7.​ | | Media Volume​ | Set the media playback volume. Minimum: 0, Maximum: 15. | | Ring Volume | Set the phone's ringtone volume. Minimum: 0, Maximum: 7.​ | | Call Volume | Set the in-call voice volume. Minimum: 1, Maximum: 5. | | Default Notification Sound | Choose whether the default notification sound is enabled. Not supported on Android 7.0 Nougat and above.​ | | Dial Pad Tones | Enable or disable sounds while dialing.​ | | Screen Locking Sounds | Enable or disable sounds when locking or unlocking the screen.​ | | Touch Sounds | Enable or disable sounds when interacting with the touchscreen.​ | | Touch Vibration | Enable or disable vibration feedback when touching the screen.​ | **Display Configuration** | Settings | Description | | --- | --- | | Brightness Level | Adjust the screen backlight brightness. Valid range between 0–255.​ | | Auto-Rotate Screen | Enable or disable automatic screen rotation. | | Screen Saver | Choose whether to turn the screen saver on or off.​ | | Screen Time Out | Set the duration of inactivity before the screen turns off. The available options are **15 seconds**, **30 seconds**, **1 minute**, **2 minutes**, **5 minutes**, **10 minutes**, or **30 minutes**. | | Dark Theme | Enable or disable Dark Mode — On activates it, while Off turns it off.​ | | Desktop Mode | Configure desktop mode settings, including **Force activities to be resizable**, **Enable freeform windows**, and **Force desktop mode**.​ | | Update Display Size | Adjust the display scaling. The available options are **204**, **240**, **246**, **254**, and **262**.​ | | Update Font Size | Adjust the text size. The available options are **0.85**, **1.00**, **1.15**, **1.30**, **1.50**, **1.80**, or **2.00**.​ | **Date & Time Configuration** | Settings | Description | | --- | --- | | Time Zone | Specify the Device's time zone.​ | | Automatic Time Zone | Enable this option to automatically use the network-provided time zone.​ | | Automatic Date & Time | Enable to automatically use the network-provided date and time.​ | | Use 24-Hour Format | Enable this option to display time in the 24-hour format.​ | | NTP Server | Enter the URL of the NTP server to synchronize the Device's time.​ | | **Set the date of the Device​** | | | Year | Set the system year for the Device.​ | | Month | Set the system month for the Device. | | Day | Set the day for the Device based on the specified time zone.​ | | **Set the time on the Device​** | | | Hour | Set the Device time (in hours) according to the specified time zone. | | Minute | Set the Device time (in minutes) according to the specified time zone.​ | **Kiosk Configuration** | Settings | Description | | --- | --- | | Kiosk State | Select whether to enable or disable kiosk mode on the Device.​ | | Kiosk Customer Name | Enter the customer name associated with the kiosk. **This field is required**.​ | | Blocks | Specify the list of system features to be blocked. The available options are **Status bar**, **Recent Apps**, and **ADB**. | | Clip | Configure the function of the floating clip, such as enabling the **flash** or **barcode** feature.​ | | Password | Set a numeric password to access the Administrator page. The password **must be at least 4 digits**.​ | | List of app package names to use | Enter the package names of the applications accessible on the Device, separated by commas.​ | | Settings Shortcut | Configures which detailed settings shortcuts are accessible in kiosk mode, such as **Wi-Fi** and **Bluetooth**. | | Kiosk Google Search Widget | Enable this option to display the Google Search widget while the Device is in kiosk mode.​ | **OTA Configuration** | Settings | Description | | --- | --- | | Disable OTA Update | Enable to completely disable OTA updates.​ | | OTA OS Upgrade Start | Set whether to start the OTA OS upgrade. If a higher version is available and updated, the Device will restart, and you will not receive feedback on the update results.​ | | OTA Data Type | Enable it to allow OTA file downloads over a mobile data connection.​ | | OTA Server URL | Enter the OTA server URL. If left blank, the Device will attempt the OS update using the default URL.​ | | OS Update Pop-Up Window | Display a pop-up once updated information is received.​ | | Popup Time Settings | If the update is canceled, the pop-up will reappear at the specified time. Default: 08.​ | | OS Pop-Up Cancel Allowance (infinite) | Allows unlimited cancellation of the OS update pop-up.​ | | OS Pop-Up Cancel Allowance (date) | Set specific dates for OS update popup behavior. Default: 1.​ | | Send CSR Info | Enter the server URL for sending CSR information.​ | | **Advanced OTA** | | | Product Server URL | Enter the product server URL. If left blank, the Device will attempt to retrieve the OTA URL using the default URL.​ | | Advanced OTA Server URL | Enter the advanced OTA server URL for warranty information and Web Console access. If left blank, the Device will use the default URL.​ | | Agent Download URL | Specifies the URL for the Advanced OTA Agent to update the pre-installed agent.​ | | Terminal Group | Define the group a Device belongs to, used for group-based updates.​ | | User ID | Enter the credential user ID for Web Console access.​ | | Password | Enter the password for Web Console access.​ | **Battery Configuration** | Settings | Description | | --- | --- | | Battery Percentage | Enable to show the battery percentage in the status bar.​ | | Active Low Battery Health Notification | Enable or disable Low Battery Health notifications in the Battery Manager App (v3.3.1 or later).​ | | Low Battery Health(%) Threshold | Set the battery health percentage at which the Low Battery Health notification triggers. Values differ by device model—typically between 60% and 80%.​ | | Active High Battery Cycle Notification | Enable or disable High Battery Cycle notifications in the Battery Manager App (v3.3.1 or later).​ | | High Battery Cycle Threshold | Set the battery cycle count at which the High Battery Cycle notification triggers. Values vary by model, usually between 400 and 600 cycles.​ | | Active High Battery Temperature Notification | Enable or disable High Battery Temperature notifications in the Battery Manager App (v3.3.1 or later).​ | | High Battery Temperature Threshold | Set the temperature (°C) at which the High Battery Temperature notification triggers. Values vary by model, typically between 50.0℃ and 59.0℃.​ | | Set BatterySaver Mode | Enable or disable Battery Saver mode. On activates the mode, Off deactivates it.​ | | Set BatteryMode Mode | Enable or disable “Battery Mode” mode. On activates the mode, Off deactivates it.​ | **Connection Configuration** | Settings | Description | | --- | --- | | Bluetooth | Enable or disable Bluetooth connectivity on the Device.​ | | NFC | Enable or disable NFC functionality on the Device.​ | **Network Configuration** | Settings | Description | | --- | --- | | Ethernet | Enable or disable Ethernet connectivity on the Device.​ | | Data Roaming | Enable or disable data roaming. Not supported on Android 8 or lower.​ | | Set Hide APN Password | Choose **Off to show** or **On to hide** the APN password.​ | | Set Enable Nano Card | Enable or disable the Nano SIM card. (Supported only on EF551, S50, and S70 models.)​ | | Disallow Share Wi-Fi QR Code | Prevent users from sharing Wi-Fi credentials via QR code.​ | | Set Captive Portal | Configure captive portal settings for the Device's network connection.​ | | **Specify the APN list to add​** | | | APN Name | Enter a name to identify the APN among other networks.​ | | APN Domain | Enter the domain name of the APN server.​ | | APN Proxy​ | Enter the domain name or IP address of the proxy server.​ | | APN Port | Specify the port number for the proxy server.​ | | APN MMS Proxy | Enter the domain name or IP address of the multimedia messaging proxy server.​ | | APN MMS Port | Specify the port number for the MMS proxy.​ | | APN Server | Enter the URL of the APN server.​ | | APN User | Enter the username used for authentication.​ | | APN Password | Enter the password associated with the username.​ | | APN MMSC | Enter the Multimedia Messaging Service Center URL for the APN.​ | | APN MCC | Enter the Mobile Country Code.​ | | APN MNC | Enter the Mobile Network Code.​ | | APN Type | Enter a comma-separated list of APN types. The available options include **DEFAULT**, **MMS**, **SUPL**, **DUN**, **HIPRI**, **FOTA**, **IMS**, **CBS**, **IA**, and **EMERGENCY**. Use ***** to allow all specified types.​ | | Authentication Type | Choose the authentication method. The available options are **NONE**, **PAP**, **CHAP**, or **PAP or CHAP**.​ | | Bearer | Define a list of bearers: **LTE**, **HSPAP**, **HSPA**, **HSUPA**, **HSDPA**, **UMTS**, **EDGE**, **GPRS**, **eHRPD**, **EVDO_B**, **EVDO_A**, **EVDO_0**, **1xRTT**, **IS95B**, or **IS95A​**. | | APN Protocol | Select the APN protocol: **IPv4**, **IPv6**, or **IPv4/IPv6**.​ | | APN Roaming Protocol | Select the APN protocol for roaming: **IPv4**, **IPv6**, or **IPv4/IPv6**.​ | | APN MVNO Type | Choose the type of Mobile Virtual Network Operator: **SPN** (Service Provider Name), **IMSI** (International Mobile Subscriber Identity), **GID** (Group Identifier), or **ICCID** (Integrated Circuit Card Identifier). | | APN MVNO Data | Enter the corresponding MVNO data. | | APN Preference | Enable this to set the configured APN as the default. | | **Remove the specified APNs. This feature is supported on Devices with BOS Provisioning App version 4.12.2 or later.​** | | | Remove Multiple APNs (Using APN Display Name as Input) | Enter the APN display names separated by commas. | | Remove Multiple APNs (Using APN Domain Name as Input) | Enter the APN domain names separated by commas. | | **Private DNS: By default, Devices automatically upgrade to DNS over TLS if the network's DNS server supports it. Users who prefer not to use DNS over TLS can disable it. This feature is not supported on Android 8 or lower.** | | | Private DNS Mode | Select the private DNS mode. The available options are **Off**, **Automatic**, or **Private DNS provider hostname**. | | DNS Provider Hostname | Enter the hostname of the DNS provider.​ | | **Ethernet Static IP** | | | IP Address | Enter the static IP address.​ | | Network Prefix Length | Enter the prefix length.​ | | Gateway | Enter the gateway address.​ | | DNS1 | Enter the primary DNS unless overridden by Private DNS. | | DNS2 | Enter the secondary DNS unless overridden by Private DNS. | | **Ethernet Network Configuration** | | | Ethernet State | Enter the state.​ | | Connection Type | Choose between **DHCP** or **Static IP**. | | **Static IP Configuration for Ethernet Network** | | | IP Address | Enter the static IP address.​​ | | Network Prefix Length | Enter the prefix length.​ | | Gateway | Enter the gateway address. | | DNS1 | Enter the primary DNS unless overridden by Private DNS. | | DNS2 | Enter the secondary DNS unless overridden by Private DNS. | | **Advanced Ethernet Options** | | | Proxy | Choose between **None**, **Manual**, or **Proxy Auto-Config**. | | Proxy Hostname | Enter the hostname. | | Proxy Port | Enter the proxy port (**for Proxy type: Manual**). | | Bypass Proxy for | Enter the bypass proxy port (**for Proxy type: Manual**). | | PAC URL | Enter the PAC URL (**for Proxy type: Auto-Config**). | | **Set Ethernet Config** | | | Ethernet Config Type | Choose between **Normal config** or **Enterprise config**. | | EAP Method | Choose between **PEAP**, **TTLS**, or **TLS**. | | Phase 2 Authentication | Choose between **None**, **PAP**, **MSCHAP**, **MSCHAPV2**, or **GTS**. | | Identity | Enter the identity. | | Anonymous identity | Enter the anonymous identity. | | Password | Enter the password. | | CA Certificate Name | Enter the CA certificate name. | | User Certificate Name | Enter the user certificate name. | | **Set Network PLMN** | | | Install PLMN Net ID | Enter the “Public Land Mobile Network” network identifier to be installed. | | Install PLMN Net Priority | Set the priority level for the specified PLMN network. | | Install PLMN Net Mode | Specify the network mode for the selected PLMN configuration. The available options are **GMS**, **WCDMA**, **LTE**, **NR**, or **Quadruple mode**. | **Input Configuration** | Settings | Description | | --- | --- | | Default IME | Enter the package name of the App to be used as the default Input Method Editor. | | Language | Specify the system language to be used on the Device. | | Spell Checker | Enable this option to turn on the spell checker. | | Pointer Speed | Adjust the pointer speed on the Device. You can set any value between **–7 and 7**. | | Disable Autofill Service | Enable this option to disable the Device's autofill service. | **Notification Configuration** | Settings | Description | | --- | --- | | Lock Screen Notification | Specify whether notifications should be displayed when the Device is on the lock screen. | **Location Configuration** | Settings | Description | | --- | --- | | Location Mode | Sets the Device's location mode. Options like DeviceOnly, BatterySaving, and HighAccuracy no longer have distinct meanings on Android 8 and higher. On these versions, all are simply interpreted as location services being enabled. | **Accessibility Configuration** | Settings | Description | | --- | --- | | Touch Type | Set the Device's touch type. Note that the available touch types may vary depending on the Device model, so please verify which values are supported for your specific model. The available options are **Normal**, **Glove**, **Pen**, and **Finger**, along with their corresponding variants. | **Peripheral Configuration** | Settings | Description | | --- | --- | | Select Key Format | Define the format of the side key. The available options are **SCAN/SCAN**, **SCAN/PTT**, **PTT/SCAN**, and **PTT/PTT**. | | DataWedge Mode | Configure the Barcode DataWedge mode. | | Floating Clip | Specify whether the floating clip feature is enabled. | | Set PTT/Scan Left Key | Configure the left PTT/Scan key behavior. The available options are **DISABLE**, **SCAN**, **PTT**. | | Set PTT/Scan Right Key | Configure the right PTT/Scan key behavior. The available options are **DISABLE**, **SCAN**, **PTT**. | | Set Volume Key as Scan Key | Specify whether the volume key should function as a scan key. | **Log Configuration** | Settings | Description | | --- | --- | | Logger State | Choose whether to start or stop the logger. | | Main Log | Enable this option to include main system logs. | | Kernel Log | Enable this option to include kernel logs. | | Radio Log | Enable this option to include radio logs. | | Event Log | Enable this option to include event logs. | **File Download Configuration** | Settings | Description | | --- | --- | | Download File Source URL | Specify the source URL of the file to be downloaded. | | Download Destination File Path | Specify the destination file path where the downloaded file will be saved. | **Restrictions Configuration** | Settings | Description | | --- | --- | | Block Home Key | Enable this option to block the home key. When activated, pressing the home key will have no effect. | | Block Recent-App Key | Enable this option to block the recent Apps key, which normally shows a card view of the most recently used Apps. | | Block Power Key | Enable this option to block the power key. When activated, pressing the power key will have no effect. | | Block Back Key | Enable this option to block the back key. When activated, pressing the back key will have no effect. | | Block Volume Key | Enable this option to block the volume keys. When activated, pressing the volume keys will have no effect. | | Block Vibration Mode Setting | Enable this option to prevent the Device from entering vibration mode. When blocked, the vibration mode cannot be activated using the volume up + power key combination. Not supported on Android 8 or lower. | | Block Status Bar | Specify how the status bar should be blocked. The available options are **All**, **None**, **Quick Settings**. | | Disable Recovery Mode | Enable this option to disable access to recovery mode. | | Disable Fastboot Mode | Enable this option to disable access to fastboot mode. | | Block Add User/Guest | Enable this option to prevent adding new users or guests to the Device. | | Disable Lock Screen | Enable this option to disable the Device's lock screen. | | Disallow Transferring Files Over USB | Enable this option to prevent file transfers over USB. | | Disallow Bluetooth | Enable this option to disable Bluetooth.​ | | Disallow Changing Wi-Fi Access Points | Enable this option to prevent the Device from changing Wi-Fi access points. | | Disallow External Mounted Memory | Enable this option to prevent access to external mounted memory. | | Disallow Mounting USB OTG | Enable this option to prevent USB OTG mounting. | | Disallow Settings | Enable this option to block access to the Device settings. | | Disable Microphone and Audio Recording | Enable this option to block all microphone and audio recording functionality on the Device. | | Disable Microphone and Audio Recording in the Call | Enable this option to disable the microphone and audio recording during calls when the microphone/audio is blocked. | | List of Packages Excluded From Disabling Microphone and Audio Recording | Enter a comma-separated list of package names for Apps that are exempt from microphone/audio restrictions. | | Disable Camera | Enable this option to block the Device camera. | | List of Packages Excluded From Disabling Camera | Enter a comma-separated list of package names for Apps that are exempt from camera restrictions. | | Disable Battery Manager Settings | Enable this option to block the Battery Manager App. | | Disallow Proximity Sensor During Calls | Enable this option to block the proximity sensor during calls. Not supported on Android 8 and lower. | | Disallow NFC | Enable this option to block NFC.​ | | Disallow Airplane Mode | Enable this option to block the Airplane mode. | | Disallow Add Multi User | Enable or disable the ability to add multiple users. | | Disallow DND Mode | Enable this option to block the Do Not Disturb mode. | | Disallow Auto Rotate | Enable or disable automatic screen rotation. | | Disallow Battery Saver | Enable this option to block battery saver.​ | | Disallow Data Roaming | Enable this option to block data roaming.​ | | Disallow Mobile Data | Enable this option to block mobile data.​ | **System Configuration** | Settings | Description | | --- | --- | | Set Device Name | Specify the Device name. | | Hide Hotseat | Hide the hotseat in the launcher. | | **Configure a list of certificates to be installed** | | | Input File Download URL | Enter the URL to download the certificate file. | | Input Certificate's Name | Enter the name of the certificate. | | Input Certificate's MIME Type | Enter the certificate's MIME type. The available options are **CA-CERT**, **PKCS12**, or **Wi-Fi-CONFIG**. | | Input Certificate's Password | Enter the password of the certificate. | | **Update SLED Firmware** | | | Firmware File URL | Specify the destination file path where the downloaded file will be saved. | | SLED Type | Specify the Scanner LED type. The available options are **RFR900**, **RFR901**, **RFR971**. | | Firmware File Version | Enter the firmware version. | | Start Update time(Hour) | Set the hour to start the firmware update. | | Start Update time(Minute) | Set the minute to start the firmware update. | **Barcode Configuration** | Settings | Description | | --- | --- | | Barcode Step | Add and configure a list of barcode profiles. | --- ## Deploy and configure Zebra OEMConfig Source: https://docs.applivery.com/en/device-management/android/oem-configs/deploy-and-configure-zebra-oemconfig/ Description: Deploy and configure Zebra OEMConfig with Applivery to manage Zebra Android Devices remotely, enforce Policies, and optimize performance. TL;DR: Configure and manage Zebra Android devices remotely using Zebra OEMConfig and Applivery to enforce policies and optimize device performance. Key topics: Zebra OEMConfig, Applivery integration, Android Enterprise, Device policy configuration, Remote device management, Zebra Technologies, Applivery, TC20, TC25 ![Zebra_Logo](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/d2f94e8a-1cd9-46d0-8757-5404f160c92a.png) **Zebra OEMConfig** is Zebra's enterprise-grade configuration solution that empowers IT administrators to remotely manage and customize Zebra Android Devices at a system level. By leveraging Android Enterprise's managed configurations framework, Zebra OEMConfig enables precise control over Zebra-specific hardware, software, and device settings — all without requiring custom applications or additional agents. Through integration with Applivery, administrators can seamlessly define, deploy, and enforce advanced device Policies such as network configurations, app management, security controls, display behavior, and kiosk mode restrictions. This integration ensures full compliance with organizational standards, optimizes device performance, and delivers consistent, streamlined management across the entire Zebra device fleet. Note To install the **Zebra OEMConfig Powered by MX** app via Applivery, Zebra Devices must be running **Android 11 or higher**. For Devices that do not meet this requirement, an alternative version — **Legacy Zebra OEMConfig** — is available to configure managed properties on older Android versions. ### Getting started Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), go to any of your **Policies** 1. From the left-side menu, go to **Apps** 2 and click the + Add App button 3. ![add app](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/052e37a7-4cf2-49e3-898d-e51a7b2d2db2.png) Search for the **Zebra OEMConfig Powered by MX** app and select the one from **Zebra Technologies** (package name: `com.zebra.oemconfig.release`). Set the **Install Type** to **Force Installed** to ensure the App is automatically installed on any Device associated with the Policy. Once the App appears in the list, click on it to expand all the **managed properties** and configure them according to your requirements. ![zebra oemconfig](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/e09a61c8-3551-44c8-85a8-46fcb7537e54.png) :::warning The OEM-specific settings described in this document are defined and maintained by their respective OEM vendors, and may change periodically. Since these configurations are managed externally, the options and values displayed in the Applivery Dashboard may occasionally differ slightly from those shown in this documentation. ::: **Device Central Config** Not supported on TC20 and TC25.

Settings

Description

Bluetooth Pairing Control

Define how the Device Central subsystem manages Bluetooth pairing. Choose one of the following options: Single Pairing per Device Class (allows only one active pairing at a time for each Bluetooth device class), Multiple Pairings per Device Class (allows multiple simultaneous pairings for each Bluetooth device class). Supported from MX 8.1.

User Control of Bluetooth State

Select whether users are permitted to use the Device Central UI to turn Bluetooth on or off. Supported from MX 8.1.

User Control of Firmware Update

Select whether users are allowed to use the Firmware Update Button to perform firmware updates through the Device Central subsystem. Supported from MX 8.1.

Smart Leash

State

Select whether Smart Leash is enabled or disabled. Supported from MX 10.2.

User Access To Smart Leash Section

Select whether the Device user is allowed to access the Device Central UI to configure Smart Leash settings. Supported from MX 10.2.

Audio Feedback State

Select whether Smart Leash Audio Feedback is enabled or disabled. Supported from MX 10.2.

Audio Feedback Sound

Specify an existing ringtone or the path to an audio file to play when Smart Leash Audio Feedback is enabled. Supported from MX 10.2.

Audio Feedback Volume

Specify the volume level (percentage) for the sound when Smart Leash Audio Feedback is enabled. Supported from MX 10.2.

Audio Feedback Repeat Count

Enter the number of times the sound should repeat when Smart Leash Audio Feedback is enabled. Supported from MX 10.2.

Haptic Feedback State

Select whether Smart Leash Haptic Feedback is enabled or disabled. Supported from MX 10.2.

Haptic Feedback Time

Specify the vibration duration when Smart Leash Haptic Feedback is enabled. Supported from MX 10.2.

**File Config**

Settings

Description

Device Path And Name

Specify the path and file name within the Device file system, or the target application package name, of the single file to be managed on the Device. Not supported on Devices TC20 and TC25.

Files Config Download Options

Add one or more download option elements to configure how files are downloaded to the Device. Select the type of download option to be applied when downloading a single file. The available options are On Server, On Server but Not on Device. Not supported on Devices TC20 and TC25. Supported from MX 5.0.

Download Server URI

Specify the server URI from which a single file can be downloaded to the Device file system. Not supported on Devices TC20 and TC25. Supported from MX 11.3.

Download Application Signature

Enter the digital signature of the target application associated with the download. Supported from MX 11.3.

Download File Persistence

Select whether the downloaded file should remain stored on the Device after an enterprise reset. Supported from MX 11.3.

Files Config Upload Options

Add one or more upload option elements to configure how files are uploaded from the Device. Select the type of upload option to be applied when managing a single file in the Device file system. The available options are Not on Server, Sorted by Name. Not supported on Devices TC20 and TC25. Supported from MX 10.1.

Upload File Name Pattern

Enter a naming pattern to be used for files uploaded from the Device file system to the server.

Upload Server URI

Specify the server URI where files from the Device file system will be uploaded.

Files Config Delete Options

Add one or more delete option elements to configure how files are deleted from the Device file system. Select the type of delete option to be applied when managing a single file. The available options are Always, After Reboot. Not supported on Devices TC20 and TC25. Supported from MX 5.0.

**Keyboard Mappings** Not supported on Devices TC20 and TC25.

Settings

Description

Key ID

Select the key identifier that uniquely corresponds to a physical key on the Device's hardware keyboard to be remapped.

Keymapping Behaviors

Add one or more behavior elements to define the desired key remapping behavior.

**License Management**

Settings

Description

Enterprise Reset Persistence

Select whether all Zebra licenses should remain stored locally on the Device after an Enterprise Reset. Supported from MX 11.2.

License Server Proxy URL

Enter the proxy server URL used to manage licensing requests. (Optional — requires ZLicenseMgr v14.0.). Supported from MX 14.0.

Badge Licenses Cloud Server Type

Select the source server from which a Zebra capability license will be obtained. The available options are Production Cloud, Test Cloud. Supported from MX 14.0.

Badge Licenses ID

Enter the Zebra-issued Badge ID for the license pool from which licenses will be issued. Supported from MX 14.0.

Products

Add license details to be deployed to the Device. Supported from MX 14.0.

LLS License

Open this section to configure the Local Server URL and License Information. Requires ZLicenseMgr v14.5. Supported from MX 14.0.

Licenses

Add one or more License Configuration – Licenses – License elements. Supported from MX 14.0.

Features

Add one or more License Configuration – Features – Feature elements. Supported from MX 14.0.

**PKG Config**

Settings

Description

Class Name

Enter the class name within the Android package for which one or more non-default, class-specific behaviors should be configured. Supported from MX 4.3.

Package Name

Enter the package name of the Android application for which one or more non-default behaviors should be configured.

Package Signing Certificate

Enter the package signing certificate used to verify that the Android package identified by the Package Name is a genuine and trusted instance of that package.

Package Permissions

Add one or more permission elements to configure permissions for the specified package. Supported from MX 10.4.

Package Class Variances

Add one or more class variance elements to configure class-specific behavioral variations.

Package Feature Variances

Add one or more feature variance elements to configure feature-specific behavioral variations.

Package Allowed Services

Add one or more allowed service elements to define the services that the package is permitted to access. Supported from MX 8.3.

**Security And Privacy Config**

Settings

Description

Encrypt Config: Configure encryption keys and the SD Card encryption key name. Not supported on Devices TC20 and TC25.

Security Encryption Keys

Add one or more encryption key elements to configure encryption keys. Supported from MX 4.3.

Key Name

Enter the key name of a defined (named) encryption key.

Key Value

Enter the key value associated with the specified encryption key name.

SD Card Encrypt Key Name

Enter the key name of the encryption key used to encrypt the removable SD card. Supported from MX 4.3.

Screen Lock Config. Not supported on Devices TC20 and TC25.

Instant Screen Lock on Power Key

Select whether the Device should instantly lock when the Power Key is used to turn off the display. Supported from MX 4.3.

Lock Screen Wallpaper

Select the wallpaper image to be displayed on the lock screen. The available options are Restore to default and Custom. Supported from MX 10.5.

Custom Lock Screen Wallpaper

Enter the path and file name of a custom image file (.jpg or .png) stored on the Device to use as the lock screen wallpaper. Supported from MX 10.5.

Screen Lock Type

Select the type of screen lock used to protect the Device from unauthorized access. The available options are None, Swipe, PIN, Password, and Pattern. Supported from MX 6.0.

Notifications on Lock Screen

Select the type of notification content to display on the lock screen. The available options are Show all content, Show only non-sensitive content, and Hide notifications. Supported from MX 10.5.

RC Lock Screen Visibility

Select whether the Android lock screen should be visible in the remote console when the Device is being remotely controlled. Supported from MX 13.3.

Screen Lock Timeout

Select what action the Device should take when the display turns off due to a timeout. The available options are Inmediately after Display Timeout, 5 seconds after Display Timeout, 15 seconds after Display Timeout, 30 seconds after Display Timeout, 1 minute after Display Timeout, 2 minutes after Display Timeout, 5 minutes after Display Timeout, 10 minutes after Display Timeout, and 30 minutes after Display Timeout. Supported from MX 4.3.

User Selection of Secure Start-up

Select whether the user is allowed to enable Secure Start-up when changing their PIN, password, or pattern. Supported from MX 10.0.

Secondary Keyguard

Select whether to activate a secondary keyguard (e.g., Identity Guardian) on the Device. Supported from MX 14.0.

Reboot

Select whether the Device should reboot immediately after applying the Secondary Keyguard setting, or suppress the reboot to apply the change later. Supported from MX 14.0.

Double-line Clock on Lock Screen

Select whether the lock screen clock should be displayed on a single line or across two lines in a larger font (when space allows). Supported from MX 14.1.

SD Card Setup Notification

Select whether to display a notification to the user when an SD card is inserted into the Device. Supported from MX 11.5.

**System Config**

Settings

Description

Analytics Config

Analytics State

Select whether the Analytics Client is allowed to collect device data and send it to Zebra. Supported from MX 4.3.

User Control of Analytics State

Select whether the user is allowed to control the Analytics Client's ability to collect and transmit device data to Zebra. Supported from MX 7.2.

Clock Config

Time Mode

Select whether the time mode is Automatic (time set using information obtained from a time server) or Rule-Based (time set using specified rules and parameters). Supported from MX4.2.

Auto NTP Server Address

Select the allowed drift threshold at which the Device will automatically attempt to reacquire and reset the time and date when Time Mode is set to Automatic. Supported from MX 4.2.

Auto NTP Drift Interval

Select the allowed drift threshold at which the Device will automatically attempt to reacquire and reset the time and date when Time Mode is set to Automatic. Supported from MX 11.7.

Auto NTP Sync Interval

Select the interval at which the Device will automatically attempt to synchronize the time and date when Time Mode is set to Automatic. Supported from MX 4.2.

Time Zone Mode

Select whether the time zone is set manually (explicitly defined) or automatically (based on information obtained from the carrier network). Supported from MX 6.0.

Manual Time Zone

Enter the time zone to be applied when Time Zone Mode is set to Manual.

Time Format

Select the display format for the Device's system time. Supported from MX 6.0.

Data Wipe Config. Not supported on Devices TC20 and TC25.

Data Wipe Options Type

Add one or more data wipe option elements to define how device data should be wiped. Select a single wipe method to determine how data on the Device will be erased. The available options are Primary Storage, Persistent Storage, and Portable Storage.

Bypass SUW on Enterprise Reset

Select whether the Google Setup Wizard (SUW) should be bypassed when performing an Enterprise Reset as part of a data wipe operation.

GMS Config. Not supported on Devices TC20 and TC25.

GMS Feature Set

Select the GMS feature set to be enabled on the Device. The available options are All, Restricted, and Profiled.

GMS Profile

Select the GMS profile that defines the subset of GMS features to be used. The available options are Chrome Browser, Google Maps, Firebase Cloud Messaging, and Combination of Chrome and Maps and FCM. Supported from MX 8.3.

Fota Config

Update Mode

Select how LifeGuard Updates are applied. The available options are Fully Automatic, EMM Controlled, and File-Based Updates. Not supported on Devices TC20 and TC25. Supported from MX 11.1.

UI Control

Select whether the user can modify LifeGuard update settings through the UI. Not supported on Devices TC20 and TC25. Supported from MX 9.1.

Update Over Cellular

Select whether automatic LifeGuard updates are allowed over metered cellular networks. Not supported on Devices TC20 and TC25. Supported from MX 11.1.

OTA Options

Enter optional parameters that control OTA update behavior. Not supported on Devices TC20 and TC25. Supported from Future use.

File-Based Update Source

Select the source of the update file used for file-based OS updates. Not supported on Devices TC20 and TC25. Supported from MX 8.1.

File-Based Update Options

Add one or more update option elements to control file-based update behavior. Not supported on Devices TC20 and TC25. Supported from MX 8.1.

Suppress Reboot

Select whether to prevent automatic reboot after an A/B update. Not supported on Devices TC20 and TC25. Supported from MX 8.1.

File-Based Update Local Path And Name

Enter the path and filename of a local update package used in file-based updates. Not supported on Devices TC20 and TC25. Supported from MX 4.1.

Fota Streaming Config

Source URL

Enter the URL where the update file is hosted.

Authorization Type

Select the authentication method required by the remote server. The available options are No Authorization, Zebra Authentication Token, Basic Authentication, and Custom Authorization Header.

Zebra Authentication Token

Enter the token for Zebra Support Central authentication.

Username

Enter the authorized username for accessing the update package.

Password

Enter the password for the specified username.

Custom Authentication Header

Provide a custom authorization header value, if required.

Power Config. Not supported on Devices TC20 and TC25.

Auto Control Config

State

Select whether automatic power control is enabled.

On Mode

Select when and how the Device will automatically power on.

Off Mode

Select when and how the Device will automatically power off.

Off Timeout

Enter the timeout before the Device automatically powers off.

Battery Config

Critical Low Threshold

Enter the battery level threshold (in percentage) below which the battery is considered critically low. Supported from MX 8.3.

Decommission Percentage Threshold

Enter the percentage of remaining battery capacity below which the battery is considered ready for decommissioning. Supported from MX 4.4.

Decommission Usage Threshold

Enter the total battery usage (e.g., charge/discharge cycles or coulombs in/out) after which the battery will be considered ready for decommissioning. Supported from MX 4.4.

Saver Control Mode

Select how Battery Saver Mode is controlled. Supported from MX 10.1.

Saver Mode Percentage Threshold

Enter the battery level percentage below which Battery Saver Mode automatically turns on. Supported from MX 10.1.

Saver State

Select the Battery Saver Mode state. Supported from MX 10.1.

User Control of Saver

Select whether the user is allowed to control Battery Saver Mode through the Device UI. Supported from MX 11.2.

Battery Charge Mode

Select the battery charge mode. Supported from MX 11.6.

Maximum Battery Charge

Enter the maximum charge percentage (65–100%) at which the battery will stop charging. Supported from MX 11.6.

Recovery Mode Access

Select whether to enable or disable access to Recovery Mode. Supported from MX 13.1.

P B Charge Schedules

Add one or more elements to configure battery charge schedules. Supported on Android 11. Supported from MX 11.6.

Heaters

Add one or more elements to configure device heater settings. Supported on Android Oreo and Pie. Supported on Devices VC80X and VC8300. Supported from MX 9.1.

Ports Power

Add one or more elements to configure power settings for device ports. Supported on Android Oreo and Pie. Supported on Devices VC80X and VC8300. Supported from MX 7.1.

Doze Mode State

Select whether Doze Mode should be enabled or disabled for the entire device. Supported from MX 7.2.

Configure RAM On Disk

Select whether to allow a portion of available device storage to be used as RAM. Supported from MX 13.4.

Configure RAM Size

Select the amount of device storage to allocate as RAM. Supported from MX 13.4.

Custom RAM size

Enter a custom storage amount (1–12 GB) to allocate as RAM. Supported from MX 13.4.

Suppress Reboot

Select whether to reboot the Device after configuring the RAM-on-disk parameter. Zebra recommends selecting Turn Off to allow reboot. Supported from MX 13.4.

Remote Scanner Config. Not supported on Devices TC20 and TC25.

Config File

Enter the full path and file name of the configuration file located in the Device file system. This file must already exist at the specified location and will be used to apply configuration settings to the designated Remote Scanner. Supported from MX 5.2.

Scanner Serial Number

Enter the serial number of the Remote Scanner to which the configuration or action should be applied. Supported from MX 5.2.

Update File

Enter the full path and file name of the update file to be applied to the specified Remote Scanner. The file must be present in the Device file system. Supported from MX 5.2.

Wakeup Config. Not supported on Devices TC20 and TC25.

Wake-Up All Sources State

Select whether all wake-up sources should be collectively enabled or disabled. Supported from MX 8.0.

Wake-Up Method

Select the method used to identify and control wake-up sources. Supported from MX 9.2.

Wake-Up Sources

Add one or more elements to configure individual wake-up sources. Supported from MX 9.3.

Pass-Through Command

Enter OEMConfig XML to be passed through for processing. Note: XML pass-through must not include Batch, ConditionMgr, or persist elements.

Logs Config

Background Collection State

Select whether background log collection is enabled.

Logging Level

Select the logging detail level to be applied.

Upload When Logging Turned Off

Select whether to upload logs to the designated URI when logging is disabled.

Upload Snapshots URI

Enter the remote server URI where locally stored snapshot files should be uploaded.

Control Secure Logging

Select whether Secure RxLogger should be enabled or disabled.

Control Secure Logging Password

Enter the encrypted password required for Secure RxLogger.

**UI Config**

Settings

Description

Audio Config

Open to configure audio-related settings, including: Best Path Exclusions, Charging Sounds, Replication, Vibrate on Call, Mute/Vibrate State, Vibrate Icon Usage, Microphone, Mute Usage, and Vibrate Usage. Not supported on Devices TC20 and TC25.

DataWedge Config

Open to configure DataWedge parameters, including: APIs, Database File, SimulScan Template File, Automatic Database Import, and User Access to the Configuration UI. Not supported on Devices TC20 and TC25.

Display Config

Open to configure display-related behaviors, including: Force Activities Resizable, Blanking, Power, Secondary Display, Size and Rotation, and Screen Saver settings.

Event Triggered Intents

Add one or more Event-Triggered Intent elements to define automated intent actions triggered by specific events.

UI General Config

Open to configure general user interface settings, including: Feature Usage, Localization, Split-Screen Workflows, and UI Elements.

Keyboard Config

Open to configure keyboard-related settings, including: Auto Trigger, Input Method, Large Key Indicator, Use of Home and Recent Apps Keys, User Control of Large Key Indicator, Virtual Keyboard Behavior when a Physical Keyboard is Active, Double Trigger, External Keyboard Configurations, Shortcut Keys, and Num Lock Handling. Not supported on Devices TC20 and TC25.

UI Settings Config

Open to configure user settings interface options, including: Quick Settings, User Access, User Control, Settings Variant, Accessibility Options in Reduced Settings, and Network Options in Reduced Settings. Not supported on Devices TC20 and TC25. Supported from MX 4.3.

UI Touch Panel Config

Open to configure touch panel parameters, including: Touch and Hold Delay, Touch Mode, and Screen Protector settings.

ZVC Profiles

Add one or more Volume UI Profile elements to define custom volume control configurations. Supported from MX 4.4.

**Wireless And Network Config**

Settings

Description

Bluetooth Config

Open to configure Bluetooth settings, including: Discoverability, New Pairings, Pairing Rules, Blocked BLE Channels, Blocked RF-Based BLE Channels, Pairing Popup, Silent Pairing, Silent Pairing Default Method, State, Beacon, Single Pairing, BLE Scan Filter Action, Package Name, RSSI Filter Range, App Configuration Mode, App Allowlist Action, App Blocklist Action, App Config Package Name, Power Class, and Profile. Not supported on Devices TC20 and TC25. Supported from MX 5.1.

DHCP Config

Open to configure DHCP parameters, including: DHCPv6, Request V4 Options, and Send V4 Options. Supported from MX 8.1.

NFC Config

Open to configure NFC settings, including: State, General NFC behavior, and Tag handling. Not supported on Devices TC20 and TC25. Supported from MX 8.1.

Ethernet Config

Open to configure Ethernet connectivity settings, including: State, User Control of State, IP Address, Proxy, and Authentication parameters. Not supported on Devices TC20 and TC25. Supported from MX 6.2.

Host Config

Open to configure the Device's friendly name and network name. Not supported on Devices TC20 and TC25. Supported from MX 5.1.

Wireless Network Config

Open to configure wireless communication settings, including: Antenna Selection, External Antenna, Bluetooth Scanning State, GPS Power State, Location State, Network Monitor Popup, and Wi-Fi Scanning State. Not supported on Devices TC20 and TC25.

RFID Config

Open to configure RFID settings, including: Firmware Update File, Country of Operation, Channel Hopping, Channel Mask, Ukraine Region Power Mode, Query Select, Query Session, Query Target, and Transmit Power Level. Not supported on Devices TC20 and TC25.

Wireless Config

Open to configure wireless communication settings, including: Antenna Selection, External Antenna, Bluetooth Scanning State, GPS Power State, Location State, Network Monitor Popup, and Wi-Fi Scanning State. Not supported on Devices TC20 and TC25.

WLAN Config

Open to configure WLAN-related parameters, including: Auto Wakeup, Country, Network Notifications, RF Bands, State, Verbose Logging, Advanced Options, Diagnostics Options, Fine Timing Measurement (FTM), Global Proxy, Hotspot, and SecureFusion Advanced.

WWAN Config

Open to configure WWAN settings, including: APNs, Data, Device Administrator Lock, Dual SIM Dual Standby (DSDS), General Settings, and eSIM Profiles. Not supported on Devices TC20 and TC25.

* * * **Related Documentation:** - [Update Zebra with Zebra OEMConfig](https://docs.applivery.com/en/device-management/android/oem-configs/update-zebra-oemconfig/) - [Zebra Time Zone Configuration](https://docs.applivery.com/en/device-management/android/oem-configs/zebra-time-zone-configuration/) - [Update Zebra with Legacy OEMConfig](https://docs.applivery.com/en/device-management/android/oem-configs/update-zebra-legacy-oemconfig/) - [Common Policy Configurations](https://docs.applivery.com/en/device-management/android/policies/sample-policies/) --- ## Samsung Knox E-FOTA Source: https://docs.applivery.com/en/device-management/android/oem-configs/samsung-knox-efota/ Description: Configure Samsung Knox E-FOTA with Applivery to manage centralized OS updates on Samsung Devices with step-by-step instructions. TL;DR: Centrally manage Samsung device OS updates using Knox E-FOTA and Applivery by configuring a dedicated Android policy with the Knox Service Plugin. Key topics: Knox E-FOTA configuration, Applivery policy creation, Knox Service Plugin setup, Device enrollment in E-FOTA, Samsung, Knox E-FOTA, Applivery, Android, Knox Service Plugin, OEMConfig Samsung Knox E-FOTA allows enterprise IT administrators to centrally control operating system versions and security updates on Samsung Sevices, without requiring any user intervention. This capability enables organizations to validate OS updates in advance, ensure compatibility with internal applications, and deploy security patches on a controlled schedule, significantly improving device stability and security posture across the fleet. ### Configuration To begin, access the [Samsung Knox Admin Portal](https://samsungknox.com) and sign in using an administrator account with at least the **Common Admin** and **E-FOTA Admin** roles enabled. :::info This feature requires a valid **Knox Suite – Enterprise Plan license** in the Samsung Knox E-FOTA Portal. A free trial license can be issued for testing purposes using the **ACTIONS** button in the portal. ::: ![samsung knox](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/9b2d4df2-d57f-45a3-baf7-ee4f3b0b5de8.png) #### Preparing Applivery for Knox E-FOTA To enroll compatible Samsung Devices in Knox E-FOTA through Applivery, you must create a dedicated Android Policy that includes the **Samsung Knox Service Plugin** (**OEMConfig**) application. **Create a new Policy** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), [create a new Policy](https://docs.applivery.com/en/device-management/general-settings/create-policies/) from the **Policies** 1 section. This Policy should be used exclusively for Knox E-FOTA configuration. Within the Policy, go to the **Apps** 2 section and click the **\+ Add App** button 3. ![add app](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/8977cec7-2eb9-4d52-93ae-577c8d0312fb.png) **Add the Knox Service Plugin** Search for the **Knox Service Plugin** app (package name: `com.samsung.android.knox.kpu`). Set the **Install Type** to **Force Installed** to ensure the App is automatically installed on any Device associated with the Policy. **Configure the Knox Service Plugin** Once the App appears in the list, click on it to expand all the managed properties and **assign a name to the configuration profile** 4. ![knox service plugin](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/580d3f7f-9075-4570-b98b-9ce003eabc06.png) :::info By default, the Knox Service Plugin app is hidden from users when managed configuration is applied. For testing or validation purposes, visibility can be enabled by activating the **Debug** 5 option within the managed configuration. ::: #### Enabling Firmware and E-FOTA controls **Enable Device Policy Controls** Continue scrolling to the **Do Policies** section and **Enable Device policy controls** 6. ![enable device policy controls](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/da04c7ce-bb29-4c25-83c0-7ad7273e8b06.png) **Enable Firmware Controls and E-FOTA client installation & launch** Then, in the **Do Fota Update** section, activate both **Enable firmware controls** 7 and **Enable E-FOTA client installation & launch** 8. **Configure OTA Updates (Optional)** Optionally, you can control whether Devices are allowed to receive standard OTA updates outside of Knox E-FOTA by configuring the **Allow firmware update over-the-air** 9 setting. ![do fota update](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/04e58702-3d4c-4fec-a1c9-fae4f2310e10.png) **Assign the Policy** Once completed, assign this Policy to the relevant Samsung Devices using your preferred assignment method. :::info Ensure this Knox E-FOTA Policy has **a higher priority** than your regular Android Policy to avoid configuration conflicts. ::: ### Device registration and Campaign management After the Policy is applied, the Knox Service Plugin OEMConfig App is installed along with its managed configuration. This triggers the automatic installation of the **Knox E-FOTA Client**, and Devices are silently registered in the **Samsung Knox E-FOTA Portal**. ![samsung knox all devices](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/108bba6a-b713-4d61-8900-023012274a2c.png) From this point forward, E-FOTA administrators can **create and manage update campaigns per device model**, **enforce specific OS or firmware versions**, and **apply update constraints** according to organizational requirements. For additional information about Knox E-FOTA capabilities, refer to the [official Samsung documentation](https://docs.samsungknox.com/admin/knox-efota/). For detailed instructions on creating and managing campaigns, see Samsung's [Create a campaign](https://docs.samsungknox.com/admin/knox-efota/features/create-a-campaign/create-a-campaign/) documentation. --- ## Update Zebra with Legacy OEMConfig Source: https://docs.applivery.com/en/device-management/android/oem-configs/update-zebra-legacy-oemconfig/ Description: Update firmware on legacy Zebra Devices (Android 11 or earlier) using Legacy Zebra OEMConfig through Applivery MDM. TL;DR: Update legacy Zebra devices easily using Legacy Zebra OEMConfig and Applivery by following this step-by-step guide to configure firmware updates. Key topics: Legacy Zebra OEMConfig, Firmware Over-The-Air (FOTA) updates, Android device management, Applivery integration, Zebra, Android, Applivery, Amazon S3 Managing and updating **Zebra Devices running Android 11 or earlier** presents specific challenges for mobility and IT administrators. The **Legacy Zebra OEMConfig**, integrated with Applivery, enables centralized and reliable **firmware updates**, **configuration management**, and **device control**. :::warning Note that this version of the Zebra OEMConfig app requires Android 11 or lower. If your Devices run a higher Android version, use the latest [Zebra OEMConfig](https://docs.applivery.com/en/device-management/android/oem-configs/update-zebra-oemconfig/) app instead. ::: ### Getting started Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), go to any of your **Policies** 1. From the left side menu, go to **Apps** 2 and click the **\+ Add App** button 3. ![add app](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/f5d1573d-02cc-4da9-bd64-65951a5c94b3.png) Add the App **Legacy Zebra OEMConfig** (`com.zebra.oemconfig.common`) to your Policy through the **Managed Google Play iFrame**. Once the App has been added, open its managed properties and click **\+ Add element** under the **Steps** section. **Files Step** Locate the **Files Step** section and configure the fields as follows: - **Download Destination Path and File Name**: Specify the path and name of the update file (e.g., `/data/tmp/public/Android14AT_FULL_UPDATE_14-28-03.00-UG-U133-STD-ATH-04.zip`). - **Download File Source URI**: Enter the URL of the hosted update file. Ensure it’s a private hosting service that supports **direct downloads** (e.g., for Amazon S3: `https://your-bucket-name.s3.amazonaws.com/Android14AT_FULL_UPDATE_14-28-03.00-UG-U133-STD-ATH-04.zip`). ![files step](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/0bda5c98-0eaa-41d7-8b08-ff972be5acfe.png) Once configured, the Legacy Zebra OEMConfig app will automatically download the update ZIP package to the specified path. **FOTA Step** Next, locate the **FOTA Step** section and configure the fields as follows: - **LifeGuard OTA Service**: On. - **OS Upgrade File**: Specify the same path and file name as above. - **OS Upgrade Suppress Reboot**: Decide whether to prevent automatic reboot after the update. ![fota step](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/21204c8f-fd86-4c7c-af83-21f6f016ae8c.png) :::info Depending on the Device model, updating from Android 10 or earlier to Android 13 or higher may trigger an automatic factory reset. Learn more in the official [Zebra documentation](https://techdocs.zebra.com/lifeguard/a13/#migrationprocess). ::: Once these parameters are configured and the ZIP package is fully downloaded to the path specified in the **Files Step** section, the Zebra device will automatically begin the update process **silently**. You can verify this through a **silent notification** that appears in the Device’s notification panel. When the update completes, if **OS Upgrade Suppress Reboot** is set to **True**, the user must **manually restart** the Device to finalize the installation. By following the outlined steps—from configuring managed properties to defining update parameters and reboot options—you ensure a **smooth**, **reliable**, and **error-free** update process. --- ## Update Zebra with Zebra OEMConfig Source: https://docs.applivery.com/en/device-management/android/oem-configs/update-zebra-oemconfig/ Description: Update Zebra Devices remotely using Zebra OEMConfig through Applivery MDM — secure, automated firmware updates for your entire fleet. TL;DR: Update Zebra devices remotely and efficiently using Zebra OEMConfig and Applivery MDM for secure and automated firmware deployments. Key topics: Zebra OEMConfig setup, Files Config configuration, FOTA Config configuration, Remote device updates, Applivery MDM, Zebra, Zebra OEMConfig, Applivery, Android, Managed Google Play iFrame, Amazon S3 With this integration, administrators can remotely deploy and manage system and firmware updates in a **secure**, **automated**, and **controlled** way—minimizing downtime and ensuring device consistency across the fleet. :::warning Note that this version of the Zebra OEMConfig app requires **Android 11 or higher**. If your Devices run an older Android version, use the [**Legacy Zebra OEMConfig**](https://docs.applivery.com/en/device-management/android/oem-configs/update-zebra-legacy-oemconfig/) app instead. ::: ### Getting started Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), go to any of your **Policies** 1. From the left side menu, go to **Apps** 2 and click the **\+ Add App** button 3. ![add app](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/7d1537d3-432f-410b-8331-dc7a98f18f2b.png) Add the App **Zebra OEMConfig Powered by MX** (`com.zebra.oemconfig.release`) to your Policy through the **Managed Google Play iFrame**. Once the App has been added, open its managed properties and click **\+ Add element** under the **Files Config** section. **Files Config** Configure the fields as follows: - **Device Path and Name**: Specify the path and name of the update file (e.g., `/data/tmp/public/Android14AT_FULL_UPDATE_14-28-03.00-UG-U133-STD-ATH-04.zip`). - **Files Config Download Options**: - **Download Option Type**: On Server. - **Download Server URI**: Enter the URL of the hosted update file. Ensure it’s a private hosting service that supports **direct downloads** (e.g., for Amazon S3: `https://your-bucket-name.s3.amazonaws.com/Android14AT_FULL_UPDATE_14-28-03.00-UG-U133-STD-ATH-04.zip`). ![files config](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/7ef17b6f-3892-44d1-9d73-d3ff66981414.png) Once configured, the Zebra OEMConfig app will automatically download the update ZIP package to the specified path. **FOTA Config** Next, locate the **FOTA Config** section and configure the fields as follows: - **Update Mode**: File-Based Updates. - **File-Based Update Source**: Local Update File. - **FOTA Update Options**: - **File-Based Update Option Type**: Version Mismatch. - **Mismatch Version**: Enter the system version the Device will report after the update. - **File-Based Update Local Path and Name**: Specify the same path and file name as above. - **Update Over Cellular:** Choose whether updates are allowed over mobile data. - **Suppress Reboot**: Decide whether to prevent automatic reboot after the update. ![fota config](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/74a48198-e6d9-4f5b-9115-ab77f5a88a7a.png) Once these parameters are configured and the ZIP package is fully downloaded to the path specified in the **Files Config** section, the Zebra device will automatically begin the update process **silently**. You can verify this through a **silent notification** that appears in the Device’s notification panel. When the update completes, if **Suppress Reboot** is set to **True**, the user must **manually restart** the Device to finalize the installation. By following the outlined steps—from configuring managed properties to defining update parameters and reboot options—you ensure a **smooth**, **reliable**, and **error-free** update process. --- ## Zebra Time Zone Configuration Source: https://docs.applivery.com/en/device-management/android/oem-configs/zebra-time-zone-configuration/ Description: Configure the time zone and NTP server on Zebra Devices using Zebra OEMConfig or Legacy Zebra OEMConfig for accurate time synchronization. TL;DR: Learn how to configure the correct time zone and NTP server on Zebra devices using Zebra OEMConfig apps for Android 11+ and Legacy Zebra OEMConfig for older devices. Key topics: Zebra OEMConfig, Legacy Zebra OEMConfig, Time zone configuration, NTP server configuration, Android device management, Zebra, Android, NTP, Managed Google Play iFrame Sometimes, small details—like the correct time on a Device—can make a big difference in a company’s daily operations. Keeping all Devices synchronized helps prevent confusion and ensures that applications run smoothly. You can change the time zone and configure the NTP server on **Zebra Devices** using the **Zebra OEMConfig** and **Legacy Zebra OEMConfig** Apps, which allow you to apply advanced settings centrally across your Devices. This process ensures that all Devices maintain the correct time based on their location or your company’s synchronization policy, preventing mismatches in logs, communications, or critical applications. It’s important to know when and on which Devices to use each App. Depending on the Android operating system version, you’ll need to use either the Legacy or the current version of Zebra OEMConfig. The steps for configuring the time zone will vary slightly depending on which app you use. ### Legacy Zebra OEMConfig (Android 11-) For Devices running **Android 11 or earlier**, use the **Legacy Zebra OEMConfig** app to configure the time zone. Add the App to your Policy through the **Managed Google Play iFrame**. If you need help with this step, you can find more information [here](https://docs.applivery.com/en/device-management/android/oem-configs/update-zebra-legacy-oemconfig/). Once the App has been added, open its managed properties and click **\+ Add element** under the **Steps** 1 section. ![steps](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/c5b9ffc1-6ac8-485a-95c8-9ed775048d2e.png) The configuration options will now be displayed. With so many settings, scrolling through them can be time-consuming. To find the section you need more efficiently, use the search feature to locate **Clock step**. ![clock step](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/2a73ebbd-e73c-4e67-be80-d7ef80c43f0a.png) Configure the fields as follows: - **Time Mode**: Automatic. - **Manual Date**: Leave as is. - **Manual Time**: Leave as is. - **Manual UTC Date**: Leave as is. - **Manual UTC Time**: Leave as is. - **Auto NTP Server Address**: `ntp.pool.org`. - **Auto NTP Sync Interval**: Defines how often the App connects to the NTP server to update the time. Select the interval that best fits your needs. - **Time Zone Mode**: Manual. - **Zone**: Enter the appropriate time zone (e.g., `America/New_York`) - **Time Format**: Choose how the time will be displayed — **12h** or **24h**. Once the changes are saved, all Devices linked to this Policy will have the Legacy Zebra OEMConfig app installed. Based on the configuration defined in its managed properties, the App will automatically connect to the NTP server and apply the correct date and time according to the specified time zone. ### Zebra OEMConfig Powered by MX (Android 11+) For Devices running **Android 11 or higher**, use the **current version of the Zebra OEMConfig** app to configure the time zone. Add the App to your Policy through the **Managed Google Play iFrame**. If you need help with this step, you can find more information [here.](https://docs.applivery.com/en/device-management/android/oem-configs/update-zebra-oemconfig/) Once the App has been added, use the search feature to locate **Clock Config**. Configure the fields as follows: - **Time Mode**: Automatic. - **Auto NTP Server Address**: `ntp.pool.org`. - **Auto NTP Drift Interval**: Leave as is. - **Auto NTP Sync Interval**: Defines how often the App connects to the NTP server to update the time. Select the interval that best fits your needs. - **Time Zone Mode**: Manual. - **Manual Time Zone**: Enter the appropriate time zone (e.g., `America/New_York`) - **Time Format**: Choose how the time will be displayed — **12h** or **24h**. ![clock config](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/937661c8-83fb-4845-a193-8825578c6772.png) Once the changes are saved, all Devices linked to this Policy will have the Zebra OEMConfig app installed. Based on the configuration defined in its managed properties, the App will apply the date and time of the specified time zone. As you can see, properly setting up the time zone and NTP server on Zebra Devices is simple—and it ensures that all Devices stay synchronized, preventing log errors, communication issues, and failures in critical Apps. With the **Zebra OEMConfig** and **Legacy Zebra OEMConfig** Apps, this process can be managed centrally and adapted to each Device’s Android version, helping you maintain a consistent, reliable environment that aligns with your organization’s operational needs. --- ## Android Policies Source: https://docs.applivery.com/en/device-management/android/policies/ Description: Android Policies in Applivery — create and enforce security Policies, control Device settings, restrictions, and compliance requirements at scale. TL;DR: Android Policies in Applivery enable administrators to enforce security standards and restrictions across devices at scale. Key topics: Android device policies, Security policies, Device restrictions, Compliance management, Policy enforcement, Android, Applivery Android Policies in Applivery let you enforce security standards and compliance requirements across your managed Devices. You can control device settings, restrict features, require password complexity, configure kiosk mode, manage App behavior, and much more. Android Policy settings are organized by category, so you can build the right configuration for every Device group in your organization. --- ## Agent Source: https://docs.applivery.com/en/device-management/android/policies/agent/ Description: The Applivery Android Agent — features, configuration, geolocation, and how it enhances Device Management and security on Android. TL;DR: The Applivery Android MDM Agent provides background device management and a self-service portal for users to access corporate resources, enhancing device management and security. Key topics: Android MDM Agent Features, Agent Configuration, Self-Service Portal, Data Security, Geolocation Tracking, Applivery, Android, Kotlin, Google Play Store, Google Maps, SHA-256, SSL TLS 1.3, Push Notifications, Service Account ![agent overview](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/a5ca7622-6fdf-4a2c-8e1d-da165c3d7d18.png) The Applivery Android MDM Agent is an Android application deployed on managed Devices enrolled in the Applivery Dashboard. It serves two complementary purposes: 1. **Background management**: Collects and reports device telemetry (geolocation, app usage, network traffic, network signal) to the Applivery Dashboard, according to the Policies configured by the organization's IT administrator. 2. **Self-Service Portal**: Provides the Device user with a built-in interface to browse and install corporate applications, access organization bookmarks, and check the health of the management services running on their Device. The Agent is written in [Kotlin](https://kotlinlang.org/) and is **deployed at the Policy level**. It runs silently in the background while giving end users a convenient way to access resources their organization has made available to them. ### Version 2.0.0 — What's New Version 2.0.0 is a major update that introduces the **Self-Service Portal** — a completely new user-facing experience — alongside improvements to background management. #### New for end users - **Application catalog**: Browse, search, install, update, and uninstall corporate applications directly from the Device, without needing to access the Applivery Dashboard. - **App detail pages**: View full application information, including descriptions, screenshots, age ratings, version history, and device compatibility before installing. - **Bookmarks**: Quick access to URLs and web resources shared by the organization, organized by category. - **Status Dashboard**: See at a glance whether all management services are running correctly on the Device. - **Redesigned interface**: The entire user interface has been modernized with a cleaner, faster design. #### New for administrators - **Feature-level control**: Enable or disable individual Self-Service sections (Applications, Bookmarks, Status, Files, Notifications) per device or device group through managed configuration. - **Default view**: Configure which section opens first when the user launches the App. - **Real-time install tracking**: The Agent now detects when a user installs a Google Play Store application and reflects the status in real time. ### Features #### Geolocation Tracking ![agent location](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/be9fe4ef-1910-4d48-bec0-5e76cd2a36b7.png) Reports the Device's geographic location (latitude, longitude), including full street address when available. The entire list of reported locations is accessible from the **Locations** section when selecting a Device. Click any entry to see a map preview, or click **Open** to view it in Google Maps. :::warning Geolocation reporting is available for **Fully Managed** Devices and **COPE** (Company-Owned, Personally Enabled) Devices. Devices with a **Work Profile** do not have access to this feature. ::: #### App Usage Reporting ![app usage](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/022a34a1-2fda-4b39-b84d-076f4d35e3d5.png) Reports app usage time by querying foreground activity data from Android APIs. Usage analytics are displayed on a weekly basis, aggregated by package name, with the App name and category shown when available. The top 5 applications are highlighted in different colors; remaining usage time is aggregated in gray. To access usage analytics, navigate to the **Usage** section when selecting a Device, then use the week selector above the charts to navigate across periods. :::warning On **Work Profile** and **COPE** Devices, only work Apps are reported — personal Apps are not visible. On **Fully Managed** Devices, all Apps are visible. ::: #### Network Traffic Reporting ![network reporting](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/920de8d0-5a5b-4d24-ac21-15c2495960b9.png) Reports per-app incoming and outgoing network traffic in MB, queried from Android's network usage APIs. Analytics are displayed weekly, aggregated by package name, with app name and category where available. The top 5 Apps are color-coded; the remainder is aggregated in gray. To access network analytics, navigate to the **Usage** section when selecting a Device. Use the week selector to navigate across periods and the blue filters to isolate Wi-Fi or mobile traffic, or to distinguish between received and transmitted data. #### Network Signal Reporting Reports network signal strength and carrier information. This data is collected by the Network Report Agent and is viewable from the Device's detail page in the Applivery Dashboard. #### Features by Plan

Feature

Starter Plan

Advanced Plan

Geolocation tracking

Sync: every 1h · Retention: 1 week

Sync: every 15 min · Retention: 1 month

Network traffic

Sync: every 24h · Retention: 1 week

Sync: every 12h · Retention: 1 month

App usage

Sync: every 24h · Retention: 1 week

Sync: every 12h · Retention: 1 month

:::warning The Agent adheres to the sync frequencies above, but the system may prioritize other processes depending on network connection status, battery optimizations, or doze mode. ::: :::info Android includes a battery optimization system that restricts background execution. Some device manufacturers customize Android and may remove this permission or its settings screen. In those cases, there is no need to worry — the agent will still function correctly, as the restriction does not apply and the App can run in the background seamlessly. ::: ### Data Security Applivery takes data security seriously, especially for sensitive device data. The Android MDM Agent uses best-in-class encryption: - All tracking reports are encrypted at runtime using **SHA-256**. - Data in transit is protected using **SSL TLS 1.3**. - Data at rest on Applivery servers is encrypted using **SHA-256**. ### Enabling the Agent at Policy Level The Android MDM Agent is enabled at the Policy level. To configure it: **Navigate to Policies** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), go to any of your **Policies** 1. From the left side menu, go to **Agent** 2 and **enable** it 3. ![agent](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/9dcaa950-ac96-4058-8611-2186634a0cb3.png) **Choose the installation mode** - **Required for Setup**: The App is installed during the enrollment process, before the system starts up. Recommended for new Devices. - **Force Installed** (default): The App is automatically installed on Devices and cannot be removed by the user. Click **Save changes** to deploy. :::warning Once saved, the Agent will be deployed on all Devices associated with that Policy. However, **it will not start reporting until it has been opened at least once** and the required permissions have been accepted. ::: #### How to Programmatically Launch the Agent The Applivery Android Agent must be opened at least once to request the necessary permissions and begin reporting. To launch it programmatically from an enrollment workflow or another App, invoke it using an Android Intent with the following action: ``` com.applivery.mdm_agent.action.LAUNCH ``` To ensure that the Agent is available at runtime, you may need first to query system information about it, such as calling: ```kotlin val intent = Intent("com.applivery.mdm_agent.action.LAUNCH") if (packageManager.queryIntentActivities(intent, 0).isNotEmpty()) { startActivity(intent) } ``` Note that starting with Android 11, package visibility filters apply. To ensure the Agent is discoverable by `queryIntentActivities`, add the following to the calling app's manifest (replace `com.example.app` with your App's package name): ```xml ... ``` ### First Launch and Setup When the Agent launches for the first time (or after updating to v2.0.0), it goes through an initial setup process. #### Loading Screen A splash screen appears with the message _"Checking your Device configuration... please wait"_. During this time, the Agent connects to the Applivery Dashboard to retrieve the Device's managed configuration. #### Permission Requests Depending on which management features the administrator has enabled, the App may request one or more of the following permissions. Each permission is explained to the user before being requested.

Permission

When requested

Why

Location

Location tracking or network signal reporting is enabled

Reports device location to the management console.

Background location

Location tracking is enabled

Allows location reporting when the App is not in the foreground.

Phone state

Network signal reporting is enabled

Reads network signal strength and carrier information.

Usage statistics

App usage or data usage reporting is enabled

Collects which Apps are used and how much data they consume.

Notifications

Always (Android 13+)

Shows progress notifications during app installations.

Battery optimization exemption

Always

Allows background services to run reliably without being stopped by the system.

Internet

Always (automatic, no user prompt)

Communicates with Applivery servers.

If the user denies a permission, the App continues to the Self-Service Portal. Features that required the denied permission will appear with an error state in the **Status** section. :::warning If the Agent cannot find a valid managed configuration (e.g., the Device is not yet enrolled or is still syncing), it displays a message explaining that the Device is not being managed by Applivery, along with a **Retry now** button. ::: ### Self-Service Portal ![self service](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/f78fc0d5-1a6e-494c-a2fc-69c671a4e1cc.png) After setup, the user arrives at the Self-Service Portal — the main user-facing interface of the Agent. #### Layout The portal has three main elements: - **Top bar**: Shows the current section name. On the left, a menu icon opens the navigation drawer. Inside detail screens (such as an App detail page), the menu icon is replaced by a back arrow. - **Content area**: Displays the active section (Applications, Bookmarks, Status, etc.). - **Navigation drawer** — A side panel that slides in from the left. Lists all enabled sections and allows switching between them. #### Which Sections Are Visible? The sections shown in the navigation drawer depend on what the administrator has enabled via managed configuration. Only active sections appear in the menu. If no features are configured, the portal defaults to showing the **Status** section so the user always has visibility into the Device's management health. ![status section](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/34db9185-3de7-4627-b518-81e768398679.png) ### Applications The Applications section is the core feature of the Self-Service Portal. It allows users to browse, install, update, and uninstall corporate applications assigned to their Devices. The section is organized into three tabs. ![home screen](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/419d730f-4ca6-4833-a061-2f2b7cc2f469.png) #### Home Tab The Home tab is the landing view of the Applications section, providing a quick overview: - **Applications preview**: Shows up to four of the user's Apps, prioritizing those already installed. Each App displays its icon, name, category, and an action button (Open, Install, or Update). Tap **View All** to navigate to the My Apps tab. - **Feature shortcuts**: A grid of cards linking to other enabled Self-Service sections (Bookmarks, Status, etc.) for quick access without opening the navigation drawer. - **Pull to refresh**: Pull down on the screen to refresh the application list from the server. #### My Apps Tab Shows a complete list of all managed applications currently installed on the Device, plus any currently being installed. Each App displays: - Icon, name, and category. - An action button: **Open** (installed and up to date), **Update** (newer version available), or an animated progress indicator (currently installing). If no managed Apps are installed, the screen displays: _"No applications installed."_ #### Updates Tab Shows only applications that have a newer version available. The header displays a count: _"Updates pending (N)"_. Each App shows an **Update** button to start the update process. If all Apps are up to date, the screen displays: _"No updates available."_ #### App Detail Page Tapping any application opens its full detail page, which includes: - **Header**: Large app icon, application name, and publisher name. - **Compatibility warning**: If the App requires a newer Android version than the Device is running, a _"Not compatible with this Device"_ warning appears and the Install button is disabled. - **Action buttons**: Vary based on the App's current state:

App State

Available Actions

Not installed

Install

Not installed (incompatible)

Install (disabled)

Installed

Uninstall and Open

Update available

Uninstall and Update

Installing in progress

Animated loading indicator (no buttons)

- **Screenshots**: A horizontally scrollable carousel. Tapping a screenshot opens it in a full-screen viewer with swipe navigation. - **About this App**: Application description, initially truncated to three lines. Tap to expand or open a dedicated full-screen reading view. - **Information**: Metadata including Author, Category, Compatibility, Age Rating (PEGI: 3+, 7+, 12+, 16+, or 18+), and Version number. :::info When returning to a previously viewed detail page, information loads instantly from a local cache while the App checks for updates in the background. ::: #### Search The Applications section includes a search feature, accessible via the search icon in the top bar. It provides a real-time filtered list of Apps as the user types, matched against the application name (case-insensitive). Each result has an action button for quick install/open/update actions without visiting the detail page. #### How App Installation Works There are two types of applications, each installed differently: **Corporate applications (Custom Apps)**. Hosted directly on Applivery. When the user taps **Install**: 1. The App icon changes to an animated loading indicator. 2. A notification appears in the notification bar showing installation progress. 3. The application file is downloaded from the Applivery servers. 4. The system's package installer runs. 5. Once complete, the button changes to **Open**. The entire process runs in the background — the user can continue browsing while installation takes place. **Google Play Store applications**. When the user taps **Install**: 1. The Device opens the App's page in the Google Play Store. 2. The user completes the installation through the Play Store. 3. When returning to the Applivery Agent, the App automatically detects the installation status and updates in real time — no manual refresh needed. **Uninstalling applications**: Tap the **Uninstall** button on an App's detail page. A system confirmation prompt appears before the App is removed. ### Bookmarks The Bookmarks section displays URLs and web links that the organization has shared with the user — such as links to internal tools, documentation, or company portals. #### Organization Bookmarks are grouped into two categories: - **Custom**: Links configured specifically by the organization's administrator. - **Applivery**: Links provided by the Applivery Dashboard. Filter buttons at the top of the screen allow viewing one category at a time. Tapping the same filter again removes it and shows all bookmarks. Each bookmark displays an icon (if configured), name, description, and an **Open** button that opens the URL in the Device's default browser. ### Status The Status section gives the user visibility into the management Agents (background services) running on their Device. Each Agent is responsible for collecting and reporting a specific type of device information to the Applivery Dashboard. #### Agents

Agent

What it does

Location tracking

Reports the Device's geographic location.

App Usage Details

Reports on which Apps are used and for how long.

Cellular Data Usage

Reports mobile data consumption.

Network Report

Reports network signal strength and carrier info.

Download Assets

Downloads certificates and files assigned to the Device.

#### Status Indicators Each Agent is shown as a card with its icon, name, last successful run time, and a color-coded status:

Indicator

Color

Meaning

Enabled

Green

Running normally and reporting on schedule

Disabled

Gray

Turned off by the administrator for this Device

Error

Orange

A problem occurred (e.g., a required permission was denied)

If an Agent is currently running, its subtitle shows _"Running"_ instead of a timestamp. Status information updates in real time. ### Push Notifications You can send a push notification to a managed Device to communicate directly with its user — for example, to share an announcement, a reminder, or a prompt to complete an action. The notification is delivered through the Applivery Agent and appears as a standard Android notification on the Device, showing the Agent icon, the title, and the message. **Navigate to the Device** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), select the **Device** you want to notify and click the **Action** button. **Select Send push notification** From the dropdown menu, select **Send push notification**. Enter a **Title** and a **Message**, then send it. ![push notifications](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/d975c280-83ea-4451-b61d-399fd1a48544.png) #### Sending notifications through the API You can also send push notifications programmatically — for example, to trigger messages from your own workflows — using the Applivery **Send push notification** endpoint: ``` POST https://api.applivery.io/v1/organizations/ORG_ID/mdm/push-notifications/send ``` Authenticate with a [Service Account](https://docs.applivery.com/en/platform/api/service-accounts/) token in the `Authorization` header, and provide the target Device `identifier`, the `os` (`android`), the target `app` (`mdmAgent`), the `type` (`notification` for a visible alert or `silent` for a data-only message), and the `notification` `title` and `body`. See the [API reference](https://docs.applivery.com/en/api/uem/push-notifications/post-send/) for the full schema. ### Navigation and Menu #### Navigation Drawer Open the navigation drawer by tapping the menu icon (☰) in the top-left corner. The drawer contains: - A close button (✕). - The Applivery logo. - All enabled sections with their icons: Applications, Files, Bookmarks, Status, Notifications. Tapping any section switches to that view and closes the drawer. #### Back Navigation When inside a detail screen (app detail, search), the menu icon is replaced by a back arrow. Each main section maintains its own navigation history — returning to a section resumes where the user left off. #### Default View The administrator can configure which section opens by default when the App is launched. If no default is set, the first enabled section is shown. #### Debug Mode Rapidly tapping the Applivery logo in the navigation drawer multiple times opens a hidden debug screen intended for IT support, showing technical details about the Device's configuration and Agent status. ### Admin Configuration Administrators control the Self-Service Portal's behavior through the managed configuration policy in the Applivery Dashboard, which is pushed to Devices automatically. ![android self service configuration](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/01e90244-c9f9-4fed-971f-3d4447742ab4.png) #### Feature Toggles Each section of the Self-Service Portal can be independently enabled or disabled:

Feature key

Section

APPLICATIONS

Application catalog with install/update/uninstall.

BOOKMARKS

Organization bookmarks and web links.

STATUS

Agent health monitoring Dashboard.

FILES

File management.

NOTIFICATIONS

Push notification center.

For each feature, the administrator can configure: - **active**: Whether the feature appears in the navigation menu (`true` or `false`). - **defaultView**: Whether this feature is the first screen shown when the App opens (`true` or `false`). Only one feature should be set as the default view at a time. #### Application Catalog Applications shown in the Self-Service Portal are managed through the Applivery Dashboard App Management features. The Agent automatically syncs the assigned application list. Administrators control: - Which applications are visible to which Devices or groups. - Whether an App is a **corporate app** (hosted on Applivery) or a **Play Store app**. - Whether the install type is **Available** (user-initiated) or **Force Install** (mandatory). - App metadata: name, description, icon, screenshots, category, age rating, version. #### Bookmarks Bookmarks are configured through the Applivery Dashboard Resources management. They support custom bookmarks (created by the administrator) and Applivery Dashboard bookmarks. Each bookmark has a title, description, URL, and an optional icon. #### Resources Management The Agent handles downloading and installing certificates and files assigned to the Device. Certificates (such as SCEP-enrolled certificates) are automatically installed into the Device's keystore. Other file types are downloaded and stored on the Device. ### Device Compatibility The Applivery Android MDM Agent v2.0.0 supports: - **Android 7.0 (Nougat / API 24)** and higher. - Phones and tablets. - Fully Managed Devices and Work Profile Devices. The Self-Service Portal is designed for both portrait and landscape orientations, with optimized layouts for different screen sizes. :::warning Version 2.0.0 is a one-way upgrade. Once a Device is updated to v2.0.0, it cannot be downgraded to v1.x without losing local application and certificate data. ::: --- ## Configure APN Settings Source: https://docs.applivery.com/en/device-management/android/policies/apn-settings/ Description: Deploy one or more APNs to managed Android Devices with apnPolicy from an Applivery Policy, without configuring them by hand on each Device. TL;DR: You deploy an APN with the Android Policy's apnPolicy object: turn on overrideApns and declare one or more apnSettings. It requires Android 10 or later on fully managed Devices, and Android 13 or later, ENTERPRISE type only, on work profiles. Key topics: apnPolicy and overrideApns, Configuring the APN in the Policy, ApnSetting field reference, Checking on the Device, Troubleshooting, Applivery, Android, Android Management API, APN The APN (Access Point Name) is the access point the Device uses to connect to its carrier's data network. When a fleet uses corporate SIMs with a private APN (for example, to reach the company's internal network through the carrier), configuring it by hand on every Device doesn't scale. With `apnPolicy`, you declare it once in the Policy and it reaches every assigned Device, without any user action. Applivery sends the Android Policy configuration to Devices through the Android Management API (AMAPI), so the fields and requirements for `apnPolicy` are the ones Google defines in its [policy reference](https://developers.google.com/android/management/reference/rest/v1/enterprises.policies). ### Prerequisites

Requirement

Details

Device with an active SIM or eSIM

The APN only affects the carrier's mobile data connection.

Android Device enrolled in Applivery

With an Android Enterprise Policy assigned.

Fully managed

Android 10 or later. Multiple APN types are supported.

Work profile

Android 13 or later, and only APNs with the ENTERPRISE type.

APN details provided by the carrier

APN name, username and password if applicable, authentication type, MCC+MNC, proxy, etc.

:::info If the Device doesn't meet the minimum version, nothing visibly fails: the setting is discarded and the Device reports a non-compliance reason (`API_LEVEL` or `MANAGEMENT_MODE`). ::: ### How it works `apnPolicy` has two fields: - `overrideApns`: turns Policy-defined APNs on or off. Values: `OVERRIDE_APNS_UNSPECIFIED`, `OVERRIDE_APNS_DISABLED` and `OVERRIDE_APNS_ENABLED`. With `OVERRIDE_APNS_ENABLED`, the Policy's APNs can take precedence over the Device's other APNs. The behavior matches Android's `DevicePolicyManager.setOverrideApnsEnabled`. - `apnSettings`: the list of APNs. Each entry is an `ApnSetting` object. :::warning APNs in the list can't conflict with each other. Two entries conflict when they match on all of these fields: `numericOperatorId`, `apn`, `proxyAddress`, `proxyPort`, `mmsProxyAddress`, `mmsProxyPort`, `mmsc`, `mvnoType`, `protocol` and `roamingProtocol`. If there's a conflict, the Policy is rejected. ::: ### Configure an APN **Open the Policy** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), go to **Policies** 1, open the Android Policy, or [create a new one](https://docs.applivery.com/en/device-management/general-settings/create-policies/). From the left-hand menu, click the **Network** 2 section and look for the **Apn Policy** 3 configuration and set `overrideApns` to `OVERRIDE_APNS_ENABLED`. ![apn](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/4ea3c067-e3b4-4ec5-a2b2-f6fea6fe403e.png) **Add the APNs** Add one `apnSettings` entry per APN and fill in at least the required fields: `apn`, `displayName` and `apnTypes`. **Save and assign** Click **Save** and assign the Policy to the relevant Devices or groups. ### Field reference #### Required

Field

Description

apn

The APN name. The Policy is rejected if it's empty.

displayName

A friendly name for the APN. The Policy is rejected if it's empty.

apnTypes

List of usage types for the APN. Rejected if it's empty, contains APN_TYPE_UNSPECIFIED or has duplicates.

`apnTypes` values: `ENTERPRISE`, `BIP`, `CBS`, `DEFAULT`, `DUN`, `EMERGENCY`, `FOTA`, `HIPRI`, `IA`, `IMS`, `MCX`, `MMS`, `RCS`, `SUPL`, `VSIM` and `XCAP`. :::info On fully managed Devices you can combine several types. On work profiles, `ENTERPRISE` is the only type allowed. Types the Device or management mode doesn't support are ignored; if none is valid, the whole entry is ignored and `INVALID_VALUE` is reported. ::: #### Optional

Field

Description

authType

Authentication type: NONE, PAP, CHAP or PAP_OR_CHAP.

username / password

APN credentials, if the carrier requires them.

numericOperatorId

Numeric operator ID: MCC (country code) + MNC (network code).

mvnoType

MVNO match type: GID, ICCID, IMSI or SPN.

carrierId

Carrier ID. 0 means not set; negative values aren't allowed.

protocol / roamingProtocol

Connection protocol, normal and roaming: IP, IPV4V6, IPV6, NON_IP, PPP or UNSTRUCTURED.

networkTypes

Radio technologies the APN can use: EDGE, GPRS, GSM, HSDPA, HSPA, HSPAP, HSUPA, IWLAN, LTE, NR, TD_SCDMA and UMTS. No duplicates allowed.

proxyAddress / proxyPort

APN proxy. Port 0 means not set.

mmsc / mmsProxyAddress / mmsProxyPort

Multimedia messaging (MMS) parameters. The MMS proxy address is an IP or a hostname, not a URL.

mtuV4 / mtuV6

MTU size in bytes for IPv4 and IPv6. Requires Android 13 or later.

alwaysOnSetting

NOT_ALWAYS_ON or ALWAYS_ON. Whether user plane resources are activated on every CM-IDLE to CM-CONNECTED transition (3GPP TS 23.501, section 5.6.13).

### Check that it was applied 1. On the Device, open **Settings → Mobile networks → Access Point Names** (the path varies by manufacturer) and check that the APN appears with the `displayName` you defined. 2. Check that the Device has a mobile data connection with Wi-Fi turned off. 3. If the APN doesn't appear, review the Device's non-compliance reasons. ### Troubleshooting

Symptom

Likely cause

What to do

The Device reports API_LEVEL

Android lower than 10 (any mode), or mtuV4/mtuV6 used on Android lower than 13.

Update the Device or remove the fields that require Android 13.

The Device reports MANAGEMENT_MODE

Work profile on Android lower than 13, or with an apnTypes other than ENTERPRISE.

Use only ENTERPRISE on work profiles, with Android 13 or later.

INVALID_VALUE is reported

None of the apnTypes is supported by the Device or management mode.

Review the declared types.

The Policy is rejected when saving

apn, displayName or apnTypes is missing; there are duplicates in apnTypes or networkTypes; or APNs conflict.

Fix the fields and check that no two APNs share the same key values.

The APN applies but there's no data

Wrong carrier details (APN, authentication, protocol).

Confirm the parameters with the carrier and try protocol and roamingProtocol set to IPV4V6.

--- ## Check Point Harmony VPN Source: https://docs.applivery.com/en/device-management/android/policies/checkpoint-harmony-vpn/ Description: Integrate Check Point Harmony VPN with Applivery for enhanced mobile device security. Protect network traffic and ensure zero-touch deployment. TL;DR: Integrate Check Point Harmony Mobile VPN with Applivery to secure mobile devices and protect network traffic with zero-touch deployment. Key topics: Mobile Security, VPN Integration, Device Management, Check Point Harmony Mobile VPN, Applivery, Check Point Portal Integrating **Check Point Harmony Mobile VPN** within your Applivery Workspace strengthens device protection by ensuring all network traffic is securely routed through Check Point’s trusted infrastructure. The **VPN feature** adds a critical security layer to Harmony Mobile’s threat prevention capabilities, helping protect users from malicious or unsafe connections even when they’re outside corporate networks. By combining **Harmony Mobile’s Zero-touch deployment** with automated VPN configuration, organizations can deliver consistent, always-on protection for mobile Devices without requiring any manual setup from end users. ### Implementation steps **Generate the Policy Certificate in Check Point** To begin, access the [Check Point Portal](https://portal.checkpoint.com/) and open the **Policy** 1 section. Expand the **Global Policy** 2 (or the workspace policy relevant to your environment) and navigate to the **Network Protection** 3 settings. ![policy-checkpoint](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/0eccb0d4-7265-4442-b5fa-b57cb3f63994.png) Within this section, locate the **HTTPS Settings** 4 panel and generate a new **network policy certificate** 5. Be sure to save this certificate securely, as it will be required later when configuring the Policy in Applivery. Before leaving this page, it is also recommended to enable the **Use next generation ONP** 6 option to ensure the most up-to-date protection features are applied. ![https-settings](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/d1fc092c-01d9-4a95-872f-eabc45e98859.png) **Configure the Policy in Applivery** :::info If you haven’t yet integrated Check Point Harmony Mobile into your Workspace, or haven’t added the App to your Policy, you can learn how by following this [link](https://docs.applivery.com/en/device-management/integrations/security/checkpoint-harmony-mobile-integration/). ::: Once in the [**Applivery Dashboard**](https://dashboard.applivery.io), head to the **Resources** 7. From the left-hand menu, select **Certificates** 8 and use the **\+ Upload Certificate** button 9 to upload the certificate you previously downloaded from the Check Point portal. ![upload certificate](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/69b78e79-4ddf-442a-b6cd-4e8f5ac988dc.png) Next, open the Policy where you want to deploy the certificate. In the left-hand menu, go to **Resources** 10, select **\+ Add Resource** 11, and choose the certificate you previously uploaded. Finally, **save** the Policy and **deploy** the changes. ![add certificate](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/b23c02c4-3829-4b38-aed9-565ce3b07e81.png) --- ## Configure Wi-Fi Networks Source: https://docs.applivery.com/en/device-management/android/policies/configure-wifi-networks/ Description: Push predefined Wi-Fi configurations to Managed Android Devices using Applivery Policies — supports WPA-PSK, WPA-EAP, hidden SSIDs, and advanced network options. TL;DR: Use Applivery Android policies to push Wi-Fi configurations automatically to Managed Devices — define the SSID, security type, and advanced options like Auto Connect, MAC randomization, and proxy settings. Answers: How do I push a Wi-Fi configuration to Managed Android Devices? · What is openNetworkConfiguration in Android Enterprise? · How do I configure WPA-EAP Wi-Fi on Android MDM? · What is the GUID field in a Wi-Fi network policy? · How does Auto Connect work on Managed Android Devices? · What is MAC Address Randomization Mode in Android MDM? · Can I configure hidden SSIDs on Managed Android Devices? · What is a BSSID Allowlist in an Android Wi-Fi policy? Key topics: Wi-Fi policy configuration, openNetworkConfiguration, Android Enterprise network management, Applivery MDM, Android, Applivery, Android Management API, Wi-Fi Applivery lets you define Wi-Fi network configurations directly within an Android policy so that managed devices automatically receive the necessary connectivity settings — no manual setup required on each device. Configuration is based on `openNetworkConfiguration`, the standard format used by the Android Management API to declare Wi-Fi networks on managed devices. This is particularly useful in COBO/COPE deployments, kiosk-mode devices, and large-scale rollouts where minimizing user intervention is essential — devices connect to approved corporate networks automatically, from first boot. ### Prerequisites Before you start, make sure you have: - An Android device enrolled in Applivery with an Android Enterprise policy assigned. - The network SSID and its security type — for example, open, WPA-PSK, or WPA-EAP. - For 802.1X/EAP networks: the required authentication parameters and certificates, including CA certificates and, if applicable, a client certificate. :::warning If you plan to block manual Wi-Fi changes on the device, make sure at least one valid and tested network is already declared in the policy — otherwise the device may lose Wi-Fi access entirely. ::: ### Configuring a Wi-Fi network **Open the policy** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), go to any of your **Policies** or [create a new one](https://docs.applivery.com/en/device-management/general-settings/create-policies/). From the left-hand menu, select **WiFi**, then click **\+ Add WiFi network**. ![add wifi network](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/df1eea51-794f-4b1c-8170-9cc18ac48426.png) **Configure the network** Fill in the network details according to the type of corporate network you need to deploy. See the [field reference](#field-reference) below for a description of each option. ![wifi network config](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/86fdfd55-df43-4e18-86b0-309831db7cbb.png) **Save and apply** Click **Save** to apply changes, then assign the Policy to the relevant devices or groups. Applivery will push the Wi-Fi configuration automatically to all targeted devices. ### Field reference #### General - **GUID** — Unique internal identifier for the network entry within the policy. It lets Applivery and Android distinguish this Wi-Fi entry from others, even when multiple entries share the same SSID across different policies or versions. - **Name** — A friendly label visible only in the Applivery Dashboard. It does not need to match the SSID; it is for administrative purposes only (for example, "Wi-Fi office floor 3"). - **SSID** — The actual name of the Wi-Fi network that the device will see and connect to. This maps to the `SSID` field in `openNetworkConfiguration` and must match exactly what is configured on the access point, including capitalization. - **Security** — The security type of the Wi-Fi network. Applivery supports the values defined by the Android Management API: `None` (open), `WEP-PSK`, `WPA-PSK`, and `WPA-EAP`. Selecting a value enables the corresponding fields — for example, a passphrase field for WPA-PSK, or EAP parameters and certificate selectors for WPA-EAP. #### Certificate from a Certificate Provider To authenticate a WPA-EAP network with a certificate requested through SCEP: 1. Set **Security** to **WPA-EAP**. 2. In the EAP configuration, set **Outer** to **EAP-TLS**. 3. Set **Certificate Type** to **Certificate Provider**. 4. Select the Certificate Provider, then the profile. You set up providers and their profiles in [Certificate Providers](https://docs.applivery.com/en/device-management/general-settings/certificate-providers/). #### Advanced configuration - **Auto Connect** — When enabled, the device connects to this network automatically whenever it is in range, without user intervention, provided the credentials are correct. - **MAC Address Randomization Mode** — Controls whether the device uses its real hardware MAC address or a randomized one for this network. Maps to `MACAddressRandomizationMode` in the Android Management API (Android 13+). Relevant in environments with MAC-based access control or network inventory management. - **Hidden SSID** — Marks the network as hidden, meaning the access point does not broadcast the SSID name. When enabled, the device still searches for and connects to the network using the configured SSID, even if it does not appear in the visible networks list. - **BSSID Allowlist** — An optional list of BSSIDs (MAC addresses of specific access points) that the device is allowed to associate with for this SSID. Restricts connectivity to specific radios — useful when the same SSID exists across multiple locations and you only want devices to connect to a defined subset. - **Proxy Settings** — Proxy configuration applied while the device is connected to this network. Supports no proxy, manual configuration (host, port, and exclusions), or automatic configuration via PAC URL, following the `ProxySettings` field of the Android Management API. ### Best practices - Enable **Auto Connect** for networks that must be available from first boot. - Validate the configuration on a **pilot group** before rolling it out to the entire fleet. - If you plan to block manual Wi-Fi modifications, confirm the policy contains a functional and tested network before enabling that restriction. - In environments with MAC-based access control, evaluate whether to fix **MAC Address Randomization Mode** based on your network infrastructure's expected behavior. Once the Policy is applied, the device shows the network as saved or connects automatically, depending on the `AutoConnect` setting. If the network does not apply as expected, review the security type, password, SSID visibility, certificates, and EAP parameters configured in the Policy. --- ## Personal Usage Policies in COPE Source: https://docs.applivery.com/en/device-management/android/policies/cope-personal-usage/ Description: Configure Personal Usage Policies in Applivery MDM for COPE Devices to balance corporate security with employee privacy and flexibility. TL;DR: Configure Personal Usage Policies in Applivery MDM to balance corporate security and employee privacy on COPE devices. Key topics: COPE device management, Personal Usage Policies configuration, Applivery MDM features, Android MDM, Balancing security and privacy, Applivery, COPE, Android, Google Play, Bluetooth :::warning Personal Usage Policies require COPE enrollment (Work Profile on a Company-Owned Device) and are **not available on AOSP Devices**. On AOSP, the Applivery DPC runs as Device Owner across the full Device — there is no personal profile or Work Profile to configure separately. ::: Modern mobile-device management requires balancing strict corporate security with user privacy and flexibility. COPE (Corporate-Owned, Personally Enabled) Devices are designed specifically for this: the company owns and manages the Device, while employees retain a personal space that remains separate and private. Personal Usage Policies in Applivery MDM provide fine-grained control over what users can do in the personal profile of a COPE Device—without compromising compliance, security, or the protection of corporate data. These Policies let organizations clearly define which features, applications, and permissions belong to the user’s personal area, enabling a secure and productive environment that also respects employee privacy. By using these controls, IT teams can adapt each COPE Device to both corporate and personal needs, maximizing security and productivity while maintaining the personal freedom expected from modern work environments. ### How to access Personal Usage Policies Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), go to any of your **Policies** 1. From the left side menu, go to **Compliance** and scroll down to **Personal Usage Policies** 2. ![personal usage Policies](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/0d8c9f3f-c923-4574-8378-e3ea9087b404.png) ### Configuration options #### Account types with management disabled Defines which account types should not be managed by MDM. This is typically used to enforce management only for corporate accounts, while keeping personal accounts completely outside IT control. To add an account type, click **\+ Add element** and enter the account identifier. #### Bluetooth Sharing (Allowed / Disallowed) Controls whether users can share content via Bluetooth from the personal profile. Useful for allowing or restricting file exchange in the private area of the Device. #### Camera Disabled Disables the camera in the personal profile. Recommended for environments where taking photos or videos in personal mode could pose a security or confidentiality risk. #### Max Days With Work Off Controls how long the Work Profile can remain turned off on a COPE Device. **How does it work?** - The value must be at least 3 days. - Example: If set to 5, the user may disable the Work Profile for up to 5 consecutive days. - If exceeded, the system may block access, restrict usage, or force reactivation based on company Policy. - A value of 0 disables the feature completely. - Values under the minimum cause an error and are not applied. **When is it useful?** - Ensuring the Device does not remain too long without corporate controls. - Preventing users from keeping the Work Profile disabled indefinitely. - Maintaining access to corporate Apps, updates, and security requirements. - Essential for organizations handling sensitive or regulated data. #### Personal Applications Controls which Apps may be installed inside the personal profile. Each entry includes: - **Install Type**: Whether the App is allowed or blocked. - **Package Name**: The application’s identifier This allows IT to authorize safe, approved Apps while restricting unwanted or non-compliant ones. #### Personal Play Store Mode Defines the level of access the user has to Google Play in the personal space: - **Blocklist Mode**: All Apps from Google Play are allowed except those explicitly marked as **BLOCKED** in Personal Applications. Useful when you want broad freedom but still block certain categories (e.g., risky Apps, unverified messaging Apps, etc.). - **Allowlist Mode**: Only Apps explicitly marked as **AVAILABLE** in Personal Applications may be installed. Everything else is automatically blocked. This is the most restrictive setting and ideal for highly controlled environments. #### Private Space Policy (Allowed / Disallowed) Determines whether the user can create a private, independent space on the Device. Useful for fully separating personal content from corporate data. You can learn more about Private Spaces on Android Devices by following [this link.](https://docs.applivery.com/en/device-management/android/policies/private-space/) #### Screen Capture Disabled Prevents the user from taking screenshots in the personal profile. Useful when organizations want to avoid the spread or saving of sensitive information. ### Why Personal Usage Policies matter These policy controls allow IT to define exactly what is allowed or restricted within the personal area of a COPE device. This creates the ideal balance between: - **Corporate security** — protecting Apps, data, and compliance. - **Employee privacy** — giving users freedom in their personal profiles. - **Operational efficiency** — keeping Devices productive and aligned with company standards. Applivery enables granular control over accounts, app installation, camera and screenshot usage, file sharing, and how long the Work Profile can remain off—ensuring Devices remain secure while also being user-friendly. Implementing Personal Usage Policies in COPE environments leads to: - Safer and better-managed Devices. - Clear rules for employees. - Easier COPE adoption across the organization. - Greater clarity and control for IT teams. - A balanced, secure, and user-respectful mobile ecosystem. --- ## Disable USB Data Transfer Source: https://docs.applivery.com/en/device-management/android/policies/disable-usb-data-transfer/ Description: Disable USB data transfer on Android Devices with Applivery MDM to prevent unauthorized data access and enforce security Policies. TL;DR: Disable USB data transfer on Android devices via Applivery MDM to prevent data leaks and unauthorized access. Key topics: Android Device Security, Mobile Device Management, Data Leak Prevention, Applivery, Android, USB Disabling USB ports on Android Devices is an increasingly common security practice in corporate environments, particularly in industries where data protection and physical access control are critical. With MDM solutions like Applivery, organizations can restrict USB port functionality to prevent unauthorized file transfers, the use of external storage Devices, or charging from untrusted sources. This capability enhances the organization’s security posture and helps safeguard against data leaks and malware infections introduced through physical connections. ### Disabling USB Data Transfer **Navigate to Policies** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), navigate to **Policies** 1. **Select the Android Policy** Select the Android Policy where you want to perform this configuration. **Go to Network Settings** From the left-hand menu, click on the **Network** section. **Disallow USB Data Transfer** In the **Device Connectivity Management** 3 configuration, choose **DISALLOW USB DATA TRANSFER** under **USB Data Access** 4. ![disallow usb data transfer](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/4f762a43-e019-4cf5-8ad5-6a235b824d7d.png) Disabling USB ports on Android Devices adds an important layer of protection against external threats and unauthorized usage. Applied remotely and centrally, this measure ensures that corporate Devices are used strictly in line with organizational security Policies. When implemented effectively, it not only minimizes operational risks but also reinforces compliance with regulatory standards, particularly in environments where information security is paramount. ### AOSP Devices Support Disabling USB data transfer is fully supported on AOSP — same steps, no Google services required. Especially useful for rugged and industrial deployments where physical port security is a priority. --- ## Distribute Certificates Source: https://docs.applivery.com/en/device-management/android/policies/distribute-certificates/ Description: Securely issue certificates to Android devices remotely using Applivery. Enable secure access to corporate resources for your remote workforce. TL;DR: Remotely issue certificates to Android devices via Applivery policies for secure access to corporate resources, ensuring secure access for remote workers. Key topics: device management, security, certificates, android, Applivery, G Suite Certificates play a crucial role in identifying and authenticating mobile Devices, enabling secure access to corporate resources like G Suite and enterprise Wi-Fi hotspots. Some organizations require Devices to be on-premises and behind a firewall to distribute device certificates. However, as some users can no longer access corporate locations and networks, there is a need for a way to issue these certificates remotely. With this feature, organizations can ensure their users remain connected and productive, even while working remotely. :::warning This feature requires the [**Applivery MDM Agent**](https://docs.applivery.com/en/device-management/android/policies/agent/) to be enabled in the Device policy. ::: ### Adding a certificate to a Policy **Navigate to Policies** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), navigate to **Policies** 1. **Select Android Policy** Select the Android Policy where you want to add a certificate. **Add Resource** In the left-hand menu, click on the **Resources** 2 section, then click the **\+ Add Resource** button 3. **Upload Certificate** A modal view will be displayed, allowing you to select the type of file you want to add to the Policy. Select an existing certificate from the Resources section or **Upload new resource**. Certificates must be uploaded in `.p12`, `.pem`, `.der`, `.crt` or `.cer` format. :::warning Password-protected `.p12` certificates are not supported. Make sure the `.p12` file you upload has no password set. ::: **Save Changes** Once you’ve completed the necessary configurations in your Policy, **Save changes**. ![add certificate](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/577de775-40f7-474e-990d-2bce17525f75.png) --- ## Encryption Policy Source: https://docs.applivery.com/en/device-management/android/policies/encryption-policy/ Description: Configure Android device encryption in Applivery — understand encryptionPolicy values, how they affect device boot behavior, and which setting to choose for your deployment. TL;DR: encryptionPolicy controls device encryption and boot behavior on managed Android devices. ENABLED_WITHOUT_PASSWORD is recommended for most deployments as it enforces encryption while keeping the device remotely manageable. Key topics: Android Encryption Policy, File-Based Encryption (FBE), Before First Unlock (BFU), Android Device Policy, Applivery MDM Configuration, Android, Applivery, Android Management API, File-Based Encryption All Android devices enrolled in Applivery MDM have their storage encrypted by default, thanks to Android's [File-Based Encryption (FBE)](https://source.android.com/docs/security/features/encryption/file-based). The `encryptionPolicy` setting lets you define exactly how that encryption interacts with the device boot process — which has a direct impact on remote manageability. ### How Android encryption works Android uses **File-Based Encryption (FBE)**, which encrypts files individually and divides storage into two areas:

Storage type

When it's accessible

What it contains

Device Encrypted (DE)

Immediately after boot, before user authentication

System processes, Direct Boot–aware apps, Android Device Policy

Credential Encrypted (CE)

Only after the user unlocks with PIN, password, or biometrics

User data, most apps, personal files

This separation is what makes **Direct Boot** possible: the device can boot, connect to Wi-Fi, and run essential services (including MDM communication) before the user has entered their PIN. ### encryptionPolicy values The `encryptionPolicy` field in your Android policy controls whether encryption is enforced and how the device handles the boot process. #### ENCRYPTION\_POLICY\_UNSPECIFIED The value is ignored by the Android Management API — no explicit encryption requirement is set. Encryption behavior depends entirely on the device's own defaults. **This value is not recommended** for managed enterprise deployments. #### ENABLED\_WITHOUT\_PASSWORD (Recommended) Encryption is enforced, but the device **does not require the PIN at boot** to start. Under the hood, Android derives the encryption key from the device hardware at startup, making DE storage available immediately. CE storage (and user data) remains encrypted until the user authenticates. This is the standard behavior for modern Android devices and the recommended value for enterprise deployments because: - Android Device Policy starts normally after every reboot. - Remote commands (including Reset password) reach the device immediately. - Encryption is still enforced — data is fully protected against offline attacks. #### ENABLED\_WITH\_PASSWORD Encryption is enforced, **and** the device requires the user's PIN or password at boot, before the encrypted storage is decrypted. This maps to the **Secure Startup** feature on Android devices. :::warning When `ENABLED_WITH_PASSWORD` is active and a device restarts, the device enters a **Before First Unlock (BFU)** state until the user enters their PIN. In BFU state, Android Device Policy cannot start — the device appears online in Applivery but is completely unreachable for remote commands. See [Remote Commands — Reset password troubleshooting](https://docs.applivery.com/en/device-management/android/commands/remote-commands/#troubleshooting-reset-password-fails-instantly) for details on resolving this situation. ::: Use this value only if your security policy explicitly requires pre-boot authentication — for example, in regulated environments where unattended device boot is not permitted. ### Where to configure it Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), go to any of your **Policies** 1. From the left side menu, go to **Security**, and locate the **Encryption Policy** 2 setting. ![encryption policy](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/59315ba5-3fcb-42bc-a8df-5b441bad3371.png) ### Choosing the right value

Scenario

Recommended value

Standard enterprise deployment

ENABLED_WITHOUT_PASSWORD

Kiosk or unattended devices

ENABLED_WITHOUT_PASSWORD

Regulated environment requiring pre-boot PIN

ENABLED_WITH_PASSWORD (ensure physical access is always available)

Device was already in BFU and is unreachable

Recover physically, then consider switching to ENABLED_WITHOUT_PASSWORD

### Security considerations A common concern is whether `ENABLED_WITHOUT_PASSWORD` is less secure than `ENABLED_WITH_PASSWORD`. The answer depends on the threat model: - **Against offline attacks** (extracting the storage chip and reading it externally): both values provide equivalent protection through Android FBE. The DE key is derived from a hardware-bound key that cannot be extracted without the device. - **Against an attacker with physical access to a running device**: `ENABLED_WITH_PASSWORD` adds a layer by preventing the device from booting unattended, but this must be weighed against the operational risk of devices becoming permanently unmanageable if the user forgets their PIN. For most enterprise deployments, `ENABLED_WITHOUT_PASSWORD` strikes the right balance between security and operational control. --- ## Enforcement Rules Source: https://docs.applivery.com/en/device-management/android/policies/enforcement-rules/ Description: Automate Android compliance with Policy Enforcement Rules. Learn to configure rules for blocking access, remote wipe, and enforcing policies. TL;DR: Automate Android device compliance by configuring Policy Enforcement Rules in Applivery to block access or wipe devices upon policy violation. Key topics: Android Device Management, Policy Enforcement, Compliance Automation, Applivery Configuration, Applivery, Android, Google, Factory Reset Protection (FRP) In the management of enterprise Android Devices, it is essential not only to define security and usage Policies but also to ensure that these Policies are effectively enforced. **Policy Enforcement Rules** are designed to automatically detect and respond to policy violations, helping organizations maintain compliance and protect their Device fleet. The main purpose of this configuration is to provide administrators with a flexible mechanism to **automate corrective actions** when a Device falls out of compliance. Depending on the type or severity of the violation, the system can execute predefined responses—such as blocking device access, performing a remote wipe, or notifying the user—to immediately mitigate risks and restore compliance. By implementing Policy Enforcement Rules, organizations can ensure **continuous protection**, **real-time control**, and **operational efficiency** across all managed Android Devices, minimizing security gaps and reducing the need for manual intervention. ### Configuring Policy Enforcement Rules **Navigate to Policies** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), navigate to **Policies** 1. **Select the Android Policy** Select the Android Policy where you want to make this configuration. **Go to the Compliance section** Then, go to the **Compliance** section in the left-hand menu. **Add a new Policy Enforcement Rule** Locate the **Policy Enforcement Rules** 3 configuration, then click the **\+ Add element** button. ![policy enforcement rules](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/674d51a7-5e0b-4675-97fc-f17629d06b81.png) #### Block Action Defines an automatic action that restricts access to applications and data on a managed device or Work Profile when it fails to comply with the selected Policy. :::tip It is also recommended to configure the **Wipe Action** to complete the full compliance enforcement cycle. ::: - **Block After Days**: Specifies the number of days a Device or profile may remain non-compliant before the block is applied. A value of **0** applies the block immediately. If configured with a delay, access will be restricted once that period elapses. - **Block Scope**: Determines the scope of the block, typically whether it applies to the entire device or only the Work Profile. For example, selecting **WORK PROFILE** limits the block to corporate Apps and data, leaving personal content unaffected. #### Setting Name Specifies the name of the top-level policy to enforce (for example: `passwordPolicies`). This helps identify which policy governs the rule and simplifies tracking and management. #### Wipe Action Defines an automatic action that either performs a factory reset or removes the Work Profile if compliance is not restored within the specified timeframe. :::tip It is recommended to configure this action together with **Block Action**. ::: - **Preserve FRP**: Indicates whether **Factory Reset Protection (FRP)** by Google should remain enabled after a wipe. Applicable only to **Fully Managed Devices**, not work profiles. See [Factory Reset Protection (FRP)](https://docs.applivery.com/en/device-management/android/policies/factory-reset-protection/) for how it works and how to set it up. - **Wipe After Days**: Defines the number of days of non-compliance before the Device or profile is wiped. This value should be **greater than** the one set for **Block After Days**, ensuring that blocking occurs first, followed by a wipe if compliance is not reestablished. These configuration options give administrators fine-grained control over how Devices respond to policy violations. By defining specific actions, time thresholds, and enforcement scopes, each rule can be precisely aligned with the organization’s operational and security needs. Together, these settings transform compliance management into a predictable, transparent process—where administrators know exactly what will happen, when, and why. This structured approach simplifies oversight, improves consistency across Devices, and helps maintain a stable, policy-driven environment for all managed Android Devices. --- ## Factory Reset Protection (FRP) Source: https://docs.applivery.com/en/device-management/android/policies/factory-reset-protection/ Description: Control which accounts can reactivate an Android Device after a factory reset, protecting corporate Devices against theft or loss — configured through the frpAdminEmails policy field in Applivery. TL;DR: FRP stops a stolen or lost Android Device from being reactivated after a factory reset without an authorized admin account. On AMAPI-managed Devices it is not automatic — you must set the frpAdminEmails field in the Policy's Security section. Key topics: Factory Reset Protection, frpAdminEmails, preserveFrp, Compliance wipes, Android Management API, Applivery, Google accounts Factory Reset Protection (FRP) stops a stolen or lost Android Device from being reactivated after a factory reset unless someone signs in with an authorized administrator account. On Devices managed through the Android Management API (AMAPI) — like the ones Applivery administers — this protection **is not enabled automatically**: you have to set the **Frp Admin Emails** field in the Policy explicitly. ### What is Factory Reset Protection? Factory Reset Protection is an Android security feature that blocks a Device after a factory reset until someone signs in with an authorized Google account. Its goal is to discourage theft: a Device with FRP active that is reset "the hard way" — for example, from the recovery menu — becomes unusable to anyone who doesn't know the credentials of the linked account. In the consumer world, FRP turns on as soon as there's a Google account on the Device. **On Devices managed through AMAPI, this behavior is different and must be configured explicitly.** ### How FRP behaves on AMAPI-managed Devices This is the most important nuance, and the one that most often causes operational confusion. :::warning On AMAPI-managed Devices, FRP **only activates if the Policy defines** **Frp Admin Emails**. If this field is absent or empty, the Device offers no factory reset protection — even if a Google account is present. ::: Android's behavior also distinguishes **how** the reset was started: - **Reset from the Device's Settings** (the user is already signed in as owner): on many Fully Managed Devices, a reset started from Settings by the signed-in user doesn't trigger FRP the same way a "forced" reset does. Even so, protection still depends on **Frp Admin Emails** being configured correctly. - **Reset by other means** (recovery menu, remote wipe command, theft with physical extraction): if the Policy has **Frp Admin Emails** set, the Device requires the email and password of one of those accounts to finish provisioning. ### The **Frp Admin Emails** field **Frp Admin Emails** is a top-level field in the AMAPI `Policy` resource. Applivery exposes it through its Android Policies — the same mechanism other AMAPI settings not covered by a native Dashboard control (such as Network Escape Hatch Enabled or Advanced Security Overrides) use to be applied directly.

Field

Type

Description

Frp Admin Emails

array of strings

Email addresses of the Google accounts authorized to unlock the Device after a factory reset. If empty or absent, the Device does not enforce FRP.

Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), go to any of your **Policies**. From the left side menu, go to **Security**, locate **FRP Admin Emails**, and click **\+ Add element** to add each authorized account. ![frp admin emails](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/5e48d20a-c8f8-401d-8148-c01028ed79fd.png) :::tip Include **at least two** accounts in **FRP Admin Emails** — for example, a team account and a direct manager's account. This prevents a Device from becoming permanently locked if a single administrative account is no longer available. ::: #### Should I enable FRP on all my Devices? It depends on the balance between security and day-to-day operations in your organization:

Scenario

Recommendation

High-value corporate Devices at risk of theft (couriers, field sales, Devices that leave the premises)

Enable FRP with FRP Admin Emails pointing to an IT-managed team account

Devices frequently reassigned between employees or returned to IT for re-provisioning

Weigh whether FRP adds operational friction; if your offboarding process isn't well oiled, a Device can end up locked to someone no longer in the organization

Dedicated / kiosk Devices with no personal user account

Usually adds no value, since there's no end-user Google account to protect

### Preserve Frp: FRP and compliance rules (automatic wipe) When a Device is wiped automatically for policy non-compliance (through **Policy Enforcement Rules**), the **Preserve Frp** field inside the **Wipe action** configuration decides whether FRP data survives that wipe. You configure it in the **Compliance** section of your Policy, under **Policy Enforcement Rules**.

Field

Location

Type

Behavior

Preserve Frp

Policy Enforcement Rules > Wipe Action > Preserve Frp

boolean

If true, FRP data is kept after a non-compliance wipe. If omitted, the default behavior does not preserve FRP data.

:::warning **Preserve Frp** only has an effect if the Device already had **FRP Admin Emails** configured. It does not enable FRP on its own. ::: ![preserve frp](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/9293c931-64ac-48f6-9799-56418f986a09.png) For the full compliance-wipe configuration, see [Enforcement Rules](https://docs.applivery.com/en/device-management/android/policies/enforcement-rules/). ### Known limitations - **Doesn't apply to work profiles (Work Profile / COPE).** **FRP Admin Emails** operates at the full-device level ("Fully Managed" mode). - **Requires the Device to have FRP Google accounts registered before the reset.** If the Device never had an account associated through the Policy, there are no credentials to ask for. ### Troubleshooting #### A Device is locked by FRP and can't be re-provisioned **Check the authorized accounts** Confirm which accounts were in **FRP Admin Emails** on the Policy the Device had assigned before the reset. **Sign in with an authorized account** Ask a holder of one of those accounts to enter their credentials on the FRP lock screen during Device setup. **If no authorized account is available** If none of the **FRP Admin Emails** accounts are available (for example, an employee who took their access with them), you'll need to handle Device recovery directly with Google or the manufacturer. Applivery has no remote mechanism to bypass FRP once it's active. #### I need a batch of new Devices to never be protected by FRP Make sure the provisioning Policy **doesn't include** **FRP Admin Emails**, or that the array is explicitly empty. --- ## Hide the Organization Name Source: https://docs.applivery.com/en/device-management/android/policies/hide-organization-name/ Description: Stop the Managed Google Play organization name appearing on the lock screen and in Settings of your managed Android Devices. TL;DR: You can't rename the organization name shown on Devices, but you can hide it from the Policy. It applies on the next sync. Key topics: Enterprise display name, Policy visibility setting, Managed Google Play binding, Applivery, Android, Android Enterprise, Managed Google Play, Google Devices that were showing nothing suddenly display your organization's name on the lock screen and in Settings, without anyone changing a Policy. That is Google's doing: the default for the `enterpriseDisplayNameVisibility` setting is now **visible**, so any Workspace that never configured it inherits the new behavior. ### Where the name comes from It is the **enterprise display name** of your Managed Google Play organization, fixed when the Android Enterprise account was bound to Applivery. :::warning **It cannot be renamed.** The only way to change the text would be unbinding the Android Enterprise account and binding it again, which forces you to re-enroll every Device in the fleet. In practice that is not a rename, it is a migration. ::: ### Hiding it What you can do is stop it from being shown. The Policy exposes the enterprise name visibility setting, which maps to Android's `enterpriseDisplayNameVisibility`:

Value

Effect

ENTERPRISE_DISPLAY_NAME_VISIBLE

The organization name is shown on the Device. This is now Google's default.

ENTERPRISE_DISPLAY_NAME_HIDDEN

The organization name is not shown.

![enterprise display name visibility](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/2066f70a-2cbb-46c6-8399-0e7ec6631620.png) Set it to hidden in the Policy, and it applies on the Device's next sync. There is no reset, no re-enrollment, and no user interaction involved. --- ## Kiosk Mode Source: https://docs.applivery.com/en/device-management/android/policies/kiosk-mode/ Description: Configure Android Kiosk Mode in Applivery — Single App, Basic Launcher, and Advanced Launcher options for dedicated Android Devices. TL;DR: Configure Android Kiosk Mode in Applivery using Single App, Basic Launcher, or Advanced Launcher. The Advanced Launcher offers two modes — Launcher for a managed launcher experience and Kiosk for a full multi-app lockdown — with granular control over navigation, display, and system access. Key topics: Android Kiosk Mode, Applivery Kiosk Modes, Single App Configuration, Multi-App Configuration, Advanced Launcher Customization, Android, Applivery, Device Policy Controller (DPC) Kiosk Mode is one of the most commonly used features for deploying dedicated Android Devices. It allows IT administrators to lock down a Device to a single application or a curated set of Apps, preventing users from accessing anything outside of what the organization has defined — no home screen, no App drawer, no system navigation unless explicitly allowed. Applivery provides three distinct kiosk modes for Android, each designed for different use cases and levels of customization. :::warning Kiosk mode is only available on **Fully Managed** Devices. See [Android management options](https://docs.applivery.com/en/device-management/android/enrollment/manual-enrollment/#management-options) for more information on enrollment types. ::: ### Available Kiosk Modes

Mode

Apps allowed

Description

Single App

One App

Locks the Device entirely to a single application. The most restrictive mode.

Basic Launcher

Multiple Apps

Multi-app kiosk using Android's native Device Policy Controller.

Advanced Launcher

Multiple Apps

Applivery's custom launcher with two operating modes: Launcher (managed launcher without kiosk restrictions) and Kiosk (full multi-app lockdown with extended configuration options).

### Minimum Android versions The Applivery agent supports Android 7.0 (API 24) and above, but some kiosk settings need a newer release than that.

Feature

Minimum Android version

Kiosk customization settings — System Navigation, Status Bar, Device Settings, Power Button Actions and System Error Warnings

Android 9

Advanced Launcher

Android 8

:::warning **Below the minimum version, the setting is discarded silently.** The Device reports `nonComplianceReason: API_LEVEL` in its compliance checks, but nothing fails and nothing restarts — the configuration simply has no effect. Check the Android version before assuming the Policy is wrong. ::: ### Single App kiosk mode Single App kiosk mode locks the Device to one specific application. Users cannot exit the App, access the home screen, or reach any other part of the Device unless the administrator explicitly allows it. This is the go-to mode for point-of-sale terminals, self-service kiosks, digital signage, data collection Devices, and any other single-purpose deployment. **How to configure Single App kiosk mode** Single App kiosk mode is configured at the Policy level in Applivery. Go to any of your **Policies** 1 or [create a new one](https://docs.applivery.com/en/device-management/general-settings/create-policies/). From the left-hand menu, click **Kiosk**, and select the **Single App** 2 option. Choose the App to lock the Device from the dropdown 3. If no Apps are listed, go to the **Apps** section of the Policy and add at least one Force-Installed App first. ![single app](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/cdcd765f-662b-4ddd-be51-beb63b8aea4b.png) Configure the lockdown behavior options (described below). **Single App lockdown options**

Option

Description

Device Settings

Whether the Settings App is accessible while in kiosk mode.

Power button actions

Controls the behavior when the user long-presses the Power button.

Status bar

Specifies whether system info and notifications are disabled in kiosk mode.

System error warnings

Whether system error dialogs for crashed or unresponsive Apps are blocked. When blocked, the system force-stops the App as if the user selected "Close app".

System navigation

Specifies which navigation features are enabled (e.g., Home button, Overview/Recents button).

Network escape hatch

If enabled, and a network connection cannot be established at boot, the user is prompted to temporarily connect to a network to refresh the Device Policy. The temporary connection is forgotten once the Policy is refreshed.

:::warning **We strongly recommend enabling the Network Escape Hatch** in all kiosk modes. Without it, a Device that fails to connect to the network at boot — for example, because the last known network is no longer available — may become stuck and unable to receive Policy updates, especially when booting directly into a locked App. ::: **Preparing your App for Single App kiosk mode** :::warning Declaring `android.intent.category.HOME` in your App's main activity intent filter may prevent certain kiosk settings — such as system navigation restrictions or status bar control — from being applied correctly on some Devices. Test thoroughly on your target hardware before deploying. ::: ### Basic Launcher (Multi-App kiosk mode) The Basic Launcher allows administrators to define a list of allowed applications displayed in a locked home screen UI. It is built on Android's native Device Policy Controller (DPC) and provides a solid foundation for multi-app kiosk deployments without requiring additional licensing. **How to configure the Basic Launcher** Inside the Policy, go to the **Apps** section. Click **\+ Add App** and add each application you want to make available in the kiosk launcher. Key rules for App visibility in the Basic Launcher: - Only Apps set to **Force Installed** will appear in the launcher interface. - All [System Apps](https://docs.applivery.com/en/device-management/android/app-management/system-apps/) are **hidden by default** — if you need a System App visible (e.g., Phone, Camera, Chrome), you must add it explicitly. **Enable the Basic Launcher** From the left-hand menu, click **Kiosk** and select the **Basic Launcher** 4 option. Configure the lockdown behavior options (same options as Single App mode — see the table above). ![basic launcher](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/91436c94-1b10-4d35-9ba9-b6ba4a61b470.png) ### Advanced Launcher (Multi-App kiosk mode) The Advanced Launcher is Applivery's custom-built launcher for Android policies on Fully Managed devices. Unlike the Basic Launcher, it introduces two distinct operating modes — **Launcher** and **Kiosk** — that serve different deployment scenarios with different levels of restriction. To enable it, go to the **Kiosk** section and switch to the **Advanced Launcher** 5 tab. ![advanced launcher](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/60dc68a2-2205-4bf7-9474-5857231a49a7.png) #### Operating modes **Launcher** replaces Android's default launcher with Applivery's managed launcher, but does not activate a restricted kiosk mode. The device continues to function as a normal Android terminal in terms of general experience — but through Applivery's launcher layer, which enables advanced policy-driven configurations that Android's stock launcher does not support (for example, enforcing a corporate wallpaper). This mode is the right choice when you want a managed launcher experience and additional controls without locking the device to a defined set of apps. **Kiosk** activates a full multi-app kiosk: a locked screen with one or more applications available to the user, without an open launcher experience. This is the appropriate mode for dedicated devices where the device must remain restricted to a specific set of apps. In addition to the Launcher mode capabilities, Kiosk mode adds centralized control over screen navigation, power button behavior, status bar, system errors, and network recovery — the controls typical of a traditional kiosk configuration. #### General configuration These settings apply to **both Launcher and Kiosk** modes. ##### App operation mode Select the operating mode — **Launcher** or **Kiosk** — from the **App operation mode** 6 selector. This is the most important setting in the Advanced Launcher configuration: it determines whether the device runs a managed launcher without kiosk restrictions, or enters a full kiosk scenario. ![app operation mode](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/6bc624e4-07a8-43fa-8e40-d2b47f3b72c5.png) ##### Personalization Customize the visual appearance of the managed launcher: - **Wallpaper**: URL of the background image. Must point to a web-accessible host where the image is stored. - **Icon Size**: Small, Medium, or Large. - **App layout**: Organize the arrangement of apps on the screen. - **Folders**: Group apps into folders for a cleaner layout. Both fields support [dynamic variables](https://docs.applivery.com/en/device-management/general-settings/dynamic-variables/) — for example, to display the device serial number or the email address of the assigned user. **Startup app:** By tapping on a specific app in the Advanced Launcher configuration, you can mark it as the **startup app**. This causes the app to launch automatically the first time it is installed on the device — particularly useful for applications that require an initial setup or onboarding flow to run before anything else. ##### Display settings - **Keep the screen always on**: Keeps the screen permanently active, preventing it from going to sleep. ##### Settings access control The Advanced Launcher gives granular control over how — or whether — users can access the device Settings: - **Restrict access entirely**: Prevent the Settings app from opening. - **Configure the landing view**: Choose which Settings screen opens when the user taps Settings, rather than showing the full Settings menu. - **Password-protect Settings**: Require a password to access the Settings app, ensuring that only authorized users (such as technicians or store managers) can make system-level changes on the device. #### Options ##### Kiosk mode — exclusive settings :::warning **These settings only apply when the Device is genuinely in kiosk mode.** They map to Android's `kioskCustomization` block, which the system honours only while lock task mode is active — that is, with an App set to install type **Kiosk**, or with the Advanced Launcher running in **Kiosk** mode. Pinning a launcher as the Device's default HOME app is **not** the same thing. A launcher fixed through `persistentPreferredActivities` becomes the home screen but never starts lock task mode, so the whole block is discarded without any error. ::: The following settings are only available when **Kiosk** mode is selected.

Setting

Description

Device Settings

Whether the Settings app is accessible (allowed) or blocked for the user.

Power Button Actions

Controls the long-press behavior of the power button. Available keeps the power menu accessible; Blocked prevents the user from powering off or restarting the device using the power buttons.

Status Bar

Whether the status bar, notifications, and system info are visible. Options: all enabled, all disabled, or system info only.

System Error Warnings

When muted, system error dialogs (crashes or "app not responding" messages) are suppressed and the app is force-closed automatically — preventing pop-ups that break the kiosk experience.

System Navigation

Whether Home and Overview buttons are accessible. Navigation Enabled allows the user to navigate freely; Navigation Disabled removes access entirely; Home Button Only restricts to the Home button only.

##### Status bar and Settings access On Android, the status bar and the pull-down panel are the same mechanism. Turning the bar off also blocks notifications, quick settings and the other overlays that let a user escape full-screen mode — which is precisely why it exists as a kiosk control. The practical consequence: there is no way to show the status bar and hide only the shortcut into Settings. The three values below are the whole granularity available.

Value

Behavior

NOTIFICATIONS_AND_SYSTEM_INFO_ENABLED

Bar visible, pull-down panel available.

SYSTEM_INFO_ONLY

System information without notifications.

NOTIFICATIONS_AND_SYSTEM_INFO_DISABLED

Everything off. This is the default in kiosk mode.

Because disabled is the default, a Device where the panel is reachable is a Device where someone enabled it on purpose. ##### Common settings — Launcher and Kiosk **Network Escape Hatch**: If the device cannot establish a network connection at boot, the user is offered a temporary network recovery path to refresh the policy. Once the policy is applied, the temporary network is forgotten and the boot process continues normally. :::warning We strongly recommend enabling the Network Escape Hatch in all Advanced Launcher policies. Without it, a device that fails to connect at boot may become stuck and unable to receive policy updates. Note that this option may be overridden by Wi-Fi restrictions such as **Wifi Config Disabled** or **Configure Wifi = DISALLOW\_CONFIGURING\_WIFI**. ::: #### Advanced display settings In addition to the general display setting above, the Advanced Launcher exposes more detailed controls over brightness, timeout, and power behavior. These settings allow fine-tuning the operational behavior of the device in both modes.

Setting

Description

Screen Brightness

Brightness mode: User choice, Automatic, or Fixed.

Screen Timeout

Whether the timeout duration is left to the user (User choice) or enforced by the policy.

Maximum Time to Lock

Maximum inactivity period before the device locks, with a configurable value and unit.

Stay On Plugged Modes

Which power sources keep the screen active: AC Charger, USB Port, and/or Wireless. Useful for fixed kiosks or always-on terminals.

The launcher interface also supports a customizable **Header** and **Footer**, configurable by tapping the corresponding area in the preview: - **Header**: Text displayed at the top of the launcher or kiosk interface. - **Footer**: Text displayed at the bottom of the launcher or kiosk interface. Both support [dynamic variables](https://docs.applivery.com/en/device-management/general-settings/dynamic-variables/) — for example, device name or user email — which is particularly useful for shared devices deployed across multiple locations. ### Choosing the right kiosk mode

Deployment scenario

Recommended mode

Point-of-sale terminal with a single POS app

Single App

Self-service kiosk or information panel

Single App

Data collection device (one field app)

Single App

Shared device with multiple approved work Apps

Basic Launcher

Managed device needing a corporate launcher with policy controls, without full kiosk lockdown

Advanced Launcher — Launcher mode

Retail device with branded experience and corporate tools

Advanced Launcher — Kiosk mode

Digital signage with a screen-always-on requirement

Advanced Launcher — Kiosk mode

Shared device requiring per-location identification

Advanced Launcher — Kiosk mode (with header/footer dynamic variables)

Kiosk requiring technician-only Settings access

Advanced Launcher — Kiosk mode (with password-protected Settings)

### AOSP Devices Support On AOSP Devices, kiosk mode is supported through both **Single App kiosk** and the **Advanced Launcher**. The **Basic Launcher** is not available on AOSP — it depends on Android's native Device Policy Controller (DPC) infrastructure that AOSP Devices do not have. #### Advanced Launcher on AOSP The Advanced Launcher works on AOSP Devices exactly as it does on Fully Managed (AMAPI) Devices — no limitations. Both operating modes (**Launcher** and **Kiosk**) are available, along with every configuration option described in the [Advanced Launcher](#advanced-launcher-multi-app-kiosk-mode) section above, including personalization, settings access control, advanced display settings, and the Network Escape Hatch. You configure it in exactly the same way, from the **Kiosk** section of the Policy. #### Single App kiosk on AOSP To set up Single App kiosk on an AOSP Device, add the target App to the Policy with **Install Type = Kiosk** (only one App per Policy can have this install type), then open the **Kiosk** section and configure:

Setting

Description

Power button

Allow, disable, or single-press to turn off screen.

System error warnings

Show or hide system error dialogs.

System navigation

ENABLED, DISABLED, or HOME_BUTTON_ONLY.

Status bar

Show or hide the status bar.

Device settings

Allow or block access to Settings.

Network escape hatch

Prompt the user to temporarily connect to a network if the Device cannot reach the Applivery backend at boot.

:::warning **Enable the Network Escape Hatch on every AOSP kiosk Policy.** Without it, a Device that fails to connect at boot may become unreachable and require a factory reset to recover. ::: --- ## Location Management Source: https://docs.applivery.com/en/device-management/android/policies/location-management/ Description: Control location on Android Devices with Applivery — the system-level location service (locationMode) and per-app location permissions, and how each depends on the management mode. TL;DR: Applivery controls location at two levels: system-wide (locationMode, any Device) and per-app (Permission Grants). You can pre-grant location silently on Fully Managed and Dedicated Devices, but not on COPE or Work Profile (BYOD), where Android requires the user to approve it. Key topics: System-level location control, Per-app location permissions, Management-mode differences, Location reporting, Android, Applivery, Android Management API, COPE, Work Profile How much control you have over location on Android isn't the same on every Device: it depends on whether the Device is Fully Managed / Dedicated or has a work profile (COPE or BYOD). Applivery gives you two levels of control — the system location service and per-app location permissions — and the second behaves differently depending on the mode. ### System-level location control Regardless of the management mode, you can control whether the system location service is active with the **Location Mode** field. Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), go to any of your **Policies**. Open **All Properties** and search for the **Location Mode** configuration. It has three possible values:

Value

What it does

LOCATION_USER_CHOICE

Location isn't restricted on the Device. Nothing specific is enforced — the user decides.

LOCATION_ENFORCED

Forces location on.

LOCATION_DISABLED

Forces location off.

:::warning On Android 11 and later, work profiles on corporate-owned Devices (COPE) **can't directly force** location on or off at the device level. If you set `LOCATION_ENFORCED` or `LOCATION_DISABLED` in that scenario, Applivery reports a `NonComplianceDetail` with reason `USER_ACTION`, and compliance is only restored once the user changes the location setting manually from the Device's Settings. In practice, on COPE these two values act more as a compliance signal — the Device is flagged non-compliant until the user acts — than as a silent, immediate enforcement. ::: ![location mode](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/684327c1-1309-4627-b585-eeb24fc37cce.png) A separate field, **Share Location Disabled**, specifically controls whether location sharing is turned off. It's a different setting from Location Mode — closer to what Applivery's Feature List calls _Location sharing management_ (preventing work-profile apps from sharing location) — and shouldn't be confused with the system switch. ### Per-app location permission: Permission Grants Applivery manages app permissions — location included — from **Policies → Apps**. Once in a Policy, open **Apps** from the left-hand menu and select the app from your installed apps. If the app you want to manage isn't installed yet, install it first through any of Applivery's methods, then select it. This opens the app's Managed Properties, including a **Permissions** section with two controls: - **Default Permission Policy**: a global rule (Prompt / Grant / Deny) for every permission the app requests. ![default permission policy](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/d7bba615-df3c-49aa-a55c-2c2387a0b0b0.png) - **Permission Grants**: per-permission rules. For location, add an item, choose the **Location** permission in the dropdown, and set its policy to **Grant** (granted automatically), **Deny** (denied automatically), or **Prompt** (the user decides). ![permission grant](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/870151dd-85c6-4e54-ba74-ac84e490bb2a.png) This applies to apps with `targetSdkVersion` 23 or higher, and works the same on AOSP Devices. #### Fully Managed and Dedicated Devices On fully corporate Devices (no separate personal profile), a Permission Grant set to **Grant** grants the location permission without the user seeing any dialog. It's the usual approach for: - Fleet-tracking apps on logistics Devices. - Field-service apps on dedicated Devices. - Point-of-sale or delivery Devices that need location to operate. #### COPE and Work Profile (BYOD) :::warning On COPE and Work Profile (BYOD), `ACCESS_FINE_LOCATION` and `ACCESS_COARSE_LOCATION` **can't be pre-granted or blocked** inside the work profile. This is a technical limitation of the Android platform, not a best-practice recommendation — the user always has to approve the permission manually. ::: This is part of a wider pattern: on COPE, any permission, restriction, or setting applied by policy only affects the work profile, never the personal profile — and certain sensitive permissions (location, camera, microphone) can't be pre-granted even within the work profile itself. See [COPE permission limits](https://docs.applivery.com/en/device-management/android/cope-permission-limits/) for the full picture. So, for COPE and BYOD, inform users clearly about which work-profile apps access their location and why, rather than trying to force a silent grant the platform won't allow anyway. ### Location reporting to Applivery Beyond the app's own permission, Applivery showing a Device's last known location in the console depends on two things: the Applivery agent having the location permission granted, and the system location service not being disabled. This feeds the location tab in the Device detail — useful for locating lost equipment or checking that field Devices are operating in the expected area. Applivery shows the **last known location**, not continuous real-time tracking. Continuous tracking would require a dedicated tracking app. ### Recommendations by use case

Use case

Recommendation

Logistics fleets or field workers (Fully Managed / Dedicated)

Grant the location permission via Permission Grants (Grant). Enforce the system service with LOCATION_ENFORCED if it must always be on.

BYOD or corporate COPE fleets

Don't try to pre-grant the permission — the platform won't allow it in the work profile. Inform users which apps access their location and why.

Kiosk-mode Devices

If the use case doesn't need location, turn the system service off to save battery.

--- ## Lock Screen with Keyguard Source: https://docs.applivery.com/en/device-management/android/policies/lock-screen-keyguard/ Description: Secure Android devices by managing Keyguard features. Customize lock screen settings, disable features, and enforce security policies with Applivery. TL;DR: Applivery enables administrators to manage Android Keyguard features, customizing lock screen security and enforcing policies for enhanced device protection. Key topics: Android Keyguard management, Lock screen security configuration, Applivery MDM features, Disabling Keyguard functionalities, Android security best practices, Android, Keyguard, Applivery, Android 6, Android 7, Android 14, IT administrators Android Devices come equipped with powerful security features designed to protect user data and privacy. Chief among these is the **keyguard**, or lock screen, which appears before accessing the Device’s home screen or Apps and serves as the first line of defense against unauthorized access. Keyguard enforces secure authentication through PIN, password, pattern, or biometrics—like fingerprint or facial recognition—while also offering additional features such as notification display, camera shortcuts, and media controls directly on the lock screen. Managing **Android Keyguard** and **Lock Screen** features allows IT admins to define which functions remain accessible before user authentication, enforce organizational security Policies, and create a seamless user experience. With Applivery, admins can centrally configure lock screen behavior, customize which features are enabled, and ensure compliance across the Device fleet, helping balance convenience and robust Device protection. ### Customizing Keyguard behavior Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), go to any of your **Policies** 1. From the left side menu, go to **Restrictions** and locate the **Apps** section. ![keyguard disabled features](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/02901587-f1e4-4c83-bc19-a6936151cb98.png) Locate the **Keyguard Disabled Features** 2 and click on **\+ Add element** to expand all the configuration fields: - **Camera**: Disables the camera on secure keyguard screens, preventing access even if the lock screen normally allows it (e.g., the camera widget won’t be accessible). - **Notifications**: Hides all notifications on secure keyguard screens. When enabled, no notifications—regardless of content—will appear. - **Unredacted notifications**: Hides only sensitive or “unredacted” content on secure keyguard screens. The notification itself remains visible, but its details are concealed. - **Trust agents**: Ignores trust agents that normally keep the Device unlocked in certain conditions (e.g., when paired with a trusted smartwatch). When disabled, the Device always locks regardless of active trust agents. - **Disable fingerprint**: Prevents fingerprint authentication on the keyguard screen. Users must unlock using a PIN, password, or pattern. - **Disable remote input**: On Android 6 and earlier, disables text entry in notifications on secure keyguard screens. Has no effect on Android 7 or later. - **Face**: Disables facial recognition authentication on secure keyguard screens. - **Iris**: Disables iris authentication on secure keyguard screens, preventing unlocking via iris scanner. - **Biometrics**: Disables all biometric authentication (fingerprint, face, iris) on secure keyguard screens. This is a broader option than individual biometric controls. - **Shortcuts**: On Android 14 and later, disables all lock screen shortcuts, preventing quick access to features like the camera or flashlight. - **All features**: Deactivates all current and future keyguard features and customizations at once (e.g., camera, notifications, biometrics). Ideal for environments requiring strict control, such as kiosks, where users should only access the designated application. Managing Keyguard features on Android Devices is essential for controlling both security and user experience. By disabling specific features like biometric authentication, notifications, or shortcuts, you can tailor the Device’s behavior to meet specific needs, whether that’s enhancing security in a corporate environment or optimizing a Device for use as a digital kiosk. Understanding these functionalities allows Device administrators and App developers to implement robust security Policies and ensure that users can only access the features they need. Ultimately, a well-configured keyguard not only protects the Device from unauthorized access but also contributes to a more secure and controllable Android ecosystem. With the right tools and knowledge, the keyguard evolves from a simple lock screen into a powerful tool for Device security management. ### Controlling when the Device locks Keyguard Disabled Features control **what** is available on the lock screen. To control **when** the Device locks after a period of inactivity, you need two different settings. Both are available in any Android Policy. Go to your Policy and open the **All Properties** section from the left side menu: - **Screen Timeout**: controls how long the Device stays idle before the screen turns off. To enforce a value instead of leaving it to the user, set the **Screen Timeout Mode** to *enforced*. If you leave it as *user choice*, the user picks the value and Screen Timeout must not be set. - **Maximum Time to Lock**: the maximum idle time before the system locks the Device. A value of `0` means there is no restriction. To enforce a requirement such as *"the Device must lock after 90 seconds of inactivity"*, set **both**: one turns the screen off, the other is the ceiling after which the system forces the lock. :::warning **Screen Timeout must not be greater than Maximum Time to Lock.** If it is, Android sets the screen timeout to the Maximum Time to Lock value and reports the Device as non-compliant, with an `INVALID_VALUE` reason and the specific reason `SCREEN_TIMEOUT_GREATER_THAN_MAXIMUM_TIME_TO_LOCK`. Screen Timeout must also be greater than 0, or the Policy is rejected. ::: :::info **Each Device model has its own lower limit for Screen Timeout.** If you configure a value below it, Android silently raises it to that limit. Google does not publish these limits and they vary across Devices, so if you need a short timeout — under a minute — test it on one Device of each model in your fleet before rolling it out. ::: **Version requirements:** Screen Timeout requires **Android 9 or later** on fully managed Devices — on earlier versions the Device reports a non-compliance detail with reason `API_LEVEL`. On Work Profiles on company-owned Devices it requires **Android 15 or later**. Maximum Time to Lock has no version restriction. ### AOSP Devices Support All Keyguard Disabled Features work the same on AOSP — same options, same steps. The key difference is scope: because the Applivery DPC runs as Device Owner, restrictions apply to the entire Device lock screen rather than just a Work Profile. There is no separate work challenge keyguard on AOSP. --- ## Manage Credentials Source: https://docs.applivery.com/en/device-management/android/policies/manage-credentials/ Description: Control which Apps can act as a credential manager (passwords, passkeys and autofill) on Android Devices managed with Applivery. TL;DR: Credential Provider Policy Default (All Properties) blocks every credential manager with DISALLOWED or restricts none with ALLOWED. With DISALLOWED, allow specific Apps with Credential Provider Policy = Allowed in their properties. Requires Android 15 or later. Key topics: Credential Provider Policy Default, Per-App Credential Provider Policy, Credential manager allowlist, Work profile, Troubleshooting, Applivery, Android, Android Management API, Android Device Policy, Managed Google Play A **credential manager** (or credential provider) is the App that stores and fills in passwords, passkeys and other sign-in data on the Device. Users pick theirs in **Settings → Passwords, passkeys & accounts → Preferred service** (the exact name varies by manufacturer). With Applivery, you decide which of those services they can turn on. The **Credential Provider Policy Default** setting, in the Android Policy's **All Properties**, defines what happens by default: `DISALLOWED` blocks every manager and `ALLOWED` restricts none. With `DISALLOWED`, you can allow specific Apps by setting **Credential Provider Policy** to **Allowed** in each App's properties within the Policy. ### Before you start - The Device must run **Android 15 or later**. On earlier versions, the setting isn't guaranteed to apply. - You configure the setting in any Android Policy in the Applivery Dashboard, and it applies to the Devices that Policy is assigned to. - To allow a specific manager, the App must be **added to the Policy** (**Apps** section). For a third-party App, the usual approach is to distribute it as a force install from Managed Google Play. :::info This Policy decides **which managers the user can turn on**; it doesn't set password or screen lock rules. For those, see [Password Policies](https://docs.applivery.com/en/device-management/android/policies/password-policy/) and [Lock Screen with Keyguard](https://docs.applivery.com/en/device-management/android/policies/lock-screen-keyguard/). ::: ### How the two settings combine

You want to…

Credential Provider Policy Default

Credential Provider Policy (per App)

Block every credential manager

DISALLOWED

Don't allow any App (leave it on Unspecified)

Allow only the managers you approve

DISALLOWED

Allowed on each approved App

Not restrict credential managers

ALLOWED

No App needs configuring (Apps on Unspecified can act as a manager)

Default setting values: - `DISALLOWED`: Apps whose _Credential Provider Policy_ isn't specified **can't** act as a credential manager. - `ALLOWED`: Apps whose _Credential Provider Policy_ isn't specified **can** act as a credential manager. Per-App setting values: - `Unspecified`: the App follows the Policy's default setting. - `Allowed`: the App can act as a credential manager. :::warning The **Credential Provider Policy Default** selector also shows the **DISALLOWED EXCEPT SYSTEM** value, meant to block every manager except the ones preinstalled by the manufacturer. With this value, the Android Management API behaves incorrectly with system Apps. It's a Google issue, pending a fix on their side. Even though it still appears in the interface, avoid it until it's fixed. To allow only the managers you approve, use **DISALLOWED** and allow each App with **Allowed**. ::: ### Configure the default behavior **Open the Policy** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), go to **Policies** 1 and open an Android Policy. In the left-hand menu, open **All Properties** 2 and type `credential` in the search box. **Choose the default value** In **Credential Provider Policy Default** 3, select `DISALLOWED` to block every manager or `ALLOWED` to leave them unrestricted. ![credentials](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/3709a198-6fb2-41f4-87b5-dd19f30fb423.png) :::info Next to this setting you'll see **Credentials Config Disabled**, which controls whether the user can configure user credentials on the Device. It's a different setting and doesn't affect which password managers they can turn on. ::: **Save and deploy** Click **Save changes** on the Policy card. In the **Save policy** dialog, review the number of affected Devices and the changes, and click **Save & Deploy**. You'll see the _Saved successfully!_ message. ### Allow a credential manager from the App properties Use this procedure when the default setting is `DISALLOWED` and you want users to be able to use one or more specific managers. You allow them App by App, in the same panel where you configure [Managed App Properties](https://docs.applivery.com/en/device-management/android/app-management/managed-apps-properties/). First, **Credential Provider Policy Default** must be set to `DISALLOWED` and saved, as in the previous section. **Open the Policy's Apps** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), go to **Policies**, open the Android Policy you'll assign the manager to, and select **Apps** in the left-hand menu. **Add the manager if it's not listed** If the manager isn't in the list: 1. Click **\+ Add App**. The **Managed Google Play** iframe opens. 2. Search for the App (if it's public) and approve it. If it's a private App, upload it as explained in [Distribute Private Apps Using Managed Google Play](https://docs.applivery.com/en/device-management/android/app-management/private-app-managed-google-play/). 3. Set the **install type**. For a corporate manager, the usual choice is **Force installed**: it installs on its own and the user can't remove it. You'll find every type in [Forced Install Apps](https://docs.applivery.com/en/device-management/android/app-management/forced-install-apps/). **Allow the App** Click the App in the list to open the **side panel** with its configurable properties. Scroll to the bottom and find **Credential Provider Policy**, which shows as _Empty_ until you configure it. Open the dropdown and choose **Allowed** ("App is allowed to act as a credential provider"). The other option, **Unspecified**, lets the App follow the Policy's default setting. ![credential provider policy](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ffcdcebe-e6b9-4e61-b6f2-fb992e234e26.png) **Save and deploy** Close the side panel and click **Save changes** on the Policy card. In the **Save policy** dialog, review the affected Devices and click **Save & Deploy**. You'll see the _Saved successfully!_ message. Repeat **Allow the App** and **Save and deploy** for each manager you want to allow. The allowlist is the set of Apps with **Allowed** in the Policy. **Check the result** On the Device, open **Settings → Passwords, passkeys & accounts → Preferred service**. The allowed manager should be selectable, and the rest should appear disabled. :::info The App's **Credential Provider Policy** field only takes effect if the App is included in the Policy and assigned to the Device. If the App isn't in the Policy, the user can't use it as a credential manager when the default setting is `DISALLOWED`. ::: ### What the user sees on the Device Users manage their service in **Settings → Passwords, passkeys & accounts → Preferred service**.

Configuration

Behavior on the Device

DISALLOWED, no App allowed

Services appear disabled and can't be turned on; the system shows that the option is blocked by the work policy.

DISALLOWED + one App with Allowed

That App can be selected as the preferred service; the rest stay disabled. When the user picks it, Android asks them to confirm the change of service.

ALLOWED

The Policy doesn't block managers: Apps left unspecified can act as a credential manager.

:::info Changes can take a few moments to reach the Device. If you don't see the effect, check that the Policy shows as applied in the Device details and reopen the **Preferred service** screen. ::: ### Devices with a work profile You can use this Policy on fully managed, dedicated, and work profile Devices (both personally owned and corporate). :::warning On Devices with a **work profile**, the Policy only applies to the **work profile**. The user's personal space isn't affected, and their personal credential managers keep working normally. ::: ### Troubleshooting #### The Device shows "The policy is not supported by the version of Android Device Policy on this device" The message appears in the Device details under **Compliance checks**, for the `credentialProviderPolicyDefault` field. Check that the Device runs Android 15 or later and that Android Device Policy is up to date. If the message persists, contact Applivery support with the Device model, the Android version, and the Android Device Policy version. #### The user can still turn on a manager that should be blocked Check that the Policy with the setting is assigned to that Device and that you clicked **Save & Deploy**. Also check that the default setting is `DISALLOWED` (not `ALLOWED`) and that the manager doesn't have `Allowed` in its App properties. #### I allowed a manager with Allowed, and the user can't select it Check that the App is included in the Policy, that it's installed on the Device, that you saved and deployed the Policy after changing the **Credential Provider Policy** field, and that the Device runs Android 15 or later. #### I selected DISALLOWED EXCEPT SYSTEM and can't turn on the preinstalled manager The issue is in Google's API with system Apps, and it's pending a fix on their side. Use `DISALLOWED` and allow the manager you want with `Allowed` in the App properties. #### I can't find the setting in the Policy Open **All Properties** and search for `credential`. The default setting is there; the per-App setting is in each App's properties panel under **Apps**. --- ## Manage OS Updates Source: https://docs.applivery.com/en/device-management/android/policies/manage-os-updates/ Description: Manage Android OS updates on managed Devices with Applivery — automate deployments, schedule updates, and configure freeze periods. TL;DR: Manage and automate Android OS updates on managed devices with Applivery using system update policies and freeze periods for enhanced security and stability. Key topics: Android OS update management, Applivery system update policies, Freeze period configuration, Automated update deployment, Device security, Android, Applivery, OTA (Over-the-Air) Keeping the operating system (OS) of an Android device up to date is one of the most important practices to ensure its **security and stability**. OS updates not only introduce new features and performance improvements, but also include critical security patches to protect Devices from emerging vulnerabilities and cyber threats. Ignoring these updates can leave Devices exposed to significant risks, compromising both user data and system integrity. For companies managing a fleet of Devices, whether in a kiosk environment, point of sale, or employee use, manually updating the OS is unfeasible. This document will guide you through the necessary steps to control and automate the deployment of these updates. With Applivery, you can ensure that your Devices always run on the most recent and secure OS versions, maintaining business continuity and strong protection without the burden of individual management. ### Configure a system update policy Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), go to any of your **Policies** 1. From the left side menu, go to **Restrictions** 2, select the **System** section, and locate the **System Update** 3 configuration. ![system updates](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/4136e6ef-699b-490a-9986-b419bb7569c6.png) #### Update types This is the main configuration that defines how OS updates are handled: - **UNSPECIFIED**: Follows the Device’s default update behavior, which usually requires the user to accept and trigger the update manually. - **AUTOMATIC**: Updates are installed automatically as soon as a new version becomes available. This option is ideal for environments that need to stay up to date with the latest features and security patches immediately. - **WINDOWED**: Updates are installed automatically within a daily maintenance window that you define. This option is highly recommended for kiosk Devices, since updates will occur outside of business hours. It also allows Play Store Apps to update within this same window. If an App is configured with the **HIGH PRIORITY** update mode, it will ignore the window and update immediately. - **POSTPONE**: Updates are automatically postponed for up to **30 days**. This Policy does not affect critical security updates, which will always be deployed immediately. #### End and Start Minutes These settings only apply if the **update type** is set to **WINDOWED**. They allow you to define the daily maintenance window in minutes, starting from midnight. - **Start Minutes**: Defines the start time of the maintenance window (e.g., 120 for 2:00 AM). - **End Minutes**: Defines the end time of the maintenance window (e.g., 300 for 5:00 AM). #### Freeze Periods **Freeze Periods** are a key feature for device admins who require strict control over operating system updates. They allow you to postpone Android OS OTA (Over-the-Air) updates for a recurring period each year. This is extremely useful to prevent Devices from updating during critical business times, such as peak sales seasons, major events, or periods of high operational demand. To add them to the Policy, simply click on **\+ Add element** to expand all the configuration fields. ##### How does it work? - **Period Definition**: You can define a start date and an end date for the freeze period. - **Behavior**: When a Device is within a freeze period, all system updates (including security patches) are blocked and not installed. The Device will return to its normal update policy once the freeze period ends. - **Configuration**: To set it up, you must specify the start and end day, month, and optionally the year. A freeze period must last a minimum of **60 days**. Within the **Freeze Periods** section, each freeze period you add has two main subsections: **Start Date** and **End Date**. Each of these subsections contains the following configuration fields, allowing you to precisely define the time frame during which updates will be postponed: - **Day**: Enter a number from 1 to 31 representing the day of the month when the freeze period starts or ends. - **Month**: Enter a number from 1 to 12 representing the month when the freeze period starts or ends. - **Year**: Enter a number from 1 to 9999 representing the year. If you leave the **Year** field blank (or set it to 0), the freeze period will be considered **recurring annually**. This means that the dates you define (day and month) will apply every year, automatically postponing OS updates during that same time frame. This is the most common way to use freeze periods for recurring events, such as the holiday season or summer vacations. ##### Practical example If a store is preparing for the holiday season and doesn’t want OS updates to interrupt the operation of its point-of-sale Devices, it can set a freeze period from November 1st to December 31st. During this time, no device will update automatically. Using **Freeze Periods** gives you the assurance that your Devices will maintain a stable OS version during the most critical times, ensuring business continuity without unexpected interruptions. Managing operating system updates is a critical component of Android device administration, as it directly impacts the **security**, **stability**, and **performance** of an entire fleet. As we have explored, a platform like Applivery provides the necessary tools to turn a complex and potentially risky process into a controlled and automated workflow. By configuring update modes (**AUTOMATIC**, **WINDOWED**, **POSTPONE**) and using **Freeze Periods**, admins can design a strategy that perfectly fits their organization’s operational needs. This proactive approach not only protects Devices from vulnerabilities but also minimizes unexpected interruptions, ensuring smooth business operations even during the most critical periods. In short, strategic OS update management is key to maintaining a robust and reliable Android ecosystem in the long term. --- ## Password Policies Source: https://docs.applivery.com/en/device-management/android/policies/password-policy/ Description: Configure Android Password Policies in Applivery — enforce strong passwords, set expiration rules, and secure managed Devices. TL;DR: Configure robust Android password policies with Applivery to enhance device security, enforce compliance, and protect organizational data. Key topics: Android password policy configuration, Applivery device management, Mobile device security best practices, Password complexity and expiration settings, Android, Applivery, MDM, PIN, Password Quality, Password Scope When managing Android Devices with Applivery, one of the most important aspects is ensuring they’re protected with a strong password. It’s not just about setting any passcode, but about enforcing minimum rules to guarantee a decent level of security across all Devices. With Applivery, you can easily configure these requirements remotely, making sure that all Devices comply with your organization’s security Policies without hassle. ### Configure Android Password Policies for enhanced security **Navigate to Policies** Once in the [Applivery Dashboard,](https://dashboard.applivery.io/) navigate to **Policies** 1. **Select Android Policy** Select the Android Policy where you want to enforce password security. **Access Security settings** In the left-hand menu, select **Security**. **Add Password Policy** Click the **\+ Add Password policy** 2 button. A modal will appear asking you to choose the type of password requirement: **Password Complexity** or **Password Quality**. ![add password policy](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/9c1a18d3-1180-4b6c-817f-fbbd182506c9.png) Android's API has two concepts for password policies: - **Password Complexity** — The newer, simplified approach introduced in Android 12. - **Password Quality** — The legacy approach, which allows a more detailed configuration. For backwards compatibility, when a Complexity configuration is sent to the Android Management API (AMAPI), it also requires the equivalent legacy Quality configuration to be sent alongside it. These are two ways of expressing the same requirement, but the API needs both. ![password strenght](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/70e57d8e-2875-4748-b19b-7e05fdf8c9e5.png) :::info If no legacy quality policy is defined for the same scope, a compatible legacy equivalent will be automatically generated. This ensures compatibility with older Android versions. ::: #### Password Complexity Available on Android 12 and above, with three predefined levels: - **Low**: Pattern or PIN with repeating (4444) or ordered (1234, 4321, 2468) sequences allowed. - **Medium**: PIN with no repeating or ordered sequences; alphabetic or alphanumeric password with a minimum length of 4 characters. - **High**: PIN with no repeating or ordered sequences and at least 8 characters, or alphabetic/alphanumeric password with at least 6 characters. #### Password Quality The legacy approach, which provides more granular control over password requirements: - **Unspecified**: No password requirements are enforced. - **Biometric Weak**: Requires a low-security biometric recognition method. - **Something**: A password is required, but with no restrictions on what it must contain. - **Numeric**: The password must contain numeric characters. - **Numeric Complex**: Numeric characters only, with no repeating (4444) or ordered (1234, 4321, 2468) sequences. - **Alphabetic**: The password must contain alphabetic or symbol characters. - **Alphanumeric**: The password must contain both numeric and alphabetic characters. - **Complex**: The password must meet the minimum requirements defined in the fields below. When **Complex** is selected, the following additional fields apply: - **Password Minimum Length**: Sets the minimum number of characters required. - **Password Minimum Letters**: Minimum number of letter characters required. - **Password Minimum Lower Case**: Minimum number of lowercase letters required. - **Password Minimum Non-Letter**: Minimum number of non-letter characters required (numbers or symbols). - **Password Minimum Numeric**: Minimum number of numeric digits required. - **Password Minimum Symbols**: Minimum number of symbols required (e.g., @, #, %). - **Password Minimum Upper Case**: Minimum number of uppercase letters required. #### Common settings The following settings apply regardless of which policy type you choose: - **Password Scope**: Determines which part of the Device the Policy applies to — the Work Profile, the entire Device, or both. - **Require Password Unlock**: Specifies the duration after unlocking the Device with a secure method (e.g., PIN or pattern) before the user is required to use that method again instead of biometrics. - **Unified Lock Settings**: Controls whether the same lock settings apply to both the Device and the Work Profile. If separate passwords are required and the user hasn't configured one, the Device will be marked as non-compliant. - **Maximum Failed Passwords For Wipe**: Specifies how many incorrect password attempts are allowed before the Device is completely wiped. A value of 0 means there's no limit. - **Password Expiration Timeout**: Defines how long a password can be used before the user is required to change it. **Enter this value in seconds**, not days — for example, `31536000` for 365 days, or `7776000` for 90 days. Once the time is up, the Device asks the user for a new password before it unlocks. - **Password History Length**: Indicates how many previous passwords are remembered to prevent reuse. Properly configuring password Policies on Android Devices through Applivery is a simple and effective way to strengthen security. By adjusting these settings, you ensure that all Devices meet your organization's minimum security standards, reduce potential risks, and maintain centralized control. ### AOSP Devices Support Password Policies work the same on AOSP — same fields, same configuration steps. The only differences worth noting: - **Password Scope** is always `DEVICE` on AOSP. There is no Work Profile separation, so the Policy always applies to the full Device lock screen. - **Unified Lock Settings** does not apply — there is a single lock screen only. --- ## Personalized Support Messages for Blocked Features Source: https://docs.applivery.com/en/device-management/android/policies/personalized-support-messages/ Description: Create personalized support messages for blocked features on Android Devices with Applivery to improve user experience and maintain security. TL;DR: Configure personalized messages for blocked Android features using Applivery to improve user experience and provide clear guidance on device restrictions. Key topics: Android device restrictions, Personalized support messages, Applivery configuration, User experience improvement, Mobile device management, Android, Applivery, Device Owner Lock Screen Info, Long Support Message, Short Support Message In corporate environments where Android Devices are centrally managed, applying restrictions is a common practice to reinforce security and ensure compliance with company Policies. However, when users attempt to access a blocked feature without understanding why, the experience can become confusing or frustrating. Clear, personalized messages help guide the user in real time, improving communication without compromising the security controls established by the organization. ### Support messages types Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), go to any of your **Policies**. From the left side menu, locate the **Lock screen**, where you will find the options that allow you to configure the different message types associated with blocked features. ![lock screen](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/f2b5a1d0-d664-4eb1-8f4d-f301365cdbdb.png) The available options are: - **Device Owner Lock Screen Info**: Allows you to display customized information directly on the lock screen. It is useful for showing instructions, company identification, or contact details in case of loss or support needs while the Device is locked. - **Long Support Message**: An extended message intended for cases where the operating system allows longer descriptions. It is ideal for more detailed explanations or support guidance, such as instructions for unlocking issues or steps to follow when a configuration screen is restricted by policy. This message can include contextual information or step-by-step instructions (e.g., “If you are unable to proceed, contact Applivery technical support…”). ![long message](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/611deaee-12da-4bf2-8331-283de56697b0.png) - **Short Support Message**: A brief message shown when only limited text can be displayed on the lock screen. It is commonly used for quick instructions or essential contact details when the Device only supports minimal information (e.g., “Device property of Applivery. Contact: [support@applivery.com](mailto:support@applivery.com)”). ![short message](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/94b93498-c8b0-4cec-90cb-a89d4a5d7ec7.png) Managing personalized messages for restricted features not only improves the user experience but also strengthens internal communication and support. Offering clear explanations—whether short or detailed—helps users understand the restrictions applied, reduces uncertainty, and provides direct guidance on what to do next. This proactive communication reduces incidents, speeds up support resolution, and reinforces trust in the Device management strategy. :::tip Personalized support messages are key to a positive user experience when managing Android Device restrictions. ::: Thanks to Applivery’s tools, it is possible to transform a potentially frustrating moment into an opportunity to inform, guide, and support the user while maintaining the highest level of security and compliance across managed Android Devices. ### AOSP Devices Support All message types work the same on AOSP — same configuration, same behavior. Because the Applivery DPC runs as Device Owner across the full Device, messages are shown at Device level — there is no Work Profile context. --- ## Prevent Data Transfer Between Profiles Source: https://docs.applivery.com/en/device-management/android/policies/prevent-data-transfer/ Description: Prevent data transfer between work and personal Profiles on Android Devices — configure cross-profile restrictions using Applivery MDM Policies. TL;DR: Prevent data leakage between work and personal profiles on Android devices by configuring cross-profile restrictions in Applivery. Key topics: Android security, Cross-profile restrictions, Data loss prevention, Applivery configuration, Android, Applivery, COPE, BYOD :::warning Cross-profile restrictions require a Work Profile (COPE or BYOD enrollment) and are **not available on AOSP Devices**. On AOSP, the Applivery DPC runs as Device Owner across the entire Device — there is no personal profile to separate data from. ::: Protecting corporate data privacy is essential to ensuring the security and integrity of your organization. With the adoption of COPE (Corporate-Owned, Personally Enabled) and BYOD (Bring Your Own Device) enrollment methods, businesses and employees gain flexibility—but also face new security challenges. To reduce risk, it’s important to establish a clear boundary between the personal and work profiles on Android Devices. With Applivery, you can prevent information from being transferred between profiles, including disabling common system functions like _Copy/Paste_ across work and personal environments. ### How to configure cross-profile restrictions **Navigate to Policies** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), navigate to **Policies** 1. **Select Android Policy** Select the Android Policy where you want to apply the restriction. Then, go to the **Compliance** 2 section in the left-hand menu. **Configure Cross Profile Policies** Locate the **Cross Profile Policies** 3 settings. There, you will find the following options: - **Cross Profile Copy Paste**: Select **Copy from Work to Personal Disallowed** to block copy/paste actions between the work and personal profiles. - **Cross Profile Data Sharing**: Select **Data Sharing from Work to Personal Disallowed** to prevent data from being shared between Apps across profiles. - **Show Work Contacts in Personal Profile**: Disable this option if you want to hide work contacts from appearing in the personal profile’s contact list. ![cross profile polices](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/521a02bb-4511-42b4-9672-47c783915079.png) Applying these Policies will help ensure corporate data remains within the managed environment, reinforcing the separation between work and personal use on Android Devices. --- ## Private Spaces in COPE Source: https://docs.applivery.com/en/device-management/android/policies/private-space/ Description: Manage Private Space on COPE Android Devices with Applivery — control access, balance security, and protect user privacy. TL;DR: Applivery enables organizations to manage Android 15's Private Space on COPE devices, controlling access to balance security and user privacy through configurable policies. Key topics: Android 15 Private Space, Applivery Management, COPE Device Policies, Mobile Security, User Privacy, Android 15, Private Space, Applivery, COPE [**Private Space**](https://source.android.com/docs/security/features/private-space) is a new feature in Android 15+ that lets users set up a secure and hidden area inside their personal profile—a true “secret vault” for sensitive Apps and data. ### What makes Private Space unique - **Private installation**: Users can install confidential Apps and data in a completely isolated environment, invisible from the main profile when locked. - **Invisible mode**: Apps and notifications in Private Space don’t show up in the App launcher, recent Apps, or system settings until unlocked. - **Extra security**: Private Space can use its own authentication (like PIN or biometrics), separate from the Device’s main lock, for added protection. ### How it differs from Work and Personal profile - **Work Profile** (managed by Applivery) keeps work Apps and data separate; organizations control, secure, and monitor this space. - **Personal profile** is the default area for personal Apps and data, with optional company oversight in COPE setups. - **Private Space** is not a work or personal profile—it’s a secure, user-created space inside the personal profile. Once set up, Applivery and IT admins cannot see inside, but can allow or block the creation of Private Space on corporate Devices. ### Why does Applivery allow managing it? While Applivery can’t access the contents of Private Space, it lets organizations decide whether to permit its use on COPE Devices. This empowers companies to: - **Ensure auditability**: Block Private Space if full visibility or auditability is required. - **Grant flexibility**: Permit Private Space for users who need extra privacy and freedom in their personal Device use. This version delivers the essential information in a clear, engaging format and focuses on unique benefits and management implications. ### Configuring Private Space Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), go to any of your **Policies** 1. From the left side menu, go to **Compliance**, locate the **Personal Usage Policies** option, and configure the **Private Space Policy** 2 setting. ![private space policy](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/726ba04a-748d-4a05-9dba-648ce45e705b.png) **Allow Private Space** **Allowed**: Choose this option if you want users to set up and use Private Space on corporate Devices. **Disallow Private Space** **Disallowed**: Choose this option to prevent users from creating or accessing Private Space. This hides the feature, and existing private spaces will be deleted. :::warning Make sure this Policy is assigned to all relevant Devices (especially **COPE** Devices). ::: Once Devices sync with Applivery (this may take a few minutes): - If Private Space is **disabled**, users won’t see the option in Settings, and any existing space will be deleted automatically. - If Private Space is **enabled**, users can access and set it up from their personal profile options. Managing mobile Devices with Applivery means you can finely control how corporate Android Devices are used—balancing organizational security and user privacy. Android 15’s Private Space showcases flexible mobile innovation. By applying these Policies, your company ensures COPE (Corporate-Owned, Personally-Enabled) Devices meet security requirements while respecting employee privacy—a smart approach for a productive, secure workplace. ### AOSP Devices Support Private Space is also configurable on AOSP Devices running Android 15+. Although AOSP has no Work Profile, Private Space lives in the primary user profile — and the Applivery DPC, running as Device Owner, can control whether users are allowed to create one. The configuration is the same: Allowed or Disallowed, same steps. --- ## Restrict Enrollment to a Corporate Domain Source: https://docs.applivery.com/en/device-management/android/policies/restrict-enrollment-to-corporate-domain/ Description: Force Android Devices to be provisioned only with your company's managed Google accounts using workAccountSetupConfig — restrict sign-in to your corporate domain or to one specific account. TL;DR: If Applivery is bound as a managed Google domain, use the workAccountSetupConfig policy field with authenticationType set to GOOGLE_AUTHENTICATED to force sign-in with a corporate managed Google account. Add requiredAccountEmail to pin one specific account. Key topics: Android Enterprise identity models, Managed Google domain, workAccountSetupConfig, Domain and account restrictions, Android Enterprise, Google Workspace, Managed Google accounts, Applivery, Android Management API Restricting device provisioning to a corporate domain depends directly on the identity model your Android Enterprise is configured with. Before you can lock enrollment to your company's accounts, it helps to understand the two models available and what each one lets you do. ### The two Android Enterprise identity models Android Enterprise supports two identity models for provisioning Devices: - **Managed Google Play Accounts enterprise** — users are registered through _Managed Google Play Accounts_, accounts provisioned directly by the EMM provider and not tied to an existing corporate domain. _Managed Google accounts_ aren't supported here, because structurally they aren't part of this model. - **Managed Google domain** — your organization operates on a managed Google domain (for example, Google Workspace or Cloud Identity). Users authenticate with their corporate _managed Google accounts_, and that identity is associated directly with the managed Android Devices. In practice, this determines how much identity control you have. If you need to restrict provisioning to corporate identities from a specific domain, the managed Google domain model is the one you need. Under a managed Google Play Accounts enterprise, identity control is limited to the Managed Google Play Accounts scheme, with no way to apply domain-level restrictions. So, whenever you need to limit account sign-up on the Device to only accounts belonging to your corporate domain, Applivery must have been bound as a **managed Google domain**. With that in place, if a user signs in with a Google account on their managed Device, the system forces that account to belong to your company domains — and if it doesn't, sign-in is blocked. If, on top of that, you want to **force** the user to sign in and prevent them from skipping that step, you control it through the **Work Account Setup Config** policy field, part of Google's Android Management API. :::info This configuration requires a **verified** Google Workspace domain, and your users' managed Google accounts must already exist in the Google Admin Console before you apply the policy. It doesn't provision them on its own — it only controls which account is accepted during setup. ::: ### Prerequisites - A managed Google Workspace domain, verified in the Google Admin Console and linked to Applivery. - Managed Google accounts already created for the users who will enroll Devices. - An Android Enterprise bound to Applivery through Google Workspace (a managed account under your corporate domain). See [Getting Started with Android](https://docs.applivery.com/en/device-management/android/get-started/#google-workspace-managed-domain) if you're still using a non-managed, managed Google Play account. ### Configure the domain restriction Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), go to any of your **Policies** 1. From the left-side menu, go to **Compliance**, and locate the **Work Account Setup Config** 2 setting. You can also open the **All Properties** section and search for it directly. ![work account setup config](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/49b7e28f-fde8-4553-a47b-538cc7b944cf.png) Inside the Android policy configuration, the **Work Account Setup Config** block accepts two parameters relevant to this use case:

Field

Type

Description

Authentication Type

enum

Set to GOOGLE_AUTHENTICATED to require a managed Google account during Device setup.

Required Account Email

string (optional)

The exact email address the user must use. If omitted, any managed Google account belonging to your enterprise is accepted — that is, any account in the domain.

#### Restrict to the domain only (any company account) If you don't need to pin a specific account, just enable Google authentication without **Required Account Email**. The Device accepts any managed Google account that belongs to your enterprise. If the user tries to sign in with an account outside the domain, Android Device Policy rejects it automatically — and they can't skip this step, so they're forced to sign in with a company account. #### Restrict to a specific account Add **Required Account Email** when you want to decide in advance which user should use that Device — for example, in enrollments targeted at a specific person. ![requireda ccount email](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/070e94d8-9f58-448e-ba63-a1a327e6f234.png) :::warning If you set **Required Account Email** to an address that **doesn't** belong to your enterprise domain by mistake, the Device becomes permanently non-compliant, and the user sees an error message until an administrator corrects the policy. ::: ### What the user experiences The exact behavior depends on whether the Device already has an account configured and whether **Required Account Email** is specified: - **No existing account + with** **Required Account Email**: the user is prompted to sign in with that exact account. - **No existing account + without** **Required Account Email**: the user is prompted for any valid managed Google account from the domain. - **Required account already present on the Device**: the update happens in the background, without asking the user to sign in again. - **User enters an account other than the required one**: they see an error directly on the Google sign-in screen and must try again with the correct account. - **User enters an account outside the corporate domain (no** **Required Account Email** **set)**: the account is automatically removed from the Device, and they're asked to sign in again with a valid account. ### Troubleshooting

Situation

Likely cause

Reported non-compliance reason

The user sees "Work policy requires the specified work account" or similar

They tried to sign in with an account other than Required Account Email

(blocked at sign-in, never reported as non-compliance)

The Device becomes permanently non-compliant and shows "Contact your IT administrator" or similar

Required Account Email points to an account that doesn't belong to your enterprise

REQUIRED_ACCOUNT_NOT_IN_ENTERPRISE

The account is removed from the Device automatically

The user signed in with an account outside the domain, and no Required Account Email was set

NEW_ACCOUNT_NOT_IN_ENTERPRISE

If you combine this configuration with [enforcement rules](https://docs.applivery.com/en/device-management/android/policies/enforcement-rules/) (block or wipe after N days of non-compliance), the Device shows progressive warnings before applying the configured mitigation action. :::info Google doesn't publish a specific minimum Android version for **Work Account Setup Config** or `GOOGLE_AUTHENTICATED`. The base requirement is that the Device supports Android Enterprise, available from Android 5.0 onwards. ::: By using **Work Account Setup Config**, you tie Android Enterprise provisioning to your corporate domain — forcing Devices to be set up only with your company's managed Google accounts and, if you need it, with one specific account through **Required Account Email**. Applied on top of a verified Google Workspace environment with properly provisioned managed accounts, this strengthens identity security, reduces enrollment mistakes, and gives you granular control over which user can sign in on each Device, while keeping the experience aligned with the compliance policies you've defined in Applivery. --- ## Restrict Wi-Fi Access Source: https://docs.applivery.com/en/device-management/android/policies/restrict-wifi-access/ Description: Restrict Wi-Fi access on Android Devices through Applivery Policies — allow or block specific networks to enforce connectivity rules. TL;DR: Learn how to restrict or allow Wi-Fi network access on Android devices using Applivery's Wi-Fi policy feature. Key topics: Wi-Fi policy configuration, Android device management, Network security, Applivery Dashboard, Android, Applivery, Wi-Fi, SSID In certain corporate environments, it may be necessary to restrict access to specific Wi-Fi networks—whether to enhance security, prevent interference from unauthorized networks, or ensure that Devices connect to the correct one. Below is a simple step-by-step guide on how to allow or block access to a particular Wi-Fi network from managed Devices. #### Configuring a Wi-Fi Policy **Navigate to Policies** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), navigate to **Policies** 1. **Select the Android Policy** Choose the specific Android Policy you wish to modify. **Access Network Settings** From the left-hand menu, click on the **Network** section. **Choose Wi-Fi SSID Policy** In the **Device Connectivity Management** settings, select either **Allowlist** or **Denylist** under **Wi-Fi SSID Policy Type** 2, within the **Wi-Fi SSID Policy** section. - **Allowlist**: Only the specified Wi-Fi networks will be allowed. - **Denylist**: The specified Wi-Fi networks will be blocked. ![Wi-Fi ssid policy](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/3e6288bf-4a4b-46d9-b010-f49a677be182.png) **Add Wi-Fi SSIDs** To specify the Wi-Fi network you want to allow or block, click **\+ Add element** under the **Wi-Fi SSIDs** 3 configuration. A form will appear where you can enter the SSID of the specific network. You can add as many SSIDs as needed. Once you’re done, simply save your changes by clicking **Save changes** in the Policy view. ![Wi-Fi ssid](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/7c71f42f-0503-4d61-9224-fa207e0e87db.png) Restricting access to specific Wi-Fi networks is a simple yet effective way to control device connectivity within your organization. Implementing these rules helps maintain a more secure, stable, and policy-aligned network environment. :::tip Regularly review and update your Wi-Fi Policies to ensure they remain effective and aligned with your organization's security needs. ::: ### AOSP Devices Support Wi-Fi SSID Policy works the same on AOSP — same options, same steps. The Applivery DPC applies restrictions at the Device level through the native Android `DevicePolicyManager` APIs, so no Google services are required. --- ## Common Policy Configurations Source: https://docs.applivery.com/en/device-management/android/policies/sample-policies/ Description: Explore common Android Device Management policy configurations, including Kiosk mode, web app kiosks, unknown sources, and network settings. Examples included. TL;DR: This guide provides example configurations for common Android Device Management policies, including Kiosk mode and network settings, in JSON format. Key topics: Kiosk Mode Configuration, Application Installation Policies, Network Configuration, Android Device Management, Policy Configuration, Android, Google Chrome, Applivery, JSON, Google Play Store As you probably already know, the possibilities of the Android Device Management Policies configuration are endless. Below you will find a repository of the most common configurations our users use to configure their projects. ### Kiosk Custom Launcher Replaces the home screen with a launcher that locks down the Device to the Apps installed via the applications setting. Apps appear on a single page in alphabetical order. - **Kiosk Custom Launcher Enabled** = `true`. - **Kiosk Customization** (optional): There are many options available that you can use to customize the Custom Kiosk mode behavior. :::tip We recommend enabling **Network Escape Hatch** (`networkEscapeHatchEnabled`: `true`), as it allows users to temporarily connect to a network if the Device cannot establish connectivity at boot time, ensuring that Device Policies can be properly refreshed. ::: ``` { "config": { "applications": [...], "networkEscapeHatchEnabled": true, "kioskCustomization": { "deviceSettings": "SETTINGS_ACCESS_ALLOWED" } } } ``` ### Single App kiosk mode The App is automatically installed in kiosk mode: it’s set as the preferred home intent and whitelisted for lock task mode. Device setup won’t be complete until the App is installed. After installation, users won’t be able to remove the App. You can only set this **Install Type** for one App per policy. When this is present in the Policy, the status bar will be automatically disabled. - **App configuration**: - Install type: `KIOSK`. - **Policy configuration** (optional). **Persistent Preferred Activities**: - **Receiver Activity**: name of your receiver activity i.e.:`com.applivery.kiosk.demo001/.AppliveryDeviceAdminReceiver` - **Categories**: i.e. `android.intent.category.LAUNCHER`. `android.intent.category.HOME`. `android.intent.category.DEFAULT`. - **Actions**: i.e.: `android.intent.action.MAIN`. :::tip We recommend enabling Network Escape Hatch (`networkEscapeHatchEnabled`: `true`), as it allows users to temporarily connect to a network if the Device cannot establish connectivity at boot time, ensuring that Device Policies can be properly refreshed. ::: ``` { "config":{ "applications":[ { "packageName":"com.applivery.kiosk.demo001", "installType":"KIOSK", "defaultPermissionPolicy":"GRANT", "permissionGrants":[ { "permission":"android.permission.BIND_DEVICE_ADMIN", "policy":"GRANT" } ] } ], "persistentPreferredActivities":[ { "receiverActivity":"com.applivery.kiosk.demo001/.AppliveryDeviceAdminReceiver", "actions":[ "android.intent.action.MAIN" ], "categories":[ "android.intent.category.LAUNCHER", "android.intent.category.HOME", "android.intent.category.DEFAULT" ] } ], "networkEscapeHatchEnabled":true } } ``` ### Web App kiosk mode You can also use Google Chrome in kiosk mode to display a specific URL as a single app, achieving the desired behavior on your dedicated device. To set up this configuration, follow the steps outlined in the [Single App Kiosk Mode](#single-app-kiosk-mode) section above, which involves configuring both the Persistent Preferred Activities setting and the **Network Escape Hatch**. - **Web app configuration**: - Install type: `KIOSK`. - **Google Chrome configuration**: - Install type: `FORCE_INSTALLED`. - Managed configuration: URL allow list:`["allowed URL"]`. URL block list:`["*"]`. :::info Multiple web Apps are allowed, separated by commas, i.e: `["allowed URL1", "allowed URL2"]` ::: ``` { "applications": [ { "packageName": "com.google.enterprise.webapp.xbf6a96eb033caa10", "installType": "KIOSK", "defaultPermissionPolicy": "GRANT" }, { "packageName": "com.android.chrome", "installType": "FORCE_INSTALLED", "defaultPermissionPolicy": "GRANT", "managedConfiguration": { "URLAllowlist": "["applivery.com/docs/"]", "URLBlocklist": "["*"]" } } ], "persistentPreferredActivities": [ { "receiverActivity": "com.android.chrome/com.google.android.apps.chrome.Main", "actions": [ "android.intent.action.MAIN" ], "categories": [ "android.intent.category.HOME", "android.intent.category.DEFAULT" ] } ], "networkEscapeHatchEnabled": true, "kioskCustomization": { "systemNavigation": "NAVIGATION_DISABLED" } } ``` ### Allow install from Unknown Sources Sometimes you will need to allow your users to install Apps (`.apk` or `.aab` files) from 3rd parties or your Private App Store in Applivery MAM. This is normally blocked by default in all Policies, so you will need to customize the following policy property to make it possible: - **Advanced Security Overrides**: - **Untrusted Apps Policy** = `ALLOW_INSTALL_DEVICE_WIDE`. - **Play Store Mode** = `BLACKLIST`. ``` { "config": { "applications": [...], "advancedSecurityOverrides": { "untrustedAppsPolicy": "ALLOW_INSTALL_DEVICE_WIDE" } "playStoreMode: "BLACKLIST" } } ``` ### Allow to install unknown Apps Sometimes you will need to allow users to grant specific Apps permission to install other Apps (`.apk` files) on their Device. **This is different from the Unknown Sources setting**, which allows the installation of Apps from sources other than the Google Play Store. This feature provides more granular control over which Apps can install other Apps on your Android device. It is often used for Apps like file managers or web browsers that may need to download and install `.apk` files. :::warning Remember that allowing Apps to install unknown Apps can pose a security risk, opening the door for potentially harmful or unverified Apps to be installed on your Device. ::: ``` { "advancedSecurityOverrides": { "untrustedAppsPolicy": "ALLOW_INSTALL_DEVICE_WIDE", "developerSettings": "DEVELOPER_SETTINGS_ALLOWED" } } ``` ### Network configuration Sometimes you will need to remotely deploy network configuration, including Wi-Fi and others. This is something that can be done by using the **Open Network Configuration** property, which supports deploying multiple configurations at the same time using the [ONC standard](https://chromium.googlesource.com/chromium/src/+/main/components/onc/docs/onc_spec.md). The most common properties are: - **GUID:** unique identifier for this network. - **Name:** friendly network name. - **Type:** type of network. Allowed values are: `VPN`, `WiFi`, `Tether`, `Ethernet`, `Cellular`. - **Security:** Security type. Allowed values are: `WEP-PSK`, `WEP-8021X`, `WPA-PSK`, `WPA-EAP`. - **AutoConnect:** Indicating that the network should be connected to automatically when possible `true` or `false`. ![onc](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/233c5a28-c945-44ca-be39-b4a3e94fa0e7.png) ``` { "NetworkConfigurations": [{ "GUID": "a", "Name": "Example A", "Type": "WiFi", "WiFi": { "SSID": "Example A", "Security": "None", "AutoConnect": true } }, { "GUID": "b", "Name": "Example B", "Type": "WiFi", "WiFi": { "SSID": "Example B", "Security": "WEP-PSK", "Passphrase": "1234567890" } }, { "GUID": "c", "Name": "Example C", "Type": "WiFi", "WiFi": { "SSID": "Example C", "Security": "WPA-PSK", "Passphrase": "baseball" } }] } ``` You can read more about [Open Network Configuration specs here](https://chromium.googlesource.com/chromium/src/+/main/components/onc/docs/onc_spec.md). --- ## Setup Actions Source: https://docs.applivery.com/en/device-management/android/policies/setup-actions/ Description: Automate Android Enterprise device setup with Applivery Setup Actions. Ensure compliance, consistency, and efficient deployments. Learn how! TL;DR: Applivery Setup Actions streamline Android Enterprise device enrollment by automating initial configuration tasks for compliance and consistency. Key topics: Android Enterprise, Applivery Setup Actions, Automated Device Configuration, MDM Policies, Zero-Touch Enrollment, Applivery, Android Management API (AMAPI), Google, Slack During the enrollment of Android Devices managed through Android Enterprise, it is often necessary to perform certain actions automatically during the initial configuration. These actions prepare the Device before the user starts using it, ensuring compliance with organizational requirements for security, operations, and technical settings. Setup Actions in Applivery allow IT administrators to execute these actions as part of the provisioning flow, providing consistency across corporate Devices, mass deployments, or critical configurations that must be applied before the user interacts with the Device. ### Configuration **Navigate to Policies** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), navigate to **Policies** 1. **Select the Android Policy** Choose the specific Android Policy you wish to modify. **Access All Properties** From the left-hand menu, click on the **All properties** 2 section **Choose Setup Actions** Locate **Setup Actions** 3, then click the **\+ Add element** button. ![setup actions](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/bf112771-4b7b-4035-a44e-aac70472e6ef.png) Each Setup Action requires defining a few key elements: - **Description** (optional): Additional text displayed during the execution of the action. - **Launch App**: This allows an application to run automatically during the Device’s initial configuration. Specify the **package name** of the Android app to be executed (e.g., a corporate app, a security agent, or a configuration app such as com.slack). - Optionally, include a **Title** message that will be visible to the user during setup, explaining what is being configured. :::warning The application must already be included in the Policy and set as `REQUIRED FOR SETUP`; otherwise, the provisioning process will fail. The action will execute only once during the initial device setup. ::: ### Important considerations - **Single execution**: Setup Actions run only during the first device setup. They will not repeat during subsequent policy updates or synchronizations. - **Supported Devices**: Setup Actions are intended primarily for Company-Owned, Fully Managed Devices, or Zero-touch / QR enrollment scenarios. - **Application dependency**: If the action launches an application, it must be configured as `REQUIRED FOR SETUP`, and any failure during installation or execution will block the provisioning process. - **User experience**: Actions run before the user has full access to the Device, ensuring consistency but possibly increasing initial setup time. - **Recommended usage**: Only use Setup Actions for critical configurations, Apps required to complete onboarding, or automated provisioning workflows. :::warning Due to Android Management API (AMAPI) constraints, only one Setup Action can be configured in this section. Additional setup actions can be implemented using [Applivery’s Advanced Launcher in Kiosk mode](https://docs.applivery.com/en/device-management/android/policies/kiosk-mode/#advanced-launcher-multi-app-kiosk-mode) with the Auto-start at first boot option, keeping in mind the inherent limitations of Kiosk mode. ::: Android Setup Actions in Applivery are an essential tool to automate and standardize the first boot configuration of managed Android Devices. They ensure that critical applications and processes are executed immediately, reduce manual errors, and improve efficiency in corporate deployments. When planned and applied correctly, Setup Actions enable a controlled, secure, and repeatable onboarding experience, particularly in environments with large device volumes or strict configuration requirements. --- ## Tethering Source: https://docs.applivery.com/en/device-management/android/policies/tethering/ Description: Control tethering on Android Devices with Applivery Policies — manage Wi-Fi hotspot, USB, and Bluetooth tethering permissions. TL;DR: Manage Android tethering policies with Applivery to enable, disable, or restrict tethering based on your organization's needs for enhanced security and data control. Key topics: Android Device Management, Mobile Security, Policy Configuration, Applivery, Android, Wi-Fi, USB, Bluetooth Tethering on Android Devices enables users to share their mobile data connection with other Devices via **Wi-Fi**, **USB**, or **Bluetooth**. In a managed environment, controlling this feature is crucial to ensure secure and efficient use of corporate resources. **Enrolling in tethering** can be beneficial in certain scenarios, such as when employees are traveling or working in areas with limited Wi-Fi access. However, it also presents risks, including excessive data usage, unauthorized network access, and potential security vulnerabilities. On the other hand, **disabling tethering** supports stricter data usage Policies, helps prevent misuse of Devices as mobile hotspots, and minimizes the risk of external threats. ### Configuring a tethering policy **Navigate to Policies** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), navigate to **Policies** 1. **Select the Android Policy** Select the Android Policy where you want to configure tethering. **Go to the Network section** From the left-hand menu, click on the **Network** section. **Choose the desired tethering option** In the **Device Connectivity Management** 2 configuration, choose the option that best suits your needs under **Tethering Settings** 4: - **ALLOW ALL TETHERING**: This option enables all forms of tethering (Wi-Fi, USB, and Bluetooth) on the Device. - **DISALLOW Wi-Fi TETHERING**: This option blocks Wi-Fi tethering, while other types (e.g., USB, Bluetooth) may remain available. - **DISALLOW ALL TETHERING**: This option fully disables tethering across all connection types. It is supported on Fully Managed Devices, work profiles on company-owned Devices, and all Android versions supported by Applivery. In all three cases, any configuration related to **Tethering Config Disabled** will be ignored. ![thetering](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/24135ff0-26d9-4270-91ee-62e188de8aec.png) :::warning **DISALLOW Wi-Fi TETHERING** is only supported on company-owned Devices running Android 13 or above. If the Device runs a lower version, the system will fall back to **ALLOW ALL TETHERING**, and a `nonComplianceDetail` will be reported indicating the API LEVEL mismatch. ::: Managing Android tethering through Applivery allows organizations to strike an effective balance between user flexibility and administrative control. While **enabling tethering** can enhance user autonomy, particularly in scenarios like travel or limited connectivity, it also introduces potential risks related to data consumption and network security. Conversely, **disabling tethering** strengthens security posture and provides greater oversight of network usage, making it especially valuable in environments with strict compliance requirements. With Applivery, these settings can be centrally managed and customized for specific Device groups, ensuring consistent policy enforcement across your entire mobile fleet. ### AOSP Devices Support Tethering Policy is fully supported on AOSP — same options, same steps. No Google services required. --- ## Wallpaper Configuration Source: https://docs.applivery.com/en/device-management/android/policies/wallpaper-configuration/ Description: Apply a corporate image as the wallpaper on managed Android Devices through Applivery's Advanced Launcher. TL;DR: Configure the wallpaper in Policy → Kiosk → Advanced Launcher → Personalization → Wallpaper, using the image URL. You don't need to lock the Device down: Launcher mode is enough. Key topics: Wallpaper in the Advanced Launcher, Launcher mode vs Kiosk mode, Launcher personalization, Troubleshooting, Applivery, Android, Advanced Launcher, AOSP On Android, you configure the corporate wallpaper from Applivery's **Advanced Launcher**, using the image URL. You don't need to lock the Device down in kiosk mode: **Launcher** mode is enough. Unlike [Windows](https://docs.applivery.com/en/device-management/windows/policies/wallpaper-configuration/) and [macOS](https://docs.applivery.com/en/device-management/apple/macos/policies/wallpaper-configuration/), Android Policies don't have a standalone wallpaper setting. The wallpaper is part of the personalization of Applivery's managed launcher, which replaces Android's default launcher and supports configurations the native launcher doesn't. ### Requirements

Requirement

Details

Management type

Fully Managed Devices

Feature

Advanced Launcher (Launcher or Kiosk mode)

Minimum Android version

Android 8 (Advanced Launcher requirement)

Image

Hosted on a web-accessible host; provided by URL

AOSP

Supported: the Advanced Launcher works on AOSP exactly as on Fully Managed (AMAPI) Devices

:::warning The Advanced Launcher replaces the Device's launcher. If you only need the wallpaper and want the Device to keep behaving like a normal Android Device, use **Launcher** mode, not **Kiosk** mode. ::: ### Launcher mode or Kiosk mode Both modes support the wallpaper, because personalization is part of the Advanced Launcher's general settings.

Mode

What it does

When to choose it for the wallpaper

Launcher

Applivery's managed launcher, without kiosk restrictions

General-purpose corporate Devices that only need branding and extra controls

Kiosk

Locked multi-app kiosk

Dedicated Devices (retail, signage) where you also want to restrict usage

### Configure the wallpaper **Host the image** Upload the corporate image to a web-accessible server and copy its URL. **Open the Policy** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), go to **Policies** 1 and open the Android Policy you want to change, or [create a new one](https://docs.applivery.com/en/device-management/general-settings/create-policies/). In the left-hand menu, click **Kiosk** and switch to the **Advanced Launcher** 2 tab. In **App operation mode** 3, select **Launcher**, or **Kiosk** if the Device needs to be locked down. Under **Personalization**, fill in the **Wallpaper** 4 field with the image URL. ![wallpaper](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/d785e11b-7685-44aa-ad28-54134efc73bd.png) **Save and assign** Save the Policy and make sure it's assigned to the target Devices. :::info The wallpaper is applied through Applivery's launcher layer, not Android's native launcher. ::: ### What else you can customize in the same section Under **Personalization,** you can also set the **Icon Size** (Small, Medium or Large), the **App layout** and **Folders**. The interface also supports a text **Header** and **Footer**, which can include [dynamic variables](https://docs.applivery.com/en/device-management/general-settings/dynamic-variables/) such as the Device serial number, the IMEI, or the user. You'll find all the details in [Kiosk Mode](https://docs.applivery.com/en/device-management/android/policies/kiosk-mode/). ### If the wallpaper isn't applied - **Check the management type.** The Advanced Launcher is designed for Fully Managed Devices. - **Check the Android version.** The Advanced Launcher requires Android 8 or later. - **Check the URL.** It must point to a web-accessible host where the image is stored. Open it in a browser outside your corporate network to confirm. - **Check that the Policy is assigned** to the Device and that the Device has received it. --- ## Remote Support Source: https://docs.applivery.com/en/device-management/android/remote-support/ Description: Enable Android Remote Support in Applivery MDM to remotely access and control Android Devices for efficient troubleshooting. TL;DR: Enable Android Remote Support in Applivery MDM to remotely access and control devices for efficient troubleshooting and management. Key topics: Enabling remote support in Applivery, Starting remote support sessions, Attended vs. Unattended remote support, Android device management, Applivery, Android, MDM, IT professionals ![remote support](https://www.applivery.com/wp-content/uploads/2024/11/Remote-Support-image-1024x623.png "remote support | Applivery") :::warning Remote Support requires Google Mobile Services and is **not available on AOSP Devices**. ::: **MDM Remote Support**, or **Mobile Device Management Remote Support** (including **Remote Control** or **Remote Access**), enables an authorized administrator to remotely access and control Devices such as smartphones, tablets, or desktops. This capability is used to manage and troubleshoot Devices efficiently. Remote Support allows IT professionals to diagnose and resolve users’ technical issues from a remote location. It serves as a critical tool for IT managers, facilitating prompt issue resolution without requiring physical presence. This approach not only improves support efficiency but also enhances user satisfaction and productivity. With the **Applivery Remote Support App**, you can assist users by viewing or controlling their Android Devices directly. Support sessions can be initiated instantly from Applivery, allowing you to act as an agent and provide seamless remote assistance to Device users. ### Enabling Remote Support at the Policy level Applivery Device Management Android Remote Support is enabled at the Policy level. Go to any of your **Policies** 1 and select the **Remote support** section 2 from the left side menu. ![enable remote support](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/90e56935-985a-491d-ae80-688dfda6390e.png) To enable the Remote Support App, click the **Enable** button located at the top right 3. Last, decide whether you want the App to be installed in the **Required for Setup** mode. This way is the most common for new Devices, and the App will be installed during the enrollment process to ensure it’s installed before the system starts up. If you don’t select this option, the application will be installed in **force-installed** mode, which is the most common scenario. In this case, the Remote Support App will be automatically installed on Devices and cannot be removed. Don’t forget to click the **Save changes** button before leaving the page to deploy all your changes. ### Starting a new session There are two ways to request remote assistance: **by user** or **by admin**. If you’re the admin, navigate to any of your Android Devices to start a session. On the Device side, click the **Action** button 4, then select **Remote Support** 5. There are two operation modes:  - **Request permission**: The user must accept the request to start the session. - **Unattended**: Start the session without user interaction. :::warning For **unattended mode**, please ensure that the Remote Support App **has been opened at least once**, **all necessary permissions have been granted**, and **the screen has been properly calibrated**. ::: ![action remote support](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/421ebc31-664c-49a4-b649-526abb211415.png) ### Watch how to do it! :::warning For **unattended mode**, carefully follow the on-screen instructions. Calibration requires identifying the location of the "Start Now" button. To achieve this, **take a screenshot when the dialog box appears**. **You do not have to press the “Start Now” button**. ::: --- ## Security Posture Source: https://docs.applivery.com/en/device-management/android/security-posture/ Description: Understand the Android security posture in Applivery. Learn what Secure, At risk and Potentially compromised mean and how to act on compromised Devices. TL;DR: Applivery reports whether an Android Device's operating system has been tampered with, as a shield in the device list and a compliance check inside the Device. It needs Google Mobile Services, so AOSP is not covered. Key topics: Android security posture, Play Integrity API, Compromised device detection, Device compliance, Applivery, Android, Google Play Services Not every risk on a Device comes from a setting you can configure. A Device can follow every Policy you assigned and still not be trustworthy, simply because someone modified its operating system. The **security posture** is the signal that tells you when that happens. It answers a different question from the rest of your Policies: not _"is this Device configured the way I asked?"_ but _"can I still trust this Device with corporate data?"_ ### What the security posture tells you Android Enterprise evaluates each Device and reports one of three values:

Value

What it means

Secure (SECURE)

The Device is secure.

At risk (AT_RISK)

The Device may be more vulnerable to malicious actors than is recommended for use with corporate data.

Potentially compromised (POTENTIALLY_COMPROMISED)

The Device may be compromised, and corporate data on it may be accessible to unauthorized actors.

**Potentially compromised** is the value you get for a rooted Device. It's worth treating as an incident rather than a warning: at that point you can no longer assume that the restrictions in your Policy are actually being enforced, because the operating system that enforces them is the part that was modified. ### Where to find it in the Dashboard Applivery surfaces the security posture in two places, at two different levels of detail. #### In the device list Every Device in the list shows a **shield icon** next to the Policy field. It's a summary of the Device's overall [compliance checks](https://docs.applivery.com/en/device-management/general-settings/compliance-checks/):

Shield

What it means

🟢 Green

The Device is compliant and its posture is Secure.

⚪ Grey

Something about the Device needs attention, but it isn't the security posture.

🔴 Red

The security posture is At risk or Potentially compromised.

![security posture devices list](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/27c6cb31-c0b5-4e8b-8dca-66b11e9e8f87.png) Two things follow from this, and both matter when you're triaging a fleet: - **Red always means a security problem**, never a pending configuration. Grey and red are different classes of issue and call for different responses — grey is operational, red is a question of whether the Device can still be trusted. - **Both risk values raise the same red shield.** To tell _At risk_ from _Potentially compromised_, open the Device. #### In the Device's Compliance checks Open the Device and go to the **Overview** section, where you'll find the **Compliance checks**. A Device whose posture is at risk or compromised gets a check of its own, in red, titled with the posture value — **At risk** or **Potentially compromised**. ![security posture device overview](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/3a32e80c-2687-47ff-abfd-7bb7c8a39b41.png) Inside it, for each risk detected, you get: - **The name of the risk** — _Unknown OS_, _Compromised OS,_ or _Hardware-backed evaluation failed_ — with a tooltip explaining what Play Integrity detected. - **Google's advice** for mitigating it, written for you as the admin. For example: _"The user should lock their device's bootloader."_ A Device reported as **Secure** gets no security check at all. Here the absence is the good news — there's no green entry confirming it, so don't read "no security check" as "not evaluated". ### Why a Device is flagged When the posture isn't **Secure**, the specific risk behind it is one of these three:

Risk

What Google detected

Unknown OS (UNKNOWN_OS)

The Device is running an unknown OS: the basicIntegrity check succeeds, but ctsProfileMatch fails.

Compromised OS (COMPROMISED_OS)

The Device is running a compromised OS: the basicIntegrity check fails.

Hardware-backed evaluation failed (HARDWARE_BACKED_EVALUATION_FAILED)

The Device doesn't offer a strong guarantee of system integrity — the MEETS_STRONG_INTEGRITY label is missing from its device integrity verdict.

There's a fourth value, **Unspecified security risk** (`SECURITY_RISK_UNSPECIFIED`), shown when Google doesn't narrow down the cause. It isn't actionable on its own. All three come from Google's **Play Integrity API**, which is the component that actually inspects the Device. Applivery reports the verdict; it doesn't produce it. :::info Because the evaluation happens on Google's side, the posture is a _report_, not a _setting_. There is nothing to enable in a Policy to turn it on, and no value you can configure to make it stricter. ::: ### AOSP Devices have no security posture The Play Integrity API is part of **Google Play Services**. AOSP Devices — the non-GMS builds common on rugged and industrial hardware — don't have Google Play Services, so there is no integrity signal for Android to report and no posture for Applivery to display. This isn't an Applivery limitation, and no MDM can work around it: the component that performs the check simply isn't present on the Device. If you need integrity or root detection on an AOSP fleet, it has to come from a third-party **Mobile Threat Defense (MTD)** solution. ### Acting on a compromised Device The security posture reports a risk — it doesn't act on it. Blocking or wiping is a separate decision, and you have three routes: - [**Remote commands**](https://docs.applivery.com/en/device-management/android/commands/remote-commands/), applied manually from the Dashboard: lock the Device, reset the password, or wipe it. This is the direct response to a Device you've just seen flagged. - [**Policy Enforcement Rules**](https://docs.applivery.com/en/device-management/android/policies/enforcement-rules/), for automatic block and wipe actions after a number of days. Note what these react to: a Policy setting that _can't be applied_ on the Device — not the security posture. They're a useful complement, not a consumer of this signal. - [**Automation Rules**](https://docs.applivery.com/en/device-management/general-settings/automation-rules/), to apply a restrictive quarantine Policy automatically. These act on [Device Audiences](https://docs.applivery.com/en/device-management/general-settings/device-audiences/), which are built from tags — so you need something to tag the Device first. That's what a Mobile Threat Defense integration such as [Check Point Harmony Mobile](https://docs.applivery.com/en/device-management/integrations/security/checkpoint-harmony-mobile-integration/) provides: its risk groups map to Applivery tags, the tags feed a Device Audience, and the Automation Rule applies the quarantine Policy. :::warning **An Automation Rule can't wipe a Device.** Its only actions are applying a Policy and adding a Smart Attribute — it configures Devices, it doesn't send commands. If a compromised Device needs wiping, either do it manually with a remote command, or have the quarantine Policy carry its own Policy Enforcement Rules to block and then wipe. Don't promise a one-step "MTD detects it, Applivery wipes it" flow, because that isn't what happens. ::: ### Security posture and compliance status are not the same thing These two are easy to confuse, and the difference matters when you're explaining a flagged Device:

Security posture

Compliance status

Question it answers

Can the operating system be trusted?

Does the Device meet the Policies I assigned?

Who decides

Google, via the Play Integrity API

Your Policy configuration

Typical cause of a problem

The Device is rooted or running a modified OS

A required setting isn't applied, or the user changed something

Can you configure it?

No — it's reported, not set

Yes — it follows the Policies you define

A Device can be perfectly compliant and still be **Potentially compromised**, and that combination is precisely the one worth watching: everything looks correct, but the layer enforcing it can no longer be trusted. --- ## Android Troubleshooting Source: https://docs.applivery.com/en/device-management/android/troubleshooting/ Description: Find solutions to common Android device management issues in Applivery. Resolve enrollment problems, policy conflicts, app deployment errors, and more. TL;DR: This guide provides solutions to common Android device management issues within Applivery, including enrollment, policy, and app deployment problems. Key topics: Android device enrollment, Policy management, App deployment, Kiosk mode configuration, OEM settings management, Android, Applivery, OEM Diagnose and resolve common issues with Android Device Management in Applivery — including enrollment failures, Policy conflicts, App deployment errors, kiosk mode problems, and OEM configuration issues. Each article explains the likely cause and the steps to fix it, so you can resolve issues quickly without escalating to support. --- ## The Agent Stops Reporting Source: https://docs.applivery.com/en/device-management/android/troubleshooting/agent-not-reporting/ Description: Android Devices that go quiet for hours and then report again are usually being suspended by the manufacturer's battery layer. Here's how to confirm it and fix it. TL;DR: A Device that goes quiet for hours and comes back is usually being suspended by the manufacturer's battery layer. Exclude the agent from battery optimization. Key topics: Ruling out Doze, Manufacturer battery exclusions, Devices marked as inactive, Applivery, Android, Xiaomi, OPPO, Samsung A Device reports normally for a while, then goes quiet for most of a day, then reappears as if nothing had happened. Nobody touched it, nothing failed, and it was often sitting on a charger the whole time. That is almost always the manufacturer's **battery layer** suspending the Applivery agent to save power. Many Android manufacturers add their own power management on top of Android's, and it is far more aggressive: it decides which background Apps get suspended, and the agent is treated like any other App. ### Ruling out Android's own power saving Android has its own mechanism, Doze, and it is the obvious suspect. It is usually the wrong one. :::info **Doze does not apply while the Device is charging.** So if the Device was plugged in and still stopped reporting, Android's own power saving is ruled out and the cause is the manufacturer's layer. This single check separates the two. ::: ### Excluding the agent from battery optimization The fix is to tell the Device to leave the agent alone. The exact route depends on the manufacturer and on the version of its Android skin, so treat these as a starting point rather than exact steps.

Manufacturer

Route

Redmi / Xiaomi

Settings → Apps → Manage apps → select the App → turn on Autostart and set battery saver to No restrictions.

OPPO

Settings → Battery → select the App → allow background activity with no restrictions.

Samsung

Settings → Battery → Background usage limits → check the App is not listed under "Sleeping apps" or "Deep sleeping apps".

:::warning **Exclusions can be reverted by a firmware update.** Build them into your periodic checks on affected models rather than treating them as a one-off fix. ::: For per-brand detail, [dontkillmyapp.com](https://dontkillmyapp.com) is a useful community reference. It is not official documentation, so use it alongside the manufacturer's own settings rather than instead of them. ### Devices marked as inactive A Device is marked as inactive after 5 days without reporting, so a suspended agent is one of the ways a perfectly healthy Device ends up flagged. See [Device States](https://docs.applivery.com/en/device-management/general-settings/device-states/) for what the status fields actually mean. If the exclusion is in place and the Device still goes quiet, contact Applivery Support: we can review the agent activity on that Device and confirm whether it is still being suspended. --- ## Handling Internet Connection Loss Source: https://docs.applivery.com/en/device-management/android/troubleshooting/internet-connection-loss/ Description: Prevent internet connection loss from disrupting Kiosk Mode Devices in Applivery using the Network Escape Hatch feature. TL;DR: The Network Escape Hatch feature ensures uninterrupted kiosk mode operation by allowing temporary network connections to refresh device policies when a stable internet connection is unavailable. Key topics: kiosk mode, internet connectivity, network escape hatch, device policy, Android Maintaining a consistent internet connection is essential for the seamless operation of kiosk-mode Devices. However, there are situations where these Devices experience a loss of internet connectivity. This is the main reason why we highly recommend enabling the “**Network Escape Hatch**” property to address this concern when configuring device Policies. :::tip Enabling the Network Escape Hatch ensures uninterrupted kiosk mode operation, even with intermittent internet connectivity. ::: This feature can be enabled to ensure the uninterrupted operation of Devices in kiosk mode. When booting up, if a network connection cannot be established, the escape hatch prompts the user to temporarily connect to a network to refresh the Device policy. Once the Policy has been applied, the temporary network information is forgotten, and the Device continues to boot up. This prevents situations where the Device is unable to connect to a network due to the absence of a suitable network in the last policy. It also safeguards against scenarios where the Device boots into an App in lock task mode or the user is unable to access the Device settings. To learn more about configuring kiosk mode features, we recommend checking out our [Android kiosk mode](https://docs.applivery.com/en/device-management/android/policies/kiosk-mode/) article. --- ## Your Private App Can't Make Calls with Kiosk Mode Enabled Source: https://docs.applivery.com/en/device-management/android/troubleshooting/private-app-calls-kiosk-mode/ Description: If an Android App can't make calls only when the Device is in kiosk mode, add the system Phone Apps your Devices use to the Policy. TL;DR: If an App can't make calls only in kiosk mode, add the system Phone Apps (dialers) your Devices use to the Policy. In a kiosk, system Apps aren't shown or managed by default. Key topics: Symptoms of blocked calls in kiosk mode, Diagnosing with a duplicated Policy, Adding dialers as system Apps, Temporary workaround with Launcher mode, Applivery, Android, Advanced Launcher, Kiosk mode If an App can't make calls only when the Device is in kiosk mode, add the system Phone Apps (the _dialers_) your Devices use to the Policy and test again. In a kiosk, system Apps aren't shown or managed by default, so you need to include them explicitly. ### Symptoms - An App tries to start a call and it drops abruptly or never connects. - The system Phone App can make calls, or the App can't receive calls either. - The issue goes away when you remove the kiosk or switch the Advanced Launcher to **Launcher** mode. - Changing the default Phone App doesn't fix it. ### What happens In Applivery, the **Advanced Launcher** has two operating modes:

Mode

What it does

Restrictions

Launcher

Provides a launcher with the Policy's Apps

Doesn't apply kiosk restrictions

Kiosk

Activates a full multi-app kiosk

Does apply restrictions to the Device

[Kiosk mode](https://docs.applivery.com/en/device-management/android/policies/kiosk-mode/) restricts the Device to the Apps you define in the Policy, and its Kiosk-only settings only apply when the Device is genuinely in kiosk mode. This issue shows up mostly with Apps that **make calls from inside the App itself**. Those Apps usually open the **Device's Phone App** to place the call. If Kiosk mode blocks that Phone App, the call can't start. ### How to diagnose it Run these tests on a test Device with a copy of your production Policy:

Test

Result

Conclusion

Call from the system Phone App, outside the affected App

Works

The Device and the line are fine

Call from the affected App with the kiosk active

Fails

Possible block by the kiosk

Call from the affected App with the kiosk removed (other Policies still applied)

Works

The issue is in the kiosk, not in the other Policies

Switch the Advanced Launcher from Kiosk to Launcher

Works

Confirms it depends on Kiosk mode

:::warning Always test with a duplicated Policy and a single Device. Don't change your production Policy to diagnose. ::: ### Fix: add the dialers to the Policy **Open the Policy** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), open the affected Policy 1 and go to the **Apps** 2 section from the left-hand menu, then select **\+ Add App** 3. ![add app](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/99357efb-6f20-4548-a9c9-d0df179cd02e.png) **Choose the Phone App** Select the **System App** tab. Pick the Phone App your Devices use or type its package name. If your fleet has several manufacturers, add each one's Phone App. ![dialer](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/7dced32d-ba08-4feb-853f-cfcebdedc628.png) :::info To find the package name, turn on **Application Reports Enabled** in the Policy's **Reporting** section. The full list of Apps, including system Apps, then appears in the **Device** details under **Apps**. You'll find more details in [System Apps](https://docs.applivery.com/en/device-management/android/app-management/system-apps/). ::: **Add it as Available** Click **Select**, choose the **Available** installation type and add the App to the Policy's list. **Save and test** Save the Policy and wait for the Device to receive it. Then test an outgoing and an incoming call from the affected App. ### What usually doesn't fix it These actions **don't** fix the block: - Granting permissions to the App through _Grant permissions_ in the managed properties. - Setting another Phone App as default, whether Google's or the manufacturer's. ### Temporary workaround If you need calls to work while you adjust the Policy, run the Advanced Launcher in **Launcher** mode. Keep in mind it doesn't apply kiosk restrictions (status bar, navigation, power button, Settings access), so the Device is less locked down. ### If it still fails - Confirm the Device has received the latest Policy. - Check that the Phone App appears in the Policy's App list and that the package name matches the one the Device uses. - Repeat the diagnostic tests to confirm the failure still depends on Kiosk mode. - If the issue persists, contact Applivery support with the Device model, the Policy and the exact time of the failure. --- ## My Device Is Not Enrolled Anymore but Still Has Restrictions Source: https://docs.applivery.com/en/device-management/android/troubleshooting/unenrolled-device-restrictions/ Description: Why an Android Device can get stuck in an in-between state after you unenroll or wipe it from Applivery, and how to factory reset and recover it. TL;DR: The Device never received, or couldn't run, the removal command: it was offline, the command expired or it was in BFU. If you can reach it, resend the command; if not, factory reset it locally. If FRP appears, you need one of the accounts authorized in the Policy. Key topics: In-between state after unenrollment, Causes by management mode, Resending commands and Duration, BFU state, Factory reset from recovery mode, Factory Reset Protection, Prevention, Applivery, Android, Android Device Policy, Android Management API, AOSP, Pushy A Device gets stuck in an in-between state when the console no longer manages it, but the Device never received (or couldn't run) the removal command, so it keeps the Policy, restrictions or locks. The most common cause is that the command never arrived: the Device was off or offline, the command expired, or the Device was locked in BFU state. If you can still reach the Device, resend the command. If not, the way out is usually a local factory reset, from Settings or from recovery mode. If the FRP screen appears afterwards, you need one of the accounts authorized in the Policy. ### How to recognize a Device in an in-between state A Device is in an in-between state when two things happen at once: 1. In the Applivery Dashboard, the Device has been unenrolled, wiped or no longer responds to commands. 2. On the Device, the Policy restrictions are still active: blocked Apps, inaccessible settings, kiosk, factory reset blocked, and so on. Before looking for the cause, gather this information. You'll need it if you escalate the case to support: - The Device's **management mode**: fully managed, dedicated (kiosk), COPE, personal work profile or AOSP. - The **last command sent**, with its date and **Duration**, and the status shown in the **Commands** tab. - Whether the Device is **on**, **has battery** and **has a connection**. - Whether the Device **rebooted** recently and is asking for the PIN at boot. - Whether the Policy had **Frp Admin Emails** configured. ### Possible causes | # | Cause | How to identify it | Affected modes | |---|-------|--------------------|----------------| | 1 | **The command never reached the Device**: off, out of battery, offline or out of coverage. | The Device hasn't reported in a while and the command is still unconfirmed. | All | | 2 | **The command expired.** Remote commands have a **Duration** parameter (in seconds) and expire if the Device doesn't run them within that time. | The command shows as expired or not run, and the Device came back online afterwards. | All | | 3 | **Device in BFU (Before First Unlock) state.** With `encryptionPolicy` set to `ENABLED_WITH_PASSWORD`, after a reboot the Device asks for the PIN before decrypting storage. Until then, Android's user space is frozen, including Android Device Policy, the component that talks to Applivery. | The command fails almost instantly even though the Dashboard shows the Device connected to Wi-Fi. | Fully managed and dedicated | | 4 | **Device locked with an unknown password.** The **Reset password** command can't work on a Device that's already locked unless a reset token is activated. | You need the PIN or pattern and nobody knows it. | Fully managed | | 5 | **Dedicated (kiosk) Device with no network at boot.** Without a connection, the Device can't download the Policy or receive commands. | The Device boots into the kiosk and can't connect. | Dedicated | | 6 | **AOSP Device not receiving the command.** On AOSP, commands are sent through Pushy (not AMAPI) and run by the Applivery DPC, which confirms receipt and completion. | The command never gets past "sent" and there's no receipt confirmation. | AOSP | | 7 | **Factory reset blocked by the Policy.** The Policy prevents the user from resetting the Device from Settings. | The reset option isn't available or has no effect. | Fully managed, dedicated and AOSP | | 8 | **Factory Reset Protection (FRP).** If the Policy defined **Frp Admin Emails**, after a forced reset the Device requires one of those Google accounts to finish setup. | The account verification screen appears after the reset. | Fully managed | | 9 | **Wipe from enforcement rules with Preserve Frp turned on.** If the **Wipe Action** has **Preserve Frp** set to `true`, FRP data is kept after the automatic wipe. | The Device was wiped for non-compliance and now asks for an FRP account. | Fully managed | :::info A factory reset can't always be blocked. On COPE Devices, no EMM solution, Applivery included, can disable factory reset, so the user always keeps that option. You'll find more details in [COPE Permission Limits](https://docs.applivery.com/en/device-management/android/cope-permission-limits/). ::: ### Fixes Start with the first one that applies to your case. They go from least to most destructive: only the last ones mean losing the Device's data. #### 1. Restore connectivity and resend the command Applies to causes 1, 2, 5 and 6. 1. Check that the Device is on, has battery and has a connection (Wi-Fi or mobile data). 2. If the Device is in a kiosk with no network, use the **Network Escape Hatch** if it's enabled in the Policy. It offers temporary network recovery access to refresh the Policy; once the Policy is applied, the temporary network is forgotten and boot continues normally. You'll find more details in [Kiosk Mode](https://docs.applivery.com/en/device-management/android/policies/kiosk-mode/). 3. When the Device comes back online, resend the command from the Device's **Action** button, from its **Commands** tab or from **Settings → Danger zone**. See [Remote Commands](https://docs.applivery.com/en/device-management/android/commands/remote-commands/). 4. Set **Duration** to a value long enough to cover the time the Device may take to come back online. There's no maximum. :::info On [AOSP](https://docs.applivery.com/en/device-management/android/aosp/) Devices, if you need to remove management without wiping the Device, use the **Disenroll** command: it removes the Applivery DPC as Device Owner and clears the Device's stored state. ::: #### 2. COPE Devices: relinquish ownership or reset from the Device Applies to COPE (Company-Owned, Personally Enabled) Devices. - From the Dashboard, send the **Relinquish ownership** command from the **Commands** tab. It removes the work profile and corporate management policies and keeps the content of the personal profiles; the Device then behaves like a standard unmanaged Android Device. - If the command doesn't arrive, the user can factory reset the Device from their own Settings. On COPE, that option can't be blocked. #### 3. Device in BFU state Applies to cause 3. **There's no remote fix**, because in BFU there's no process able to receive commands. You need physical access: 1. **Enter the PIN on the Device.** If the user remembers it, this is the simplest option. Once unlocked, the Device receives commands again and you can resend the removal or wipe command. 2. **Factory reset from recovery mode.** The Device loses all local data, but becomes manageable again. To keep it from happening again, use `ENABLED_WITHOUT_PASSWORD` in `encryptionPolicy`: it keeps encryption but doesn't ask for the PIN at boot. #### 4. Device locked with an unknown password Applies to cause 4. The **Reset password** command can't work on a Device that's already locked with an unknown password. It's an Android platform limitation that affects every MDM. 1. Check whether the lock comes from Google's **Find My Device**, which lets you set a new PIN remotely. 2. If not, factory reset the Device from recovery mode. #### 5. Factory reset from recovery mode This is the fallback when the Device can't receive commands and nobody can unlock it. 1. Turn off the Device. 2. Hold the model's physical button combination to boot into recovery mode. 3. Select the factory reset option and confirm. :::warning The button combination and the look of the recovery menu depend on the manufacturer and model; check the manufacturer's documentation. This method **wipes all local data** and, if the Policy had **Frp Admin Emails**, the Device will ask for one of those accounts when it finishes. ::: #### 6. The Device asks for a Google account after the reset (FRP) Applies to causes 8 and 9. 1. Check which accounts were in **Frp Admin Emails** in the Policy assigned to the Device before the reset (the Policy's **Security** menu). 2. Ask someone who owns one of those accounts to enter their credentials on the FRP screen during initial setup. 3. If none of those accounts is available, recovery has to go directly through Google or the manufacturer. Applivery has no remote mechanism to bypass FRP once it's active. :::warning FRP is only active on AMAPI-managed Devices if the Policy defines **Frp Admin Emails**. If the field was empty or missing, the Device has no factory reset protection. It doesn't apply to work profiles or COPE. You'll find more details in [Factory Reset Protection (FRP)](https://docs.applivery.com/en/device-management/android/policies/factory-reset-protection/). ::: #### Which fix to use by management mode | Management mode | First option | If the command doesn't arrive | |-----------------|--------------|-------------------------------| | Fully managed | Resend the command with a longer **Duration** | Physical PIN or reset from recovery mode; then FRP account if needed | | Dedicated (kiosk) | Recover the network (**Network Escape Hatch**) and resend the command | Reset from recovery mode; then FRP account if needed | | COPE | **Relinquish ownership** | Reset from the Device's Settings (can't be blocked) | | AOSP | **Disenroll** command | Reset from recovery mode | ### Prevention - **Use `ENABLED_WITHOUT_PASSWORD` in `encryptionPolicy`.** It keeps full encryption but doesn't require the PIN at boot, so Android Device Policy starts normally after a reboot and remote commands keep working. See [Encryption Policy](https://docs.applivery.com/en/device-management/android/policies/encryption-policy/). - **Define at least two accounts in Frp Admin Emails**, for example a team account and a direct manager's, so a Device doesn't get locked if one account becomes unavailable. - **Review your employee offboarding process** before turning on FRP on Devices that get reassigned often: without it, a Device can end up locked to someone who's no longer in the organization. - **Use a generous Duration** on removal or wipe commands when the Device may be offline. - **Before blocking manual changes or factory reset**, test the Policy on a pilot group and validate the full removal flow, including what happens if the command doesn't arrive. - **For non-compliance wipes**, check the **Preserve Frp** value in the **Wipe Action** before deploying the rule. See [Enforcement Rules](https://docs.applivery.com/en/device-management/android/policies/enforcement-rules/). ### If the issue persists If none of the fixes above work, open a case with support and include: - The Device's management mode and Android version. - The Device identifier in Applivery and the date of its last report. - The last command sent, with its date, its **Duration** and the status shown in the **Commands** tab. - Whether the Device rebooted and which screen it shows (PIN, FRP, kiosk, Settings). - The accounts configured in **Frp Admin Emails**, if any. --- ## URL Filtering Source: https://docs.applivery.com/en/device-management/android/troubleshooting/url-filtering/ Description: URL filter syntax reference for URLBlocklist and URLAllowlist Policies in Applivery — format rules, wildcards, and examples. TL;DR: Learn how to effectively use URL filtering with URLBlocklist and URLAllowlist policies by understanding the correct syntax and applying practical examples. Key topics: URL filter syntax, URLBlocklist policies, URLAllowlist policies, Web access control, Security policy enforcement, URLBlocklist, URLAllowlist, HTTP, HTTPS, FTP URL filtering provides IT admins with powerful tools to manage and control web access for Devices within their organization. By implementing these rules and examples, admins can ensure compliance with security Policies and regulatory requirements while enabling productive and safe internet usage for users. The format for defining filters in URLBlocklist and URLAllowlist Policies follows a specific pattern: `[scheme://][.]host[:port][/path][@query]` ### Components of a URL filter 1. **Scheme (optional)**: This field specifies the protocol used in the URL, can be `http`, `https`, `ftp`, `chrome`, etc, and must be followed by ‘**://**‘. 2. **Dot prefix (optional)**: An optional ‘.’ (dot) can prefix the host field to disable subdomain matching. 3. **Host (required)**: The host field is mandatory and represents a valid hostname or an IP address. It can also be set as ‘**\***‘. Subdomains can be matched unless disabled by a dot prefix. 4. **Port (optional)**: An optional port can be specified after the host, and it should be a valid port value ranging from 1 to 65535. 5. **Path (optional)**: It can optionally follow the port, indicating a specific location within the host. Any string can be used in this field. 6. **Query (optional)**: It comes at the end of the URL filter, consisting of key-value pairs and key-only tokens delimited by ‘&’. - Key-value tokens are separated by ‘=’. - A query token can end with ‘\*’ to indicate a prefix match. - Token order is disregarded during matching. ### Special rules and considerations - Path and query are case-sensitive. - Custom schemes are supported with restricted patterns (`scheme:*` and `scheme://*`). - If a ‘#’ reference separator is present, everything after it is ignored. - Filters are selected based on the most specific match found: - Longest host match is preferred. - Filters with non-matching scheme or port are discarded. - Longest matching path is selected. - Longest set of query tokens are selected. - If no valid filter is found, the left-most subdomain is removed from the host and filtering is attempted again. - The special ‘\*’ host matches all hosts and is searched last. - When both blocklist and allowlist filters apply, the allowlist takes precedence. - Filters with a ‘.’ prefix match only exact hosts. ### Examples - **\[“example.com”\]**: Blocks all requests to the domain “example.com” and any subdomains. - **\[“**[**http://example.com”\\\]**](http://example.com%E2%80%9D%5C%5D): Blocks all HTTP requests to the domain \[“example.com”\] and any subdomains; other schemes (e.g., HTTPS, FTP) are still allowed. - **\[“mail.example.com”\]**: Blocks requests to the domain \[“mail.example.com”\] but not to \[“[www.example.com”\\\]](http://www.example.com%E2%80%9D%5C%5D) or \[“example.com”\]. - **\[“.example.com”\]**: Blocks exactly \[“example.com”\] and won’t block subdomains. - **\[“\*”\]**: Blocks all requests; only URLs on the allowlist will be permitted. - **\[“\*:8080”\]**: Blocks all requests to port 8080. - **\[“192.168.1.2”\]**: Blocks requests to this exact IP address. :::tip Remember to test your URL filters thoroughly in a staging environment before deploying them to production. ::: --- ## Apple Source: https://docs.applivery.com/en/device-management/apple/ Description: Apple Device Management in Applivery — enroll, configure, and secure iOS, iPadOS, and macOS Devices at scale from a central Dashboard. TL;DR: Applivery simplifies Apple device management by providing a centralized platform to enroll, configure, and secure iOS, iPadOS, and macOS devices. Key topics: Apple Device Management, Applivery, Device Enrollment, Security Policies, Apple, iOS, iPadOS, macOS Applivery supports full Apple MDM for iOS, iPadOS, and macOS, enabling you to enroll, configure, and manage Apple Devices at scale. You can deploy Apps, enforce security Policies, manage supervision, distribute content, and run remote commands — all through Apple's official MDM APIs. Apple Device Management in Applivery includes platform setup, enrollment methods, App and Policy management, device commands, and troubleshooting — organized by platform (iOS/iPadOS and macOS). --- ## Apple App Management Source: https://docs.applivery.com/en/device-management/apple/app-management/ Description: Manage Apple apps across iOS, iPadOS, and macOS with Applivery. Deploy, configure, assign licenses, and enforce policies from one dashboard. TL;DR: Applivery provides a centralized platform for managing Apple apps across iOS, iPadOS, and macOS, simplifying deployment and policy enforcement. Key topics: Apple App Management, Applivery, VPP licenses, App deployment, App policies, Apple, iOS, iPadOS, macOS, VPP Apple App Management in Applivery enables you to deploy, configure, and maintain applications across iOS, iPadOS, and macOS Devices at scale. You can distribute Apps silently, assign VPP licenses, manage App configurations, and control App behavior through Policies. App distribution methods for Apple platforms include Apple Business (VPP)-purchased Apps, web clips, managed App configurations, and App blocking/allowlisting. --- ## Block & Allow Apps Source: https://docs.applivery.com/en/device-management/apple/app-management/block-allow-apps/ Description: Block or allow Apps on iOS and macOS Devices through Applivery Policies — control which Apps users can access. TL;DR: Use Applivery to control app access on iOS and macOS devices by blocking unwanted apps and allowing only approved applications. Key topics: App blocking on iOS and macOS, App allowing on iOS and macOS, Applivery MDM configuration, Mobile device security, Application management policies, Applivery, iOS, macOS, Apple, Finder, Siri, VPP, App Store Whether you’re aiming to enhance security or streamline productivity, the ability to manage which applications can or cannot run on enrolled Devices is crucial. Applivery supports two approaches: app blocking and app allowing. - **App blocking** involves the selective restriction of certain applications from executing on managed Devices. This can be particularly useful to mitigate security risks. By creating a block list, administrators can prevent specified Apps from launching, thereby safeguarding sensitive data. - Conversely, app allowing, often referred to as **whitelisting**, centers around permitting only a predefined list of applications to operate on enrolled Devices. This method is employed when organizations seek to optimize productivity by ensuring users have access to only the essential tools. By creating an App whitelist, administrators can ensure that only approved applications are available for use, minimizing potential security vulnerabilities. ### Allow a list of Apps for iOS Devices **Navigate to Policies** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), go to any of your **Policies** 1. From the left side menu, go to **Apps** 2 and click the **\+ Add App** button 3. ![add app](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/60758bac-26a3-4146-8d5a-7a02a4159e10.png) Through any of the available tabs (App Store, Applivery), you can search for and add the applications that will be part of your whitelist of applications. It is necessary to specify whether the application is intended for iOS or macOS. Additionally, you will need to indicate if the App holds a VPP license (more details available [here](https://docs.applivery.com/en/device-management/apple/app-management/vpp/)). ![](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/730a96c8-fe28-4d49-9985-2f165114cfd0.png) **Configure the Allow list** You will need to configure the **Allow / Block List** setting. From the left-hand menu, select **\+ Add configuration** 4, choose **Restrictions** 5, and navigate to the **Allow / Block List** 6 section. ![allow list](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/a813ebcb-44ab-457a-8952-267fcb446afc.png) Then, select **Allow only some Apps** 7 and add the applications that will be included in this list. ![Apps in allow list](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/da8197f4-323a-496c-859d-4b081274ecd4.png) ### Block a list of Apps for iOS Devices **Configure the Block list** Just like if you were configuring a whitelist of Apps, now you will need to select the **Do not allow Apps** 8 option. The App will be blocked, and users won’t be able to install it. ![block list of Apps](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/f1f5cf01-fa59-4f4c-a728-cff4ce0871ef.png) ### Block a list of Apps for macOS Devices :::warning Certain system Apps, such as Finder and Siri, automatically relaunch and stay open on macOS. Since these Apps attempt to open continuously, blocking them results in endless blocked-access pop-ups on the Device. ::: :::warning To block applications on macOS Devices, the Applivery MDM must be enabled at the Policy level. ::: **Navigate to Policies and Agent Settings** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), go to any of your **Policies** 1. From the left side menu, go to the **Agent** 2 section and **Enable** it 3. ![enable agent](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/934274ea-4f07-4b42-8bbd-25d397a785fc.png) You’ll then be able to create a list of Apps by clicking the **\+ Add** button. ![block list macos](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ad30d0cf-be80-4326-8864-10baea8d3b05.png) :::warning Many preinstalled Apps are located on the [signed system volume](https://support.apple.com/en-gb/guide/security/secd698747c9/web), making them impossible to delete. However, you can remove them from the Dock using a Policy, and if a user tries to open one, an alert will notify them that the App cannot be launched. ::: :::info Blocking an App and blocking its website are different controls, and a service is only really out of reach when you do both. For the web side, see [Block or Allow URLs in Safari](https://docs.applivery.com/en/device-management/apple/ios-ipados/policies/web-content-filter/) on iPhone and iPad, and [Block or Allow URLs in Chrome and Safari](https://docs.applivery.com/en/device-management/apple/macos/policies/block-allow-urls-chrome-safari/) on Mac. ::: --- ## Manage Apps Source: https://docs.applivery.com/en/device-management/apple/app-management/manage-apps/ Description: Manage Apple App Store, VPP, and in-house apps on iOS/macOS with Applivery. Learn deployment, configuration, and remote updates. TL;DR: Learn to manage Apple apps (App Store, VPP, in-house) on iOS/macOS using Applivery MDM, including deployment, configuration, and scripting. Key topics: Apple App Store app management, Apple Volume Purchase Program (VPP) integration, In-house app distribution with Applivery, macOS app management and scripting, Supervised vs. Unsupervised Apple device management, Apple, Applivery, iOS, macOS, Apple App Store, Apple Volume Purchase Program (VPP), MDM, .ipa files, Apple Business Before starting, let’s describe all types of Apps that you can find in the Apple ecosystem: ### Apple App Store Apps Applivery administrators can remotely push Apps from the Apple App Store to manage Apple Devices. It requires that the App is available in the App Store and the user must sign in with his/her Apple ID account to accept the installation. For [Supervised Devices](https://docs.applivery.com/en/device-management/apple/supervision/), Apps can be silently installed in the background without the user's acceptance. 4 main types of Apps can be deployed to Apple Devices: - **Free Apps:** Publicly available on the App Store and free for download. - **Licensed Apps:** Publicly available on the App Store but not free; they require purchase. - **Custom Apps:** Created by companies for internal use or private distribution. These Apps must be uploaded to the Apple Store as **Custom Apps** and managed through Apple Business. - **Apps that are not yet available on the App Store** (primarily for macOS Devices). There are three installation types available for applications.: - **Force installed**: The App will be force-installed. - **Required for setup**: The App will be automatically installed and cannot be removed by the user. It will prevent setup from completion until installation is complete. - **Available**: The App will be available to be installed on-demand, either from the dashboard or using the Self-Service App on macOS Devices. Additionally, you will be able to create a configuration dictionary for the App. ### Apps purchased via Apple Volume Purchase Program (VPP) Additionally, Apple provides the Apple Volume Purchase Program to purchase App and book licenses, and install company-private Apps to managed Apple Devices running iOS and macOS. You can read more about the Apple VPP [here.](https://docs.applivery.com/en/device-management/apple/app-management/vpp/) ### In-house distribution (.ipa files) - **Enterprise Apps:** These Apps are signed with an Apple Enterprise Developer certificate designed for internal use and in-house distribution. Typically, they are distributed through alternative methods such as Applivery App Distribution or deployed to Devices via an MDM like Applivery Device Management for Apple Devices. It’s worth noting that Apple is phasing out this distribution method in favor of Custom Apps, which involves an application process. - **AdHoc Apps:** This less common type of App is usually created for testing purposes and internal distribution only. They are restricted to a defined set of Devices through the inclusion of their UDIDs in the provisioning profile. #### How to install In-house Apps **Install at Device level** The App will be installed on individual target Devices. - **Assign an App Build** by **c**licking the **\+ Assign App** button 1. - **Install a** `.ipa` **file:** By clicking the **Install from file** button 2, you can either select a `.ipa` file previously uploaded to the **Resources** section or install it directly from your Device using the **Upload new resource** button. ![app device level](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ce886419-4da9-47c5-bd94-fdf39f82b5cb.png) :::info If you are interested in learning how to install `.pkg` files on your macOS Devices, explore our detailed [documentation](https://docs.applivery.com/en/device-management/apple/macos/app-management/pkg-deployment/) for guidance. ::: **Install at Policy level** The App or Apps will be installed on all Devices associated with a specific Policy. Once in the [**Applivery Dashboard**](https://dashboard.applivery.io), go to any of your **Policies** 1. From the left side menu, go to **Apps** 2 and click the **\+ Add App** 3 button. ![add app](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/0d4412fb-9016-44f9-9854-5cd4dd5216bb.png) Locate the **Applivery** tab 4, then select **Your Workspace** 5 as the App origin. ![app from your Workspace](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/aee672dc-77c5-4edb-a15e-b6beb9334d10.png) **Install from Applivery macOS App Catalog** Designed for Apps not available on the Mac App Store, these can be added by selecting **App Catalog** as the App origin. For more details, refer to our in-depth documentation [here](https://docs.applivery.com/en/device-management/apple/macos/app-management/app-catalog/). ![Apps from app catalog](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/f2f51598-a224-42db-90aa-a0dc2bae972e.png) #### Pre- and Post-install Scripts for In-house Apps ![scripts-in-house-Apps](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/cf079682-79de-485f-b204-a04fe89585a0.png) For macOS Devices, you can include pre- and post-installation scripts for specific In-house Apps (available in the Applivery tab, either from **Your Workspace** or the [**App Catalog**](https://docs.applivery.com/en/device-management/apple/macos/app-management/app-catalog/)). These scripts can be loaded when adding the App, either at the Policy level or the Device level. However, they will not be visible in the Resources section and will only be accessible within the specific App associated with the script. - If the App has been assigned to a specific Device, navigate to the Device, go to the **Apps** section, locate the App, click on the vertical three-dot **(⋮)** button, and select **Edit**. - If the App was installed through a Policy, navigate to the Policy and select the **Apps** section from the left-hand menu. Locate the App, then click the Settings icon in the App’s **Source** section. ![app install scripts](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/8a42de87-749e-46ca-9512-0b6893c1d765.png) The following types of scripts can be added to an App: - **Enforce script**: Check if the App should be installed again. - **Audit script**: Check if the App can be installed. - **Pre-script**: Execute actions before the App installation. - **Post-script**: Execute actions post-App installation. ### Apps management Now that we have a clearer view of the different types of Apps, let’s take a look at the main App Management capabilities you will find in Applivery and some requirements that you must take into consideration depending on whether the target Devices are [supervised](https://docs.applivery.com/en/device-management/apple/supervision/) or not: | Feature | Supervised mode ON | Supervised mode OFF | | --- | --- | --- | | Deploy Apps | ✅ | ✅ | | Deploy paid Apps | ✅ | ✅ | | Deploy Apps silently | ✅ | ❌ It requires an Apple ID login | | Configure Apps remotely | ✅ | ✅ | | Update Apps remotely | ✅ | ✅ | | Uninstall Apps remotely | ✅ | ✅ | --- ## VPP Source: https://docs.applivery.com/en/device-management/apple/app-management/vpp/ Description: Use Apple's Volume Purchase Program (VPP) with Applivery to manage App licenses and streamline App deployment on iOS and macOS Devices. TL;DR: Apple's Volume Purchase Program (VPP) simplifies app and book license management for iOS and macOS devices, and Applivery streamlines the configuration and deployment process. Key topics: Apple Volume Purchase Program (VPP), Applivery integration, App assignment methods, Apple Business, License management, Apple, Applivery, iOS, macOS, VPP The management of licensed Apps and books on behalf of your managed users and Devices implies Apple for the purchase process through [Apple Business](https://business.apple.com/) (even for free Apps and Books if you want to control the number of units distributed to your users). Once purchased, these Apps and books can be managed from the Applivery Dashboard and assigned to registered users and Devices by their Device serial number or to the entire list of Devices registered for a given user. After the licenses have been assigned, administrators can deploy Apps and books to a Device or a set of Devices. :::info Once VPP app licenses are owned by the company, licenses can be assigned, revoked, and re-assigned to users or Devices at any time. This eliminates the need for a shared Apple ID account, and, if desired, the need for an employee to use an Apple ID on the Device at all. ::: ### When a license fails to assign An `ASDServerErrorDomain` error with code **9610** comes from Apple's side, and it means the VPP license was not found. The usual cause is a **VPP token shared between more than one MDM**. Each one keeps its own view of which licenses are assigned, the two drift apart, and Apple ends up rejecting an assignment that Applivery believes it still holds. Use one token per MDM. ### VPP does not require the Device to be in Apple Business Apple Business is easy to read as a single thing. It is two independent functions sharing one portal, and only one of them cares about your Device inventory.

Function

What it manages

Device must be in Apple Business?

Automated Device Enrollment

Device inventory and automatic enrollment

Yes

Apps and Books (VPP)

Licenses purchased by the organization

No

The VPP token is tied to an **organization location**, not to a set of Devices. In device-based assignment the MDM sends the serial number to the VPP service, and Apple registers the license against it without checking the Automated Device Enrollment inventory. So an iPad prepared with Apple Configurator, supervised and enrolled, receives VPP Apps even if it was never added to Apple Business. :::info **Supervision does not enable VPP either.** What supervision buys you is a silent install, with no user interaction. ::: ### Assignment methods There are 3 main ways to assign Apps or Books: - **Device-Based Assignment**: With device-based assignment, app licenses are assigned to a Device by serial number rather than to an Apple ID. One license will be allocated for each Device the App is installed on. With this method, Apps will remain on Devices regardless of the Apple ID in use, if any. On supervised iOS Devices, this method allows Apps to be installed without prompting or notifying the user. Businesses looking for a Zero-touch deployment process will find this to be particularly beneficial. - **User-Based Assignment**: When VPP Apps are deployed with user-based assignment, device users will be prompted to enter an Apple ID if one is not already present on the Device and be invited to join the VPP program of the company. While this requires more user interaction than device-based licensing, it is useful in situations where a single user will be utilizing multiple Devices. The App license is automatically enabled across all Devices that are using the same Apple ID. As a result of this process, only one single license will be used from the total number available in the VPP account. - **Redemption Codes**: App licenses can be distributed to Apple IDs using redemption codes, where a code can be redeemed once by an Apple ID for a particular app license. Users will be prompted to enter a code to redeem the purchase and complete the installation of the App. After entering the redemption code, ownership of the App license is transferred permanently to that user ID. These codes are delivered in a spreadsheet format and can be distributed to users through various methods, including: assigning them via Applivery, sending a URL by email, assigning them to Devices through Apple Configurator, or providing codes to users manually. When used with Applivery, Applivery will automatically redeem the codes for users when Apps are installed. ### How to configure Apple Volume Purchase Program (VPP) in Applivery Applivery provides a seamless integration with the Apple Volume Purchase Program (VPP) for purchasing app and book licenses and installing company-private Apps to managed Apple Devices running iOS and macOS. 1. You already own an [Apple Business](https://business.apple.com/)\-approved account for your organization. 2. You have an active Applivery Apple Device Management license. If that’s the case, the next steps are: **Get your Apple Business token** Sign in to [Apple Business](https://business.apple.com/) as a user who has the role of Administrator or Content Manager. Open your **organization’s dropdown menu**, select **Settings** 1, and from the left-hand menu, click on **Organizational Units** 2. Then click **Add** 3 to start creating your VPP location. ![create organisational units](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/33ddd1cd-11a7-43d9-a921-46cb52245550.png) Once it’s created, navigate to the **Payments & Billing** 4 section. Under **Content Tokens**, download the token 5 for the Organizational Unit you just created. ![content tokens](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/cd331e67-5688-4de2-8790-229a377e8325.png) :::info Apple provides a location-based token system. If you need to configure a new location, go to **Locations** and click **Add new location**. ::: **Configure VPP in Applivery** From the [**Applivery Dashboard**](https://dashboard.applivery.io/), go to the **Settings** section 1 and locate **Apple VPP** 2 in the left-hand menu. Click the **Manage locations** button, and then click **\+ Associate location** and upload the downloaded token from the previous step (`.vpptoken`). ![vpp location](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ab95c84c-f295-47e5-9844-3f1efb00ae82.png) Finally, click **Save** to finish. The new token will be created. **Get or purchase an App or book licenses from Apple Business** Purchase the necessary licenses through the Apple Business portal. **Sync the purchased licenses in Applivery** Sync the licenses within the Applivery Dashboard to reflect the purchases made in Apple Business. **Deploy licensed Apps to Devices** Deploy the purchased and synced licenses to the managed Devices through the Dashboard. --- ## Web Clips Source: https://docs.applivery.com/en/device-management/apple/app-management/web-clips/ Description: Create & configure Web Clips on iOS & macOS using Applivery. Streamline website access, customize home screen layouts, and manage access. TL;DR: Learn how to create and configure Web Clips on iOS and macOS using Applivery for quick website access and customized home screen layouts, including whitelisting options. Key topics: Web Clip Creation, Home Screen Layout Customization, Web Clip Management, Applivery Configuration, Applivery, Web Clips, iOS, macOS, iPhone, iPad, Apple Applivery streamlines and automates the creation of Web Clips, shortcuts to websites on Apple Devices. Web Clips can be added to the Home Screen of both iPhone and iPad Devices, as well as to Mac computers for individual users, offering swift access to favorite web pages or links. To learn more about this topic, you can find additional information [here](https://support.apple.com/en-gb/guide/deployment/depbc7c7808/web). ### Create and configure Web Clips **Navigate to Policies** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io), navigate to any of your **Policies** 1. From the left side menu, select the **\+ Add configuration** section and choose **Web Clip** 2. ![web clip](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/0cfe08aa-7d6b-42c6-8a83-f9beb9edd88f.png) **Add Web Clip Configuration** You will need to define mandatory fields such as the **label** and the **weblink URL**. Additionally, you can customize the image that will appear on Devices and apply further configuration settings. ![web clip configuration](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/865da68e-207e-436e-b4ef-f803df792b29.png) ### Customizing the Home Screen Layout **Access Home Screen Layout Configuration** If you do not customize your Device’s Home Screen Layout, Web Clips will be placed on the last screen, using the remaining available spaces following all the installed Apps. Alternatively, you have the option to personalize your Device’s Home Screen Layout by accessing the **\+ Add configuration** again and selecting **Home Screen Layout** 3 for a more tailored arrangement of Web Clips and Apps. ![home screen layout](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/26012923-48a8-4c72-935a-f26041dc4804.png) **Configure Web Clip Position** Within this section, you can determine the position on the display to showcase your Web Clip. Click on the **+** area 4, select the **WebClip** section 5, and choose a configured Web Clip from the list or create a new one. ![web clips in home screen layout](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/a1417944-3047-42ef-981c-c9bb39685f53.png) **Rearrange and Edit Web Clip Properties** If you want to create a customized arrangement, you can easily rearrange the positions of Apps, Web Clips, or Folders by clicking and dragging an element to your desired location. The remaining Apps will automatically align themselves after these adjustments. Once you’ve added the desired Web Clip, you’ll have the option to edit its properties within this section. If you require to configure additional Web Clips, you can easily generate new ones by selecting **create a new one**. ### Adding Web Clips to the White or Block List Enabling a **White List** involves allowing only specific Apps or web clips while restricting access to all others. By creating a White List, you establish a predefined set of trusted and approved sources that users can access without restrictions. Similarly, enabling a **Block List** prevents access to specific Apps or web clips while allowing all others, helping you restrict unwanted content without limiting overall device functionality. To set up either list, follow the steps described in our documentation [here](https://docs.applivery.com/en/device-management/apple/app-management/block-allow-apps/). --- ## Commands Source: https://docs.applivery.com/en/device-management/apple/apple-commands/ Description: Apple Device Management commands in Applivery — send real-time actions to iOS, iPadOS, and macOS Devices from a centralized Dashboard. TL;DR: Send real-time, one-off actions to enrolled Apple Devices from the Applivery Dashboard. Key topics: Apple commands, Remote device actions, Device management, Applivery, Apple, iOS, iPadOS, macOS Apple commands in Applivery let you act on an enrolled Device right now, without waiting for a Policy to sync. From the **Commands** tab on any Device detail page you can send a one-off action and see its result in the Dashboard. These commands work across Apple platforms. Commands exclusive to one platform are in the iOS/iPadOS and macOS sections. --- ## Default Applications Source: https://docs.applivery.com/en/device-management/apple/apple-commands/default-applications/ Description: Send a command to Apple Devices to set which App the system uses by default for calling, messaging and web browsing. TL;DR: Send the Settings command from an Apple Device's detail page to set the default calling, messaging and browser Apps by bundle identifier. Calling and Messaging need iOS/iPadOS 26.0+; Web Browser reaches further back. Key topics: Default Applications command, Bundle identifiers, Supervised device restrictions, Requirements and troubleshooting, Applivery, Apple, iOS, iPadOS, macOS, APNs On Apple platforms, which App answers a call, opens a message or handles a link has always been the user's choice. Applivery lets you make that choice for them: from the Device detail page you can send a command that sets the default App for **calling**, **messaging** and **web browsing**, by passing each App's bundle identifier. This is a one-off command, not a persistent Policy. It sets the defaults at the moment you send it. ### Send the command **Open the Device** In the [**Applivery Dashboard**](https://dashboard.applivery.io), go to **Devices** 1 and open the detail page of the Apple Device you want to configure. **Create a new command** Select the **Commands** 2 tab and click **\+ New command** 3. ![commands](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/f26dea33-bb93-4dd1-aa6a-397ab70404b2.png) **Choose Settings** From the list of available commands, select **Settings**, then select **Default Applications**. **Review the available fields** The panel that opens shows three fields, each with the platforms and minimum versions it supports. ![default apps](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/2ec7b83c-119a-4590-8cbc-2ac1e5b2ca28.png)

Field

What it does

Minimum compatibility shown

Calling

Bundle identifier of the App the system uses as the default calling App. It has to be an App eligible for calling.

iOS/iPadOS 26.0

Messaging

Bundle identifier of the App the system uses as the default messaging App. It has to be an App eligible for messaging.

iOS/iPadOS 26.0

Web Browser

Bundle identifier of the App the system uses as the default web browser. It has to be a browser App eligible for the Device's region.

iOS/iPadOS, macOS (10.12 Sierra+), tvOS, watchOS, visionOS

:::info You only need to fill in the field you want to configure. The three are independent of each other. ::: **Enter the bundle identifier** Type the **bundle identifier** of the target App in the matching field. Some common values for the Web Browser field:

Browser

Bundle ID (iOS/iPadOS)

Safari

com.apple.mobilesafari

Google Chrome

com.google.chrome.ios

Microsoft Edge

com.microsoft.msedge

Firefox

org.mozilla.ios.Firefox

**Send it** Click **Send** to push the command to the Device. :::warning The target App has to be **installed** on the Device before you send the command, and it has to be able to handle the matching content type — calls, messages, or `http` and `https` schemes, depending on the field. That validation is done by the operating system, not by Applivery. The safest approach is to add the App to the Policy as a forced install. ::: ### How it works on Apple's side This maps to Apple's native `Settings` MDM command with the `DefaultApplications` item, which Apple added to its MDM protocol so default Apps could be set remotely. Unlike configurations that ship as profiles — a `.mobileconfig` with a `PayloadType` — this is a **one-off command** delivered over APNs. Nothing stays installed on the Device as a persistent profile. #### Stop users changing the browser back The command sets the default browser at the moment you send it, but the user can change it again from **Settings > Apps > Default Apps**. To prevent that, Apple exposes an additional restriction inside the `com.apple.applicationaccess` payload: ```xml allowDefaultBrowserModification ``` ![allow browser modification](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/fce0ac31-1ad6-41ce-92c0-06a317206060.png) :::warning This restriction only takes effect on **supervised Devices**. On unsupervised Devices the command to set the browser still works, but the user will always be able to change it afterwards. ::: ### Requirements

Requirement

Detail

Minimum OS — Calling and Messaging

iOS/iPadOS 26.0 or later

Minimum OS — Web Browser

iOS/iPadOS, macOS 10.12 Sierra or later, tvOS, watchOS, visionOS. Check the command panel for the exact detail per platform.

App installed

The target App has to be installed on the Device before you send the command

Mechanism

A command sent from the Device detail page, not a persistent configuration profile

Connectivity

The Device has to be online and responsive to receive the command

### Troubleshooting

Situation

Likely cause

The command is sent but the default App does not change

The target App is not installed, or its bundle ID does not exactly match the one registered in the App Store

The Calling or Messaging field has no effect

The Device runs a version of iOS/iPadOS earlier than 26.0

The command never reaches the Device

The Device is offline or not responding to MDM at the time you send it

--- ## Apple MDM Source: https://docs.applivery.com/en/device-management/apple/apple-mdm/ Description: Apple MDM with Applivery — overview of Apple Business, DEP, VPP, supervision, and iOS/macOS Device Management fundamentals. TL;DR: This guide introduces Apple Device Management concepts like Apple Business Manager, DEP, and VPP, explaining how they work with Applivery to simplify Apple device deployment. Key topics: Apple Business, Device Enrollment Program (DEP), Volume Purchase Program (VPP), Supervision Mode, Apple Configurator, Apple, Applivery, Device Enrollment Program, Volume Purchase Program, iOS, tvOS, MacOS ### Apple Device Management Overview Apple has a set of programs and solutions created to simplify and speed up the configuration of Devices as well as the deployment of applications and content. ### Supported Devices Apple Device Management support for Apple Devices covers all types of Apple Devices: - iPhones. - iPads. - MacBooks and iMacs. - Apple TV. - Apple Watch. ### Apple Business [Apple Business](https://business.apple.com/) is a web-based portal for IT administrators to deploy iPhone, iPad, iPod touch, Apple TV, and Mac all from one place. Working seamlessly with other MDM solutions like Applivery, Apple Business makes it easy to automate device deployment, purchase Apps and distribute content, and create Managed Apple IDs for employees. The [Device Enrollment Program (DEP)](https://docs.applivery.com/en/device-management/apple/enrollment/dep/) and the [Volume Purchase Program (VPP)](https://docs.applivery.com/en/device-management/apple/app-management/vpp/) are completely integrated into Apple Business, so organizations can bring together everything needed to deploy Apple Devices. ![apple mdm](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/5e4fe867-0824-4dd5-888e-b4a2c656b0c0.png) #### Device Enrollment Program (DEP) Apple Device Enrollment Program (also known as **DEP**) is a tool integrated into Apple Business that allows organizations to fully automate the enrollment process of Apple Devices in MDM solutions like Applivery. In the beginning, it was focused on new Devices, but starting with iOS 11, it now supports enrolling already purchased Devices as well. DEP helps organizations enable supervision, MDM enrollment, skip setup steps, and many other features. You can read more about Apple DEP [here](https://docs.applivery.com/en/device-management/apple/enrollment/dep/). #### Volume Purchase Program (VPP) Apple Volume Purchase Program (also known as **VPP**) is another tool integrated into Apple Business that allows organizations to automate app and book license purchasing. Once they are purchased, these Apps and books can be managed from the Applivery Dashboard and assigned to registered users and Devices by their Device serial number or to the entire list of Devices registered for a given user. After the licenses have been assigned, administrators can deploy Apps and books to a Device or a set of Devices. You can read more about Apple VPP [here](https://docs.applivery.com/en/device-management/apple/app-management/vpp/).  :::warning **Managed Apple Accounts cannot add payment cards to Wallet.** Enabling Wallet in Apple Business lets the App open, but it does not enable adding cards — neither manually nor through an "add to Wallet" interface. Employee badges and IDs do work. ::: ### Other Important Concepts #### Supervision Mode Some Apple Devices (iOS and tvOS) can be configured in a special mode called **supervised mode** that grants MDMs additional control over the Devices with advanced privileges over Apps, lock mode, web content, and many other features. Supervision mode requires a factory reset or new Devices that are configured through Apple Configurator or Apple Device Enrollment Program (DEP). You can read more about what supervision is and how to activate supervision mode [here](https://docs.applivery.com/en/device-management/apple/supervision/). #### Apple Configurator App Apple provides two Apps that will help you take advantage of the Apple Device Enrollment Program by registering your Devices in your Apple Business account. - [**Apple Configurator (for Mac)**](https://apps.apple.com/app/id1037126344) is a MacOS app that makes it easy to deploy iPad, iPhone, iPod touch, and Apple TV Devices in your school or business. It automatically registers your Devices in Applivery and your Apple Business account. - [**Apple Configurator (for iPhone)**](https://apps.apple.com/us/app/apple-configurator/id1588794674) is an App that makes it easy to assign any Mac with the T2 Security Chip or Apple Silicon to your Apple Business organization and manage it through Applivery. You can read more about both Apps [here](https://docs.applivery.com/en/device-management/apple/enrollment/apple-configurator/). ### Next Steps Now that the main concepts are a bit clearer, we suggest following the next steps: **Determine Supervision Needs** Determine whether you will need device [supervision privileges](https://docs.applivery.com/en/device-management/apple/supervision/). **Select Enrollment Method** Select the [enrollment method](https://docs.applivery.com/en/device-management/apple/enrollment/enrollment-methods/) that best fits your feature requirements and deployment workflow. **Plan App Deployment** Plan your organization’s app deployment strategy. **Choose Apple ID Usage** Choose whether or not to use Apple IDs in your deployment. --- ## Policies Source: https://docs.applivery.com/en/device-management/apple/apple-policies/ Description: Apple Device Management Policies in Applivery — create and enforce Policies across iOS, iPadOS, and macOS Devices from a centralized Dashboard. TL;DR: Applivery simplifies Apple device management by providing a centralized dashboard to create and enforce policies across iOS, iPadOS, and macOS devices. Key topics: Apple device management, iOS policies, iPadOS policies, macOS policies, Applivery, Apple, iOS, iPadOS, macOS Apple Policies in Applivery let you define and enforce configurations across iOS, iPadOS, and macOS Devices. From password requirements and restriction profiles to certificates, VPN, and Wi-Fi settings, Policies give you granular control over every enrolled Device. Policy settings for Apple platforms include both shared and platform-specific options. --- ## Activation Lock Source: https://docs.applivery.com/en/device-management/apple/apple-policies/activation-lock/ Description: Centrally control Activation Lock on supervised Apple Devices with Applivery — enable strong protection and simplify Device recovery. TL;DR: Applivery allows IT admins to centrally control Activation Lock on supervised Apple devices, ensuring security and easy recovery. Key topics: Activation Lock, Apple MDM, Device Management, Applivery, Apple, Apple Business **Activation Lock** is a built-in Apple security feature designed to prevent unauthorized use of Apple Devices if they are lost, stolen, or erased. When enabled, it ties the Device to an Apple ID and requires those credentials to reactivate the Device after a reset. In corporate environments, Activation Lock can be both a powerful security mechanism and a potential operational challenge if not properly managed. Applivery allows IT administrators to centrally control Activation Lock on supervised Apple Devices, ensuring strong protection while maintaining administrative ownership and recoverability. ### What is Activation Lock? Activation Lock is part of Apple’s **Find My** framework and is automatically enabled when Find My is active on a Device. Once enabled: - The Device cannot be reactivated without the associated Apple ID credentials. - Erasing the Device does not remove the lock. - The feature protects against unauthorized resale or reuse. On unmanaged Devices, Activation Lock is tied to the user’s personal Apple ID. In managed environments, this behavior can be controlled through MDM. ### Activation Lock in managed Apple Devices When Devices are [supervised](https://docs.applivery.com/en/device-management/apple/supervision/) and [enrolled via Apple Business](https://docs.applivery.com/en/device-management/apple/enrollment/dep/) (Apple Business), Activation Lock can be managed by the organization instead of the end user. With Applivery, administrators can: - Enable Activation Lock with institutional control. - Bypass Activation Lock when recovering or redeploying Devices. - Prevent users from enabling personal Activation Lock. - Retrieve or escrow bypass codes securely. This ensures that Devices remain protected without risking permanent lockout. ### How Activation Lock works with Applivery Applivery uses Apple’s official MDM commands to manage Activation Lock behavior on supervised Devices. When enabled, Activation Lock can be owned and controlled by the organization, a bypass code is automatically generated and securely stored, and administrators can remove Activation Lock remotely whenever required. To allow enabling Activation Lock in Applivery, navigate to **Devices** in the [**Applivery Dashboard**](https://dashboard.applivery.io/) and select the target device. Then open the **Settings** 1 section and select the **Activation Lock** 2 tab. In the **State** section, click **Allow** 4 to allow activating the feature. ![activation lock](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/7e5bf9e9-80e7-440e-aa29-ddd42366a810.png) Once enabled, the Bypass section provides the available recovery options. Administrators can **clear Activation Lock manually using the stored bypass code** or **remove it remotely through the Applivery API**. ![bypass](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/19e75c82-394b-4f82-8f93-95821ce60009.png) :::info Activation Lock can also be allowed in bulk by using [Apple Smart Enrollments](https://docs.applivery.com/en/device-management/apple/enrollment/smart-enrollment/), allowing organizations to apply this setting automatically during large-scale device enrollments. ::: ### How to disable Activation Lock using Apple Business Apple has introduced a new capability in Apple Business and Apple School Manager (ASM) that allows administrators to disable Activation Lock on managed Devices directly from the portal, without needing to enter a bypass code on the Device. This provides a practical alternative to manually entering codes and is especially useful if a user has enabled Activation Lock through iCloud or Find My. To use this feature, [sign in to your Apple Business](https://business.apple.com/) or ASM portal and locate the Device for which you want to remove Activation Lock. Select the **device**, and select **Turn Off Activation Lock**. ![activation lock ab](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/1ad503e1-129b-4f8e-97cf-439663dffa2a.png) :::info If the Device is currently displaying the Activation Lock screen, the command will remove the lock, but **a restart may be required** for the change to take effect. ::: ### Important considerations Activation Lock should be used as part of a broader device lifecycle strategy: - Devices enrolled without Apple Business may still be locked to user Apple IDs. - If personal Activation Lock is allowed, recovery may require user cooperation. - Institutional Activation Lock ensures recoverability without Apple intervention. - Proper enrollment and supervision are critical for successful management. ### Device state support for turning off Activation Lock The following device states determine whether you can turn off Activation Lock. | Device state | User Interface | Can Activation Lock be turned off in Apple Business? | Can Activation Lock be turned off in Applivery? | | --- | --- | --- | --- | | User-based Activation Lock turned on | Activation Lock On (User) | ✅ | ❌ | | Organization-based Activation Lock turned on | Activation Lock On (Organization) | ✅ | ✅ | | Managed Lost Mode turned on by the Device management service | Activation Lock On (Organization) | ✅ | ✅ | | Lost Mode turned on by the user | Activation Lock On (User) | ✅ | ❌ | Activation Lock is a key security feature for Apple Devices, but in enterprise environments, it must be carefully managed to avoid device lockouts and operational disruptions. With Applivery, IT teams can centrally control Activation Lock using Apple’s official MDM framework, ensuring Devices remain secure, recoverable, and fully under organizational control throughout their lifecycle. --- ## Agent Source: https://docs.applivery.com/en/device-management/apple/apple-policies/agent/ Description: The Applivery Apple Agent for macOS and iOS — advanced MDM features, Self-Service options, geolocation reporting, and App Management. TL;DR: The Applivery Apple Agent extends MDM capabilities on macOS and iOS with features like self-service, geolocation, and app management. Key topics: macOS Agent Self-Service, iOS Agent Geolocation, App Blocklisting, Agent Configuration, Apple, Applivery, macOS, iOS, App Store, Apple Business, VPP (Volume Purchase Program) ![agent overview](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/7eb7f04e-c298-4cbb-9be3-f55eb014aa6b.png) The Apple Agent is a software that can be installed on the Devices of an organization. Its purpose is to empower Applivery to enhance its capabilities, extending beyond Apple’s MDM protocol and unlocking advanced management functionalities. Before deploying the Applivery Agent, it is essential to understand the guidelines and requirements set forth by Apple to ensure compliance and optimal functionality. ### Agent App for macOS Devices The use of macOS Agent provides additional functionality and advanced management capabilities that are not available through the use of Apple APIs. This allows a deeper customization and more complete management of macOS Devices in an enterprise environment. It provides a series of extra functionalities for both the user, who owns the Device, and the IT administrator, who manages the corporate device fleet. **Self-Service** Self-Service for macOS stands as a native Swift application designed to provide the Apple experience your users expect. Its core functionality revolves around enhancing IT operational efficiency by equipping users with the necessary tools to independently address common requests, thereby offloading tasks from administrators. Through seamless integration into managed Devices, Self-Service facilitates automatic deployment, establishing a dedicated platform for users. Within this environment, users gain access to a curated repository of resources, empowering them to efficiently fulfill their needs. ![self-service-app-store | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/7b648958-9ada-4407-9dc0-247bdd9a9ca8.png "self-service-app-store | Applivery") ##### 1.1 App Catalog Admins can designate applications for end users to install on demand. For detailed guidance on managing applications and licenses, please refer to our [documentation](https://docs.applivery.com/en/device-management/apple/macos/app-management/app-catalog/). ##### 1.2 Actions Grant your end-users the ability to execute scripts for task assistance or Device issue resolution. The results of these executions will be automatically reported to the Applivery Dashboard. You can find out how to assign a Script to Self Service [here](https://docs.applivery.com/en/device-management/apple/macos/scripts/). ##### 1.3 Bookmarks You can use bookmarks to provide your users with easy access to specified webpages directly. When you make a bookmark available in Self-Service, you can customize how the bookmark is displayed to users. This includes customizing the bookmarks label, uploading a custom icon, and adding a description. To configure bookmarks, navigate to any of your **Policies** 1 within the [**Applivery Dashboard**](https://dashboard.applivery.io/). In the left-hand menu, click on **Bookmarks** 2, then click the **\+ Add Bookmark** button 3 to begin adding bookmarks to your Self Service. ![bookmarks](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/65cd1cf0-2e0c-43bc-8aa1-fb5fd1a449fc.png) ##### 1.4 Status reporting The Agent offers detailed reports on macOS Device status and performance, enabling IT administrators to make informed management decisions. This optional reporting feature can be activated directly through the Agent, providing administrators with additional insights. Track the reports sent to the Applivery Dashboard regarding battery status, Bluetooth activity, and system information. ![agent](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/9cba3a77-1d5e-4b34-bdcd-a4861a8debc2.png) **Enabling macOS Agent App** Applivery macOS Agent App blocklisting feature offers the advantage of managing both user-installed Apps and pre-installed Apps on the Device. App blocklisting enables the selection of non-compliant Apps, ensuring their removal if installed or preventing their installation in the future. Non-compliant Apps refer to those not distributed via Applivery, whereas corporate Apps distributed through the product are classified as managed Apps. In this context, IT administrators must prevent non-compliant Apps from accessing or sharing corporate data. To configure an App blocklist, follow the steps described in the [following article](https://docs.applivery.com/en/device-management/apple/app-management/block-allow-apps/#block-a-list-of-apps-for-macos-devices) in our documentation. Navigate to any of your **Policies** 1 within the [**Applivery Dashboard**](https://dashboard.applivery.io/). In the left-hand menu, click on **Agent** 2 and **enable** 3 the macOS Agent. ![agent](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/793c8271-4dca-4f29-8c52-2fe31367fe98.png) ### Agent App for iOS Devices **Self-Service** ![self service portal](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/5f1f41e8-ba5f-44c0-9f60-a26be65ee659.png) After setup, the user arrives at the Self-Service Portal — the main user-facing interface of the Agent. ##### Layout The portal has three main elements: - **Top bar**: Shows the current section name. On the left, a menu icon opens the navigation drawer. Inside detail screens (such as an App detail page), the menu icon is replaced by a back arrow. - **Content area**: Displays the active section (Applications, Bookmarks, Status, etc.). - **Navigation drawer** — A side panel that slides in from the left. Lists all enabled sections and allows switching between them. ##### Which Sections Are Visible? The sections shown in the navigation drawer depend on what the administrator has enabled via managed configuration. Only active sections appear in the menu. If no features are configured, the portal defaults to showing the **Status** section so the user always has visibility into the Device's management health. ![status](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/233e6e30-075f-4080-8973-51d037ff43fa.png) #### Applications The Applications section is the core feature of the Self-Service Portal. It allows users to browse, install, update, and uninstall corporate applications assigned to their Devices. The section is organized into three tabs. ![home screen](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/a6091cb8-fe3a-4ebb-9921-8a93c1e72b91.png) ##### Home Tab The Home tab is the landing view of the Applications section, providing a quick overview: - **Applications preview**: Shows up to four of the user's Apps, prioritizing those not installed. Each App displays its icon, name, category, and an action button (Open, Install, or Update). Tap **View All** to navigate to the My Apps tab. - **Feature shortcuts**: A grid of cards linking to other enabled Self-Service sections (Bookmarks, Status, etc.) for quick access without opening the navigation drawer. - **Pull to refresh**: Pull down on the screen to refresh the application list from the server. ##### My Apps Tab Shows a complete list of all managed applications currently installed on the Device, plus any currently being installed. Each App displays: - Icon, name, and category. - An action button: **Open** (installed and up to date), **Update** (newer version available), or an animated progress indicator (currently installing). If no managed Apps are installed, the screen displays: _"No applications installed."_ ##### App Detail Page Tapping any application opens its full detail page, which includes: - **Header**: Large app icon, application name, and publisher name. - **Compatibility warning**: If the App requires a newer Android version than the Device is running, a _"Not compatible with this Device"_ warning appears, and the Install button is disabled. - **Action buttons**: Vary based on the App's current state: | App State | Available Actions | | --- | --- | | Not installed | **Install** | | Not installed (incompatible) | **Install** (disabled) | | Installed | **Uninstall** and **Open** | | Update available | **Uninstall** and **Update** | | Installing in progress | Animated loading indicator (no buttons) | - **Screenshots**: A horizontally scrollable carousel. Tapping a screenshot opens it in a full-screen viewer with swipe navigation. - **About this App**: Application description, initially truncated to three lines. Tap to expand or open a dedicated full-screen reading view. - **Information**: Metadata including Author, Category, Compatibility, Age Rating (PEGI: 3+, 7+, 12+, 16+, or 18+), and Version number. ##### Search The Applications section includes a search feature, accessible via the search icon in the top bar. It provides a real-time filtered list of Apps as the user types, matched against the application name (case-insensitive). Each result has an action button for quick install/open/update actions without visiting the detail page. ##### How App Installation Works There are two types of applications, each installed differently: **Corporate applications (Custom Apps)**. Hosted directly on Applivery. When the user taps **Install**: 1. The App icon changes to an animated loading indicator. 2. A notification appears in the notification bar showing installation progress. 3. The application file is downloaded from the Applivery servers. 4. The system's package installer runs. 5. Once complete, the button changes to **Open**. The entire process runs in the background — the user can continue browsing while installation takes place. **App Store applications**. When the user taps **Install**: 1. The Device opens the App's page in the App Store. 2. The user completes the installation through the App Store. 3. When returning to the Applivery Agent, the App automatically detects the installation status and updates in real time — no manual refresh needed. #### Bookmarks The Bookmarks section displays URLs and web links that the organization has shared with the user — such as links to internal tools, documentation, or company portals. ##### Organization Bookmarks are grouped into two categories: - **Custom**: Links configured specifically by the organization's administrator. - **Applivery**: Links provided by the Applivery Dashboard. Users can filter between Custom and Applivery, but there is no option to remove the filter and display all bookmarks at once. Each bookmark displays an icon (if configured), name, description, and an **Open** button that opens the URL in the Device's default browser. #### Status The Status section gives the user visibility into the management Agents (background services) running on their Device. Each Agent is responsible for collecting and reporting a specific type of device information to the Applivery Dashboard. #### Agents | Agent | What it does | | --- | --- | | **Location tracking** | Reports the Device’s geographic location. | | **System information** | Provides detailed device information, including hardware and OS data. | | **Battery** | Reports battery status. | | **Bluetooth** | Reports Bluetooth status. | | **Download Resources** | Files and resources require user interaction in the Files section. | ##### Status Indicators Each Agent is shown as a card with its icon, name, last successful run time, and a color-coded status: | Indicator | Color | Meaning | | --- | --- | --- | | **Enabled** | Green | Running normally and reporting on schedule | | **Disabled** | Gray | Turned off by the administrator for this Device | | **Error** | Orange | A problem occurred (e.g., a required permission was denied) | If an Agent is currently running, its subtitle shows _"Running"_ instead of a timestamp. Status information updates in real time. #### Navigation and Menu ##### Navigation Drawer Open the navigation drawer by tapping the menu icon (☰) in the top-left corner. The drawer contains: - A close button (✕). - The Applivery logo. - All enabled sections with their icons: Applications, Files, Bookmarks, Status, Notifications. Tapping any section switches to that view and closes the drawer. ##### Back Navigation When inside a detail screen (app detail, search), the menu icon is replaced by a back arrow. Each main section maintains its own navigation history — returning to a section resumes where the user left off. #### Admin Configuration Administrators control the Self-Service Portal's behavior through the managed configuration Policy in the Applivery Dashboard, which is pushed to Devices automatically. ![apple self service configuration](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/9f220cb1-f43a-4b10-8bf0-97c83ad94bc7.png) ##### Feature Toggles Each section of the Self-Service Portal can be independently enabled or disabled: | Feature key | Section | | --- | --- | | `APPLICATIONS` | Application catalog with install/update/uninstall | | `BOOKMARKS` | Organization bookmarks and web links | | `STATUS` | Agent health monitoring dashboard | | `FILES` | File management | For each feature, the administrator can configure: - **active**: Whether the feature appears in the navigation menu (`true` or `false`). - **defaultView**: Whether this feature is the first screen shown when the App opens (`true` or `false`). Only one feature should be set as the default view at a time. ##### Application Catalog Applications shown in the Self-Service Portal are managed through the Applivery Dashboard App Management features. The Agent automatically syncs the assigned application list. Administrators control: - Which applications are visible to which Devices or groups. - Whether an App is a **corporate app** (hosted on Applivery) or an App **app**. - Whether the install type is **Available** (user-initiated) or **Force Install** (mandatory). - App metadata: name, description, icon, screenshots, category, age rating, version. ##### Bookmarks Bookmarks are configured through the Applivery Dashboard Resources management. They support custom bookmarks (created by the administrator) and Applivery Dashboard bookmarks. Each bookmark has a title, description, URL, and an optional icon. ##### Resources Management The Agent handles downloading and installing certificates and files assigned to the Device. Certificates (such as SCEP-enrolled certificates) are automatically installed into the Device's keystore. Other file types are downloaded and stored on the Device. #### Device Compatibility The Applivery Apple MDM Agent v2.0.0 supports: - **iOS 16.0** and higher. - iPhone and iPad. The Self-Service Portal is designed for both portrait and landscape orientations, with optimized layouts for different screen sizes. :::warning Version 2.0.0 is a one-way upgrade. Once a Device is updated to v2.0.0, it cannot be downgraded to v1.x without losing local application and certificate data. ::: **Geolocation reporting** Apple places a strong emphasis on user privacy and imposes strict limitations on the capabilities of the Agent application. As a result, only geolocation reporting is allowed through the Agent App. ![location](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ceebda46-c03e-4436-a78e-0d95135a889f.png) **Reporting conditions** The Agent will report only when the Device detects a substantial change in location, exceeding 500 meters. **Initial setup and permissions** After installation, users must open the application for the first time and explicitly grant geolocation permissions. For improved functionality and to prevent the operating system from deprioritizing its execution, granting permanent execution permissions through **Settings › Applivery MDM › Location › Always** is highly recommended. **Deployment details** The Applivery iOS Agent is available on the **App Store**, and our platform facilitates its installation through [**VPP (Volume Purchase Program)**](https://docs.applivery.com/en/device-management/apple/app-management/vpp/). It is essential to assign licenses in **Apple Business** to make the Agent available. The Agent is exclusively compatible with Devices running **iOS/iPadOS 16.0 or higher**. **Enabling iOS Agent App** Navigate to any of your **Policies** 1 within the [**Applivery Dashboard**](https://dashboard.applivery.io/). In the left-hand menu, click on **Agent** 2 and **enable** 2 the iOS Agent, choose to track the Device location, and decide whether the Agent should be installed as VPP licensed. ![agent](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/2569a0f6-2434-4270-8d92-7cec329607fa.png) --- ## Auto-Lock Source: https://docs.applivery.com/en/device-management/apple/apple-policies/auto-lock/ Description: Secure Apple devices with Applivery by configuring Auto-Lock settings. Learn how to enforce inactivity timeouts and manage device security policies. TL;DR: Learn to configure Auto-Lock on Apple devices with Applivery MDM to enforce security policies and manage device inactivity, balancing security with user experience. Key topics: Apple MDM Configuration, Device Security Policies, Applivery MDM, Applivery, Apple, iPad, Apple Business, DEP In corporate environments, defining the correct automatic lock time on Apple Devices—such as iPads—is essential to balance security and usability. An Auto-Lock value that is too short may disrupt daily workflows, while an excessively long value can increase security risks. With Applivery, administrators can centrally enforce the maximum inactivity time before a Device automatically locks and requires a passcode, ensuring compliance with organizational security Policies across all managed Apple Devices. ### Prerequisites Before applying this configuration, ensure that: - The Apple Device is enrolled in Applivery. - The Policy is correctly assigned to the target Device(s). :::info **Supervision is not required.** Apple's Passcode payload — where the Auto-Lock setting lives — is listed by Apple as `Requires supervision: N/A`, so Auto-Lock applies to [supervised](https://docs.applivery.com/en/device-management/apple/supervision/) and unsupervised Devices alike. The exception is **User Enrollment** (BYOD). Apple accepts the payload on user-enrolled Devices but ignores most of its keys: it forces a 6-digit non-simple passcode and removes the **Never** option from Settings, while **ignoring the Auto-Lock value you configure**. To enforce a specific Auto-Lock time, use Device Enrollment or Automated Device Enrollment (DEP). ::: Auto-Lock is one setting within the Passcode configuration. For everything else it contains — length, complexity, expiration, failed attempts — see [Passcode Policy](https://docs.applivery.com/en/device-management/apple/apple-policies/passcode/). ### Configuration **Navigate to Policies** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io), go to any of your **Policies** 1. From the left side menu, select the **\+ Add configuration** option and choose **Passcode** 2. ![passcode](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/8fa3efe6-caa7-4975-8881-4e68801a5837.png) **Configure Auto-Lock** Within the Passcode configuration, locate the **Auto-Lock** field and enter the desired value in minutes. This value represents the maximum amount of time the Device can remain inactive before it automatically locks and prompts the user for the passcode. ![auto lock](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/dd6312f2-fc60-49cd-9d58-b940aaea21b9.png) ### Allowed values and behavior The Auto-Lock parameter defines **a maximum inactivity window** rather than an optional suggestion. Apple enforces strict limits on this setting through MDM. The minimum supported value is immediate lock (0 minutes), which is generally discouraged except in highly secure environments. The maximum supported value is 15 minutes. :::info Apple does not provide a **Never** option for Auto-Lock via MDM, and it is not possible to fully disable this behavior on managed Devices — supervised or not. ::: ### Effects of applying this configuration Once this configuration is applied, users will no longer be able to increase the Auto-Lock time from the Device’s local settings. The system will always lock after the defined period of inactivity, even when the maximum value is configured. This ensures that unattended Devices do not remain unlocked indefinitely. ### Important considerations No MDM solution, including Applivery, can keep the screen permanently on through Auto-Lock settings. The maximum realistic and recommended value remains 15 minutes, which provides a reasonable compromise between security and usability. For scenarios where the screen must remain continuously active—such as kiosks, digital signage, or point-of-sale systems—Auto-Lock is not the appropriate mechanism. In these cases, it is strongly recommended to use [Kiosk Mode](https://docs.applivery.com/en/device-management/apple/ios-ipados/policies/kiosk-mode/#app-lock) (App Lock Mode) or a dedicated application designed for always-on operation. ### Recommended use cases | Scenario | Recommendation | | --- | --- | | Standard corporate use | Auto-Lock set to 10–15 minutes. | | Shared device | Short Auto-Lock (5–10 minutes). | | Kiosk / front desk | App Lock Mode. | Applivery allows administrators to centrally manage Auto-Lock behavior on Apple Devices, helping organizations maintain compliance with security Policies while minimizing user friction. Although iPadOS does not allow Auto-Lock to be completely disabled via MDM, configuring the maximum supported value offers an effective balance between protection and user experience. --- ## Block Screenshots and Screen Recording Source: https://docs.applivery.com/en/device-management/apple/apple-policies/block-screenshots/ Description: Stop users from saving screenshots and screen recordings on managed iOS, iPadOS and macOS Devices, using Apple's native Restrictions payload. TL;DR: Block screenshots and screen recordings on managed iOS, iPadOS and macOS Devices from the Restrictions section of an Apple Policy. No supervision required. Key topics: Apple Restrictions, Screenshots and screen recording, Data loss prevention, Apple Policies, Applivery, Apple, iOS, iPadOS, macOS Screenshots are one of the easiest ways for sensitive information to leave a managed Device. A customer record, an internal dashboard, a payroll screen — one tap and it is in the camera roll, ready to be shared anywhere. Applivery lets you shut that off at operating system level on iOS, iPadOS and macOS, using Apple's native Restrictions payload. And unlike many Apple restrictions, this one does **not** require the Device to be supervised. ### What this restriction does Apple's Restrictions payload (`com.apple.applicationaccess`) includes a setting that stops the user from **saving** a screenshot or a screen recording. When you turn it on, the user can still press the usual key combination or button shortcut, but the system never generates or saves the resulting file. The restriction behaves the same way on iOS, iPadOS and macOS, although each platform has its own minimum OS version. :::info This restriction works at operating system level, not per App. It does not replace the content protection controls that some Apps implement natively — video conferencing or corporate mail Apps, for example — and it **cannot stop someone from photographing the screen with another device**. ::: ### Requirements

Platform

Minimum OS version

Supervision required

iOS / iPadOS

iOS 5 / iPadOS 13.1

No

macOS

macOS 10.14.4

No

Because supervision is not required, you can apply this restriction to company-owned Devices and, in certain user enrollment scenarios, to BYOD Devices — subject to the general limitations of each enrollment method. ### How it works The restriction is part of the `com.apple.applicationaccess` (Restrictions) payload of the MDM configuration profile. It is the same payload used by other system restrictions, such as blocking AirDrop or App installation, so you can combine it with them inside the same profile. ```xml allowScreenShot ``` Setting this key to `false` prevents screenshots and screen recordings from being saved. Apple's default value is `true`, meaning allowed. :::warning A Device can carry more than one Restrictions payload, but Apple states explicitly that you should **not manage the same restriction from two different profiles**. If you do, the resulting behavior is not guaranteed. ::: ### Configuration **Navigate to Policies** Go to the [**Applivery Dashboard**](https://dashboard.applivery.io) and open **Policies** 1. **Select or create an Apple Policy** Pick an existing **Apple** Policy, or [create a new one](https://docs.applivery.com/en/device-management/general-settings/create-policies/) for the platform you need — iOS/iPadOS or macOS. :::info A Policy can only be linked to one platform. If you manage both iPhone/iPad and Mac, you need one Policy per platform. ::: **Open Restrictions** From the left-hand menu, go to the **Restrictions** 2 section inside **\+ Add configuration**. ![restrictions](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/e88cb095-e78c-438b-b89c-3c3367f0efa1.png) **Turn off the setting** Locate **Allow Screenshots and Screen Recording** and turn it off to block the feature. ![allow screenshots and screen recording setting](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/73a6e996-7b06-4cd7-ba01-25a0177f3f2f.png) **Save and assign** Save the configuration and assign the Policy to the Device or Device group you want to cover. :::warning The availability legend in the Dashboard only lists macOS Mojave 10.14.4 or later and visionOS 2.0, but this setting is also supported on **iOS and iPadOS**, and it affects them in exactly the same way. ::: ### Important considerations - **Screenshots and screen recordings cannot be separated.** Apple covers both with the same key, so you cannot allow one and block the other. - **This restriction does not control third-party App access to screen observation on other Devices** — remote screen viewing features such as Classroom, for example. Apple handles that through a sub-restriction nested under the same key. - **A photo of the screen taken with another device is still possible.** Treat this restriction as one layer of your data loss prevention strategy, not as an absolute guarantee. ### Troubleshooting **The user can still save screenshots after the Policy is applied** - Confirm the profile actually installed on the Device. On iOS/iPadOS, check **Settings > General > VPN & Device Management**. On macOS, check **System Settings > Profiles**. - Check that no other configuration profile on the Device manages the same restriction with a different value. As Apple notes, when more than one Restrictions payload acts on the same key, the resulting behavior is not guaranteed. - On macOS, if the profile is removed and applied again, some Restrictions settings may need a system restart to apply or revert fully. This behavior has been observed with other macOS restrictions managed by the same payload, though it is not specifically confirmed for `allowScreenShot`. --- ## Check Point VPN Source: https://docs.applivery.com/en/device-management/apple/apple-policies/checkpoint-vpn/ Description: Integrate Check Point Harmony Mobile VPN with Applivery for zero-touch VPN configuration on managed iOS Devices. TL;DR: Integrate Check Point Harmony Mobile VPN with Applivery to provide secure, always-on mobile device protection with zero-touch VPN configuration. Key topics: Check Point Harmony Mobile VPN, Applivery Integration, Mobile Security, Zero-Touch Deployment, VPN Configuration, Check Point Harmony Mobile, Applivery, VPN, HTTPS Integrating **Check Point Harmony Mobile VPN** within your Applivery Workspace strengthens device protection by ensuring all network traffic is securely routed through Check Point’s trusted infrastructure. The **VPN feature** adds a critical security layer to Harmony Mobile’s threat prevention capabilities, helping protect users from malicious or unsafe connections even when they’re outside corporate networks. By combining **Harmony Mobile’s Zero-touch deployment** with automated VPN configuration, organizations can deliver consistent, always-on protection for mobile Devices without requiring any manual setup from end users. ### Implementation steps **Generate the Policy Certificate in Check Point** To begin, access the [Check Point Portal](https://portal.checkpoint.com/) and open the **Policy** 1 section. Expand the **Global Policy** 2 (or the workspace policy relevant to your environment) and navigate to the **Network Protection** 3 settings. ![policy-checkpoint](https://www.applivery.com/wp-content/uploads/2025/11/policy-checkpoint-1024x611.png "policy-checkpoint | Applivery") Within this section, locate the **HTTPS Settings** 4 panel and generate a new **network policy certificate** 5. Be sure to save this certificate securely, as it will be required later when configuring the Policy in Applivery. Before leaving this page, it is also recommended to enable the **Use next generation ONP** 6 option to ensure the most up-to-date protection features are applied. ![https-settings](https://www.applivery.com/wp-content/uploads/2025/11/https-settings-1024x643.png "https-settings | Applivery") **Configure the Policy in Applivery** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io), go to any of your **Policies** 7. Choose the Policy where you want to configure the VPN. From the left-hand menu, navigate to the **\+ Add configuration** option and then choose **VPN** 8. :::info If you haven’t yet integrated Check Point Harmony Mobile into your Workspace, or haven’t added the App to your Policy, you can learn how by following this [link](https://docs.applivery.com/en/device-management/integrations/security/checkpoint-harmony-mobile-integration/). ::: ![vpn](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/1400b15f-2657-4175-b3c3-6d118a8c3092.png) You will need to make the following configurations: - **Authentication Method**: Password. - **Provider Type**: Packet-tunnel. - **Enable HTTPS**: 0. - **User Defined Name**: Check Point Local Tunnel. - **VPN Subtype**: `com.checkpoint.capsuleprotect`. - **Type**: VPN. - **Vendor Config**:`{ "zero_touch": "true" }`. - **Remote Address**: [www.checkpoint.com](http://www.checkpoint.com) - **Enable VPN On Demand**: 1. Within the **On-Demand Rules** section: - Add rules for **Connect + Wi-Fi** and **Connect + Mobile**. - Optionally, you can include **Connect + Ethernet** for wired connections by selecting Connect in the **On-Demand Action** field and Ethernet in the **Interface Type Match** field. Within the **VPN** section: - **Account Username**: `{{device.serialnumber}}`. - **Authentication Method**: Certificate. **Certificate configuration** From the left-hand menu, navigate to the **\+ Add configuration** option and then choose **Certificate (Trusted CA)** 9. ![certificate ca](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/db596520-b782-4c75-b0ae-a2ba42947c1e.png) In the **Payload Content** field, upload the certificate you previously downloaded from the Check Point portal. Once uploaded, the certificate will appear in the Policy list, ready for deployment. Finally, **save** the Policy and **deploy** it. --- ## Configure and Restrict Wi-Fi Networks Source: https://docs.applivery.com/en/device-management/apple/apple-policies/configure-wifi-networks/ Description: Push corporate Wi-Fi networks to Apple devices with Applivery, and restrict which networks users can join. Includes WPA3, 802.1X and supervision requirements. TL;DR: Push corporate Wi-Fi to Apple Devices from Policies > Add configuration > Wi-Fi. No supervision needed. Restricting which networks users can join is a separate setting that does require supervision. Key topics: Apple Wi-Fi configuration, Wi-Fi restrictions, Enterprise 802.1X networks, Supervision requirements, Applivery, Apple, iOS, macOS There are two separate things you may want from Wi-Fi management, and it's worth being clear about which one you need, because their requirements are very different: - **Delivering a network**, so Devices connect to the corporate Wi-Fi on their own without anyone typing a password. This **doesn't require supervision** and works even on personal Devices. - **Restricting which networks can be joined**, so a Device can't connect to anything else. This **does require supervision**. You can do the first without the second. You can't do the second without the first — the restriction works by allowing only the networks you delivered. ### Delivering a Wi-Fi network #### Prerequisites - The Apple Device is enrolled in Applivery. - The Policy is correctly assigned to the target Device(s). :::info **Supervision is not required.** Apple lists the Wi-Fi payload as `Requires supervision: N/A`, and it's explicitly allowed in **User Enrollment** on iOS, macOS and visionOS — so corporate Wi-Fi reaches personal Devices too. ::: #### Configuration Once in the [**Applivery Dashboard**](https://dashboard.applivery.io), go to any of your **Policies** 1. From the left side menu, select **\+ Add configuration** and choose **Wi-Fi** 2. ![wifi](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/aeff9f7a-2a3b-44c5-ade6-e5f09da8f1ba.png) The essential settings are:

Setting

What it does

SSID

The name of the network to join.

Hidden network

Mark the network as hidden, so the Device can find it even though it doesn't broadcast its name.

Auto join

When on, the Device connects on its own. When off, the user has to tap the network name.

Encryption type

The security of the network. See the table below.

Password

The access point password, for anything other than an open network.

:::info **You can declare several networks in the same Policy.** Apple allows multiple Wi-Fi payloads, so a Device can carry the office network, the warehouse network and a guest network at once. This matters if you plan to restrict networks later — every network the Device legitimately needs has to be declared, or it won't be able to connect to it. ::: #### Encryption types From **iOS 16, tvOS 16, watchOS 9 and macOS 13** onwards, the values stopped being interchangeable and now mean exactly what they say:

Value

Networks the Device can join

WPA

WPA or WPA2

WPA2

WPA2 or WPA3

WPA3

WPA3 only

Any

WPA, WPA2, WPA3 and WEP

None

Open networks

:::warning Before iOS 16, WPA, WPA2, and WPA3 were equivalent, and all allowed joining any WPA network. If you wrote a profile back then and your access points have since moved to WPA3, a value that used to work may now be too narrow — or too broad. **WPA2** is the safe choice for a mixed environment, since it covers both WPA2 and WPA3. ::: #### Enterprise networks (802.1X) For **WPA/WPA2 Enterprise**, the configuration accepts an enterprise network configuration with the EAP settings, and a **client certificate** referenced from the same Policy. The certificate is distributed as a resource and the Wi-Fi configuration points at it, so the Device authenticates without the user entering anything. #### Proxy The configuration also supports a proxy for the network — manual, with the server address, port, and optional credentials, or automatic through a PAC file URL. With the automatic option, you can allow the Device to connect directly if the PAC file is unreachable, which avoids leaving Devices stranded when the PAC server has a bad day. ### Restricting which networks can be joined Once the corporate network is delivered, you can prevent the Device from joining anything else.

Restriction

What it does

Requirements

Force Wi-Fi to allowed networks only

Limits the Device to joining only Wi-Fi networks set up through a configuration profile.

iOS 14.5+ · iPadOS 14.5+ · visionOS 2+ · supervised

Force Wi-Fi power on

Prevents turning Wi-Fi off from Settings, Control Center, or by toggling Airplane Mode. Does not control which network the Device joins.

iOS 13+ · iPadOS 13+ · supervised

These live in the **Restrictions** configuration, not in the Wi-Fi one. :::info **The restriction works by origin, not by name.** It doesn't hold a list of allowed SSIDs — it allows any network that arrived through a configuration profile and blocks everything else. If you're expecting to type in the names of the networks you want to permit, that isn't how it works. The practical consequence: to allow a network, you deliver it. There's no way to permit a network the Device knows about, but that wasn't installed by profile. ::: :::warning **Validate the Wi-Fi profile before you enable the restriction.** If the declared network is misconfigured — wrong password, wrong encryption type, a typo in the SSID — the Device ends up unable to join anything, including the network that would deliver a corrected Policy. Recovering it means physical access. Test on one Device, confirm it connects, and only then apply the restriction to the fleet. ::: The two restrictions are complementary and answer different questions. _Force Wi-Fi to allowed networks only_ controls **which** network; _Force Wi-Fi power on_ stops the user from sidestepping the whole thing by turning Wi-Fi off. On a shared or single-purpose device, you usually want both. :::info There's an older restriction, **Force Wi-Fi whitelisting** (iOS 10.3+), which Apple **deprecated in iOS 14.5** in favour of _Force Wi-Fi to allowed networks only_. Use the current one. ::: ### Personal Devices (User Enrollment) Delivering Wi-Fi works on BYOD — Apple explicitly allows the payload in User Enrollment on iOS, macOS and visionOS. The restrictions don't. They require supervision, and a personal Device enrolled through User Enrollment is never supervised. That's the expected outcome rather than a limitation to work around: on a Device the employee owns, you deliver the corporate network and leave their personal use alone. --- ## Device Renaming Source: https://docs.applivery.com/en/device-management/apple/apple-policies/device-renaming/ Description: Rename iOS and macOS Devices in Applivery using Smart Enrollments, Commands, and Scripts for consistent Device Management across your fleet. TL;DR: Rename iOS and macOS devices with Applivery using smart enrollments, commands, and scripts for better device management. Key topics: Device Management, iOS, macOS, Device Renaming, Applivery, Apple Business, Device Enrollment Program This feature is designed to help IT administrators enforce consistent naming conventions across Apple Devices. It offers flexibility and complete control over Device Names, simplifying device management. Administrators can create standardized naming schemes using customizable patterns, incorporating variables like usernames, serial numbers, and custom text for a more personalized approach to device naming. ### Renaming of iOS Devices using Smart Enrollments This method is ideal for automatically enrolling all Devices integrated through **Apple Business** (Apple Business) and the [**Device Enrollment Program**](https://docs.applivery.com/en/device-management/apple/enrollment/dep/) (DEP) into the MDM system. **Access Smart Enrollments** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io), go to **Automation** and follow the steps to [create a Smart Enrollment](https://docs.applivery.com/en/device-management/apple/enrollment/smart-enrollment/). **Configure Auxiliary Fields and Display Name Pattern** Configure the **Auxiliary fields** to customize Device Names by creating useful labels that help organize and name the Devices in the **Display name pattern** field. ![display name](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/64196a76-901e-4285-b879-2cb8591b6426.png) **Apply to Device Name** To ensure that the configured Display Name is also synchronized with the Device Name, simply check the box for **Apply to device name as well (only for iOS)**. ### Renaming of iOS Devices using commands You can also use **commands** for specific changes to a Device Name. This method is flexible and allows for both individual and bulk modifications. **Navigate to Devices** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io), go to any of your **Devices** to synchronize the Display Name with the Device Name. **Sync Device Name (Individual)** In the left-hand summary, click the **Action** button and choose **Sync device name**. ![sync device name](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/cf48e083-a93e-4ff1-b444-d53f5b8a2576.png) **Sync Device Name (Bulk)** Additionally, you can sync the Display Name with the Device Name in bulk from the Devices list by clicking the **Action** button, selecting **Apple** as the platform, and choosing the **Sync device name** command. ![sync in bulk](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/c906946c-19d7-4727-a62c-55b884a7808a.png) :::info The **Sync device name** command requires the Device to be online and responsive. ::: ### Renaming of macOS Devices using scripts For **macOS** Devices, Applivery provides the option to create scripts with specific arguments to configure personalized names for each Device. These scripts enable IT admins to leverage their fleet information effectively, ensuring the establishment of unique and descriptive names. **Navigate to Scripts** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io), head to **Resources** 1, select **Scripts** 2 from the left-hand menu, and click the **\+ Create Script** 3 button. ![scripts](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/fd376c0b-bce9-4d08-ae11-215d7ce7f070.png) **Configure the Script** The script should include arguments that extract specific information from each Device according to your needs, such as the serial number or the assigned employee’s name. **Create Unique Device Names** Use this extracted information to create unique and descriptive Device Names. ![script change device name](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/8336d61d-967c-496f-bcd1-4fe3f109ea72.png) --- ## Manage OS Updates Source: https://docs.applivery.com/en/device-management/apple/apple-policies/manage-os-updates/ Description: Control iOS, iPadOS & macOS updates with Applivery. Schedule, delay, and enforce OS versions for enhanced security and compliance. TL;DR: Applivery simplifies Apple software update management, allowing IT admins to schedule, delay, and enforce updates for iOS, iPadOS, and macOS devices. Key topics: Apple Software Update Management, MDM Update Policies, iOS Update Scheduling, macOS Update Scheduling, Apple, iOS, iPadOS, macOS, Applivery, XProtectPlistConfigData, MRTConfigData, XProtectPayloads Keeping your Apple Devices up to date is crucial for security, performance, and access to the latest features. With Applivery, you can take control of how and when updates are delivered to your organization’s iPhones, iPads, and Macs, ensuring that updates don’t disrupt workflows and that Devices remain compliant with your Policies. Whether you want to automate updates, delay them for compatibility testing, or enforce a minimum OS version across your fleet, Applivery gives you the flexibility and control you need. ### Requirements :::warning **On iPhone and iPad, software update commands require a supervised Device.** Apple's Device Management engineers state that all software update MDM commands are supervised-only on iOS, and the behaviour is easy to confirm: an unsupervised Device doesn't quietly ignore the command, it **rejects it** with error `12021` — *"not a valid request type"*. If updates aren't reaching your iPhones or iPads, check supervision before anything else. ::: Two clarifications that matter when you're planning a rollout: - **The gate is supervision, not the enrollment method.** Automated Device Enrollment isn't required as such — what's required is that the Device ends up supervised, which in practice comes from [Automated Device Enrollment](https://docs.applivery.com/en/device-management/apple/enrollment/dep/) or [Apple Configurator](https://docs.applivery.com/en/device-management/apple/enrollment/apple-configurator/). - **BYOD Devices are out of scope.** A Device enrolled through User Enrollment is never supervised, so it can't receive software update commands at all. On personal Devices, OS updates stay with the user. This applies to the **update commands**. The Policy-level deferral settings described below are a different mechanism and behave independently. ### Understanding Apple update types & modes Apple provides multiple update mechanisms to ensure its Devices—across **iOS, iPadOS, and macOS**—remain secure, performant, and feature-rich. The way updates are managed can vary depending on the platform, and some update modes are exclusive to **macOS**. When planning your update strategy, it’s essential to distinguish between **how updates are delivered** (update modes) and **what kind of updates are being applied** (update types). #### Update types Apple software updates can be categorized into three main types: - **Major OS updates**: Released annually, these updates bring new features, significant interface changes, and broad system improvements. Examples include iOS 17 or macOS Sonoma. - **Minor OS updates**: These are released more frequently and focus on incremental refinements, such as performance improvements, bug fixes, and smaller usability enhancements. - **Background security & Configuration updates**: These updates are designed to enhance system security without requiring full OS upgrades. They include: - **XProtectPlistConfigData**: Malware definition updates for Apple’s built-in antivirus. - **MRTConfigData**: Updates for the Malware Removal Tool. - **XProtectPayloads**: Enhancements to threat detection payloads used by XProtect. #### Common update modes across all Apple Devices Apple provides several modes of updates that apply across iOS, iPadOS, and macOS Devices. These can be managed in two main ways: through **policy configurations** or by sending **update commands** directly to the Devices. ##### Policy-level updates These configurations allow administrators to define how and when updates are applied: - **Security updates**: Critical patches released independently to address vulnerabilities. - **Rapid Security Responses (RSR)**: Urgent security fixes that are delivered quickly and, in some cases, without needing a reboot. In addition, you can configure advanced update behaviors like **Force Delayed Software Updates** and **Enforced Software Update Delay**, offering even more control over when and how updates are made available to end users. **Navigate to Policies** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), go to any of your **Policies** 1. From the left-hand menu, click on **\+ Add configuration**, and choose **Restrictions** 2. ![restrictions](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/e88cb095-e78c-438b-b89c-3c3367f0efa1.png) **Configure Update Settings** Once added, navigate to the **Updates** tab to configure the required settings within your Policy. **General Restrictions** Additionally, under the **General** tab within **Restrictions**, you’ll find options to define how OS updates are deferred: - **Enforced Software Update Major OS Deferred Install Delay**: Set a delay (in days) before major OS updates can be installed. - **Force Delayed Major Software Updates**: Enforce the use of the delay for major OS updates. - **Enforced Software Update Minor OS Deferred Install Delay**: Set a delay (in days) before minor OS updates can be installed. ##### Command-based updates Applivery also allows sending **update commands** to Apple Devices, giving IT teams more immediate control. The software update command modes are: 1. **Default**: Automatically downloads or installs the available update based on the Device’s current state and system preferences. 2. **Download Only**: Downloads the update package without initiating installation. Useful for preparing Devices in advance. 3. **Install ASAP**: Installs a previously downloaded update as soon as possible, even overriding user deferral settings. ![schedule update](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/3c9bc516-f46f-4ab6-92b0-3934a3fb5093.png) #### macOS-specific update modes In addition to the common update modes, macOS supports a few software command update modes that are unique to the desktop environment: 1. **Notify Only**: Downloads the software update in the background and notifies the user via the App Store. The user can then choose when to install it. 2. **Install Later**: Downloads the update and schedules the installation for a later time, typically during an idle period or outside of working hours. 3. **Install with Force Restart**: Performs the default update action (download and install), and then forces a system restart if required to complete the update. This ensures the update is applied without waiting for user intervention. #### Additional command options Depending on the mode and the platform, the scheduling dialog exposes two extra fields: - **Max deferrals**: how many times the user can postpone the update before it's enforced. Only available when the mode is **Install Later**. :::warning A value of **`0` means unlimited**, not "no deferrals allowed". If you want to cap postponements, set the number you actually want to allow. ::: - **High priority** (macOS only): treats the update as if the user had scheduled it themselves, which moves it ahead of the normal queue. :::info These commands map to Apple's **`ScheduleOSUpdate`** MDM command. That's worth knowing for two reasons: on iOS and iPadOS, downloading and installing is a **two-step process** — which is why **Install ASAP** acts on an update that has already been downloaded — and the command schedules an update, rather than declaring a deadline the Device must meet on its own. ::: ![schedule update macos](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/816f0a49-055e-4c7c-9460-e3dedec8bf4d.png) ### Scheduling software updates With Applivery, you can schedule all types of operating system updates — whether they are major, minor, or background and configuration — and apply them either individually to specific Devices or in bulk across your entire fleet. #### Schedule an update individually To schedule a software update for a specific Device, head over to the [**Applivery Dashboard**](https://dashboard.applivery.io/) and navigate to any of your **Devices**. On the **Overview** tab, located in the bottom-right corner, you’ll find all relevant information about software updates. If the Device has a pending update, it will be displayed here. Simply click the **Schedule** button next to the available update. A modal will appear where you can configure the update details—such as the installation type and, for macOS Devices, the priority level—before confirming the schedule. ![schedule](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/4b703f9a-868a-440b-93bb-d3612631caa9.png) #### Schedule updates in bulk To schedule updates for multiple Devices at once, start by going to the **Devices** section. Use the **Action** button to open the bulk action menu. From there, select the **Apple** platform,  choose your **target Devices**, filter the list by **Available updates**, and click **Schedule update** to define the update settings—just like you would for an individual device. ![available update](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/a30e7cdb-a246-4753-9db2-5028a4bd9b60.png) --- ## Passcode Policy Source: https://docs.applivery.com/en/device-management/apple/apple-policies/passcode/ Description: Configure the Passcode policy on Apple devices with Applivery. Set minimum length, complexity, expiration, failed attempts and auto-lock, with the exact limits Apple enforces. TL;DR: Set passcode requirements on Apple Devices from Policies > Add configuration > Passcode. No supervision needed. Watch the failed-attempts setting: on iOS it erases the Device. Key topics: Apple passcode requirements, Passcode expiration and history, Failed attempts and data erasure, User Enrollment limitations, Applivery, Apple, iOS, macOS The passcode is the single control that everything else on an Apple Device depends on. Data Protection encrypts the Device's storage, but that encryption is only meaningful if there's a passcode protecting it — without one, the data is effectively unprotected no matter what else you configure. You can verify both conditions on a Device in [Security Info](https://docs.applivery.com/en/device-management/apple/security-info/). The **Passcode** configuration is where you define what that passcode has to look like: how long, how complex, how often it changes, and what happens when someone gets it wrong too many times. ### Prerequisites - The Apple Device is enrolled in Applivery. - The Policy is correctly assigned to the target Device(s). :::info **Supervision is not required.** Apple lists this payload as `Requires supervision: N/A`, so it applies to [supervised](https://docs.applivery.com/en/device-management/apple/supervision/) and unsupervised Devices alike. ::: ### Configuration Once in the [**Applivery Dashboard**](https://dashboard.applivery.io), go to any of your **Policies** 1. From the left side menu, select **\+ Add configuration** and choose **Passcode** 2. ![passcode](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/8fa3efe6-caa7-4975-8881-4e68801a5837.png) ### What you can set #### Requiring a passcode **Force PIN** is the setting that makes a passcode mandatory. It's **off by default**, which is worth pausing on: without it, none of the other settings force the user to have a passcode at all — they only describe what the passcode must look like _if_ the user sets one. Turn Force PIN on first, then configure the rest. #### Length and complexity

Setting

What it does

Range

Minimum length

Minimum overall length of the passcode.

0–16 · default 0

Allow simple

When off, blocks repeated characters and sequences such as 1111, 123 or CBA.

Default: allowed

Require alphanumeric

Requires letters, not just digits.

Default: off

Minimum complex characters

Minimum number of characters that are neither letters nor digits — &, %, $, #.

0–4 · default 0

Two details that trip people up: - **Minimum length maxes out at 16.** If a security requirement asks for more, it isn't achievable through this payload. - **Minimum length and minimum complex characters are independent.** Requiring 2 complex characters doesn't imply any total length — set both. For the common requirement of _"a 6-digit PIN that isn't trivial"_: Minimum length `6` + Allow simple **off**, leaving Require alphanumeric off. #### Rotation and reuse

Setting

What it does

Range

Maximum PIN age in days

Days the passcode can stay unchanged. When the limit is reached, the system forces a change before unlocking.

1–730

PIN history

The new passcode must be different from the last N used.

1–50

For a 12-month rotation, set 365. Pair it with PIN history, or users will alternate between two passcodes indefinitely. #### Idle locking

Setting

What it does

Range

Auto-Lock

Maximum idle minutes before the Device locks and asks for the passcode.

0–15 (macOS: up to 60)

Maximum grace period

Minutes during which the Device can be unlocked again without re-entering the passcode.

Default 0 — no grace period

:::warning **Auto-Lock is expressed in whole minutes.** There's no sub-minute granularity, so a requirement like _"lock after 90 seconds"_ isn't representable — you have to choose 1 minute (stricter) or 2 (looser). Setting the value also removes the **Never** option from the user's Settings. ::: Auto-Lock is a **ceiling**, not a fixed value: the user can pick a shorter time, but never a longer one. It's covered in more depth in [Auto-Lock](https://docs.applivery.com/en/device-management/apple/apple-policies/auto-lock/). #### Failed attempts

Setting

What it does

Range

Maximum failed attempts

Failed passcode entries allowed before the Device erases or locks.

2–11 · default 11

:::warning **On iOS, iPadOS, visionOS and watchOS, exceeding this limit securely erases all data and settings from the Device.** It doesn't lock it — it wipes it. Only macOS locks instead. This is not a setting to tighten casually. A low value on a Device used by someone who mistypes their PIN a few times means real data loss, and there's no undo. ::: After six failed attempts, the Device imposes an increasing time delay between entries. That means values of 6 or lower behave differently from higher ones: there's no delay before the erase or lock; it happens as soon as the limit is passed. #### macOS-only settings

Setting

What it does

Change at next auth

Forces a password reset the next time the user authenticates. In a device profile, it affects all users, and admin authentications may fail until the admin password is also reset.

Minutes until failed login reset

Minutes before the login resets after the maximum failed attempts. Requires the failed-attempts limit to be set.

Custom regex

A regular expression the password must match, plus a localized description of the rule. macOS 14+.

:::warning Use **Custom regex** only when the standard settings genuinely can't express your requirement. A mistake produces either an unsatisfiable passcode policy or a description that doesn't match what's actually enforced, and the user is the one who discovers it, at the worst moment. The expression uses ICU syntax and is limited to 2048 characters. ::: ### What the Passcode configuration cannot do Three things are commonly asked for, and none of them live here: - **Requiring biometrics.** Apple has no key that forces a user to enrol Face ID or Touch ID. You can restrict biometrics, never mandate them. The verifiable control is the passcode itself. - **Setting a specific passcode.** The configuration defines _minimums_. Users choose their own passcode and can change it to any other compliant one. - **Blocking passcode changes.** That's a **Restrictions** setting, and unlike the Passcode payload, it **does require a supervised Device**. ### Personal Devices (User Enrollment) On BYOD Devices enrolled through User Enrollment, Apple accepts the payload but **ignores most of its settings**. Instead, its presence forces a fixed set of rules:

Setting

What Apple applies

Force PIN

Always on

Minimum length

Always 6

Allow simple

Always off

Auto-Lock

Value ignored — only the Never option disappears from Settings

Minimum complex characters

Ignored

Everything else — expiration, history, failed attempts — **is not applied**. If your requirement includes passcode rotation or a specific auto-lock time, User Enrollment can't satisfy it, and you need Device Enrollment or [Automated Device Enrollment](https://docs.applivery.com/en/device-management/apple/enrollment/dep/). This is the single most common source of _"I configured it, and nothing happened"_ on Apple Devices. Before troubleshooting the Policy, check how the Device was enrolled. --- ## User Account Policies Source: https://docs.applivery.com/en/device-management/apple/apple-policies/user-account-policy/ Description: User Account Policies in Applivery for shared iPads and Macs — manage User accounts, enforce security, and maintain efficient operations. TL;DR: Applivery simplifies user account management on shared iPads and Macs by allowing you to create and assign user-specific policies. Key topics: Device Management, User Account Management, Apple Device Management, Applivery, Shared iPad, Apple Effectively managing multiple user accounts on a single device is essential for maintaining a company’s security Policies. While using one Device for multiple users can optimize resource allocation, poor management can lead to unauthorized access and data breaches. For instance, the Shared iPad feature allows organizations to easily manage iOS Devices used by multiple users. Applivery offers a seamless solution for managing user accounts on shared iPads and Macs, ensuring both security and efficient operations. ### Create a user account policy **Navigate to Policies** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io), follow the steps to [create a new Policy](https://docs.applivery.com/en/device-management/general-settings/create-policies/). Check the box for **Apply to device user accounts**. ![user account policy](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/2b210af0-18be-4588-8e40-00c2dbbe55a6.png) **Access the Policy Summary Page** You will be redirected to its Summary page. From the **\+ Add Configuration** button, you can apply all necessary settings for your specific users. **Assign the Policy to Users** After making these changes, you will find a list of Devices associated with users who have this Policy applied at the bottom of the page. You can also add new users by clicking the **\+ Assign to device user** button. ![assign policy](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/390d2577-1485-434a-a9ba-e0e1ff637692.png) :::warning User Account Policies can only be assigned to Shared iPads and macOS Devices. ::: --- ## Apple Enrollment Source: https://docs.applivery.com/en/device-management/apple/enrollment/ Description: Apple Enrollment in Applivery — enroll, configure, and manage iOS, iPadOS, and macOS Devices at scale from a centralized Dashboard. TL;DR: Applivery simplifies Apple device management by providing a centralized dashboard to enroll, configure, and manage iOS, iPadOS, and macOS devices at scale. Key topics: Apple device management, Applivery, iOS enrollment, iPadOS enrollment, macOS enrollment, Apple, iOS, iPadOS, macOS Enrolling an Apple Device in Applivery registers it with the MDM platform and applies your organization's Policies, Apps, and settings automatically. Applivery supports all standard Apple enrollment methods, from manual profile installation to Zero-touch deployment via Apple Business. Choose the right enrollment method for iOS, iPadOS, and macOS for your deployment: DEP, Apple Configurator, account-driven enrollment, or manual enrollment. --- ## Account-Driven Device Enrollment Source: https://docs.applivery.com/en/device-management/apple/enrollment/account-driven-device-enrollment/ Description: Account-Driven Device Enrollment for corporate-owned Apple Devices without Apple Business — how it works and its MDM capabilities. TL;DR: Account-driven Device Enrollment provides a modern way to manage corporate Apple devices without Apple Business, offering a balance between BYOD and fully supervised deployments. Key topics: Account-driven Device Enrollment process, Supported devices and OS requirements, Management capabilities, Data separation, Use cases and limitations, Apple, iOS 17, iPadOS 17, macOS 14 Sonoma, visionOS 1.1, MDM, Apple Business, Managed Apple Account Account-driven Device Enrollment is an enrollment method introduced with iOS 17, iPadOS 17, macOS 14, and visionOS 1.1, designed for **corporate-owned Devices that are not registered in Apple Business**. It allows organizations to manage Devices with a broad set of MDM capabilities while still leveraging a Managed Apple Account for authentication — without needing a DEP setup or sharing an enrollment link. It sits between Account-driven User Enrollment (BYOD, limited MDM capabilities) and Automated Device Enrollment (Zero-touch, fully supervised) in terms of management scope and deployment complexity. :::info Both a Managed Apple Account and a personal Apple Account can be active on the same device simultaneously, with full separation of work and personal data. ::: ### Supported Devices and Minimum OS Requirements | Device | Minimum OS | | --- | --- | | iPhone | iOS 17 | | iPad | iPadOS 17 | | Mac | macOS 14 Sonoma | | Apple Vision Pro | visionOS 1.1 | ### How does enrollment work? To enroll a Device, the user navigates to **Settings > General > VPN & Device Management** (on iPhone/iPad) or **System Settings > General > Device Management** (on Mac) and selects the **Sign In to Work or School Account** button. This initiates a four-stage process: **Service Discovery** The Device uses the user's organizational identifier (e.g. `eliza@company.com`) to automatically locate the organization's MDM enrollment URL by querying a well-known resource at the domain: ``` https:///.well-known/com.apple.remotemanagement ``` The MDM server responds with a JSON document indicating the enrollment type (`mdm-adde` for account-driven Device Enrollment) and the enrollment URL. **Authentication and Access Token** The user authenticates with the MDM service using their organizational credentials. Upon successful authentication, the MDM service issues a **secure access token** that is stored on the Device and used for all subsequent requests. This token also enables continuous verification of the user's authorization throughout the Device's enrollment lifecycle. On iPhone, iPad, and Apple Vision Pro, this process can be further streamlined using **Enrollment SSO (Single Sign-On)**, which reduces repeated authentication prompts and allows token renewal to happen automatically through the organization's identity provider. **MDM Enrollment** Using the access token, the Device retrieves the enrollment profile from the MDM service. To complete enrollment, the user must **sign in with their Managed Apple Account**. Once enrolled, the Managed Apple Account is displayed prominently in Settings and System Settings. **Ongoing Authentication** The access token remains active after enrollment and is included in all requests to the MDM service. This allows the service to continuously verify that the enrolled user is still authorized. When the token expires, the user may be prompted to re-authenticate — or, if Enrollment SSO is configured, this happens transparently in the background. ### What can IT administrators manage? Account-driven Device Enrollment provides a **broader set of management capabilities** than Account-driven User Enrollment, making it suitable for corporate-owned Devices. Key capabilities include: | Capability | Available | | --- | --- | | Query serial number and device identifiers (UDID, IMEI) | ✅ | | Query installed Apps list | ✅ | | Query device time zone, phone number, roaming status | ✅ | | Configure VPN (full device) | ✅ | | Configure per-app VPN | ✅ | | Require and enforce complex passcode | ✅ | | Remotely erase all content and settings | ✅ | | Enforce software updates | ✅ | | Manage FileVault (macOS) | ✅ | | Set device name (macOS) | ✅ | | Manage Activation Lock (macOS) | ✅ | | Silent app installation | ✅ | | Install and manage certificates | ✅ | | Configure Wi-Fi and email profiles | ✅ | | Manage Activation Lock (iOS/iPadOS) | ❌ (requires Automated Device Enrollment) | | Configure Always On VPN | ❌ (requires Automated Device Enrollment) | | Configure Global HTTP Proxy | ❌ (requires Automated Device Enrollment) | | Set device name (iOS/iPadOS) | ❌ (requires Automated Device Enrollment) | | Enable Lost Mode | ❌ (requires Automated Device Enrollment) | ### Supervision Account-driven Device Enrollment **does not result in supervision** on iPhone, iPad, or Apple Vision Pro. However, on **Mac computers with macOS 11 or later**, Device Enrollment — including the account-driven variant — **does enforce supervision automatically**. This means Mac Devices enrolled this way gain access to supervision-only management capabilities not available on iOS/iPadOS Devices enrolled through the same method. ### How is work and personal data separated? When enrollment is complete, the operating system automatically creates separate encryption keys on the Device. If the user unenrolls, or if the MDM service remotely unenrolls the Device, the operating system destroys those keys, cryptographically removing all managed data. The following content is kept separate between the work and personal contexts: | Content | Minimum OS | | --- | --- | | Managed app data containers | iOS 15, iPadOS 15, macOS 14, visionOS 1.1 | | Keychain items | iOS 15, iPadOS 15, macOS 14, visionOS 1.1 | | Mail app (attachments and body) | iOS 15, iPadOS 15, macOS 14, visionOS 1.1 | | Notes app | iOS 15, iPadOS 15, macOS 14, visionOS 1.1 | | Calendar app | iOS 16, iPadOS 16.1, macOS 13, visionOS 1.1 | | Reminders app | iOS 17, iPadOS 17, macOS 14, visionOS 1.1 | Additionally, if a user is signed in with both a personal Apple Account and a Managed Apple Account, **Sign in with Apple** automatically uses the Managed Apple Account for managed Apps and the personal Apple Account for unmanaged Apps — no manual selection required. ### When should I use Account-Driven Device Enrollment? This method is a good fit when: - Devices are **corporate-owned** but not purchased through Apple or an authorized reseller (and therefore not eligible for Apple Business DEP automatic assignment). - You need **more management control than BYOD** (Account-driven User Enrollment), but don't have a full Apple Business (DEP) setup in place. - You want a **modern, frictionless enrollment experience** that doesn't require sharing a link or QR code — just a Managed Apple Account sign-in. - You are managing **Mac computers** and want supervision enforced automatically without a physical setup process. It is **not recommended** when: - You need the Device to be supervised on an iPhone or iPad (use Automated Device Enrollment instead). - You need features like Lost Mode, Always On VPN, or Global HTTP Proxy on iOS/iPadOS. - The deployment scenario is BYOD (use Account-driven User Enrollment instead). --- ## Account-Driven User Enrollment Source: https://docs.applivery.com/en/device-management/apple/enrollment/account-driven-user-enrollment/ Description: Apple Account-Driven User Enrollment (UEMDM) — a BYOD Enrollment method that balances corporate security with user privacy, features, and limitations. TL;DR: Apple User Enrollment provides a secure and privacy-focused way to manage BYOD devices by isolating work and personal data. Key topics: User Enrollment features, Data separation in User Enrollment, Managed Apple IDs, Limitations of User Enrollment, Apple, iOS 13, macOS Catalina, MDM, Apple Business, VPP, APFS Starting in iOS 13 and macOS 10.15 Catalina, Apple introduced a new enrollment method called User Enrollment. With iOS 15 and macOS 14, Apple refined this approach into what is now officially called **Account-driven User Enrollment** — the current recommended method for BYOD scenarios. This is a notably different mode of enrollment than those previously available through Apple DEP, Enrollment link, or Supervised mode. While these modes still exist, **Account-driven User Enrollment aims to address Bring Your Own Device (BYOD) deployment scenarios specifically**, requiring the user to authenticate with a Managed Apple ID to complete the enrollment process. :::warning User Enrollment is still in private beta for a limited number of customers. If you want to learn more, please contact us at [support@applivery.com](mailto:support@applivery.com). ::: ### Why another enrollment method? Existing enrollment and supervision methods are very powerful. Administrators can wipe, lock, and heavily restrict access on a DEP-enrolled and supervised device. In macOS, administrators can run any type of root-level commands or scripts and apply highly intrusive configurations at the Device and app levels. Additionally, administrators can list and obtain detailed information about the Devices, even about Apps that have not been deployed through an MDM solution. In other words, administrators have almost full control over managed Devices. **Account-driven User Enrollment aims to solve this use case by restricting what MDMs can do**. Instead of having full access to the Devices, **business and personal spaces are isolated**. Commands and operations performed by the MDM are limited and restricted to run under the business side of the Device, providing a more comfortable scenario for end-users who can still get access to business services without sacrificing their privacy. This provides **a more balanced scenario between security and privacy, allowing users to easily switch from work to personal life**. ### What's different from other enrollment methods? **Device Information:** The MDM is no longer able to retrieve device-identifying information, such as serial number, universal device identifier (UDID), IMEI, or Mac addresses. Instead, the Device provides an anonymized identifier specifically created for the MDM enrollment. If a Device is unenrolled from the MDM and then re-enrolls at a later time, a new identifier is generated, maintaining the anonymity of the end-user and the hardware. **App Management:** MDMs can still install and remove Apps, but can only see information about managed Apps. The rest of the Apps installed by the user remain private and will not be visible to the MDM, and they cannot be configured as managed Apps. Additionally, some native Apps support Account-driven User Enrollment scenarios, providing the possibility to isolate information at the App level. **Profiles & Configurations:** Only a limited set of profiles and configurations are available and can be enforced on the Device: - Wi-Fi. - Per-app VPN. - Account-related profiles, like email, calendar, contacts, and Exchange/ActiveSync. **Commands:** Account-driven User Enrollment also prevents administrators from setting or clearing passwords, wiping the Device, and performing other device-level configurations. ### Managed Apple IDs and Account-driven User Enrollment The Account-driven User Enrollment method relies on **Managed Apple IDs** for user identification and authentication. This is what differentiates it from the older profile-based variant — the user actively signs in with their organizational Managed Apple ID to initiate and complete the enrollment, without needing to open a link or install a profile manually. This approach also enables two important features: - **App & media licensing**: Apps must be managed through Apple Business and VPP so that necessary licenses are provisioned. - **iCloud access**: Apple provides business-level iCloud services, such as shared storage for an organization. The Managed Apple ID acts as a credential to provide access to these resources. We highly recommend reading the documentation related to [Managed Apple IDs](https://support.apple.com/en-gb/guide/deployment/depdc4ba8d82/web) to fully understand the benefits and features. ### How is Data Separation Being Managed? As part of the Account-driven User Enrollment process, **a new and separate APFS volume is created on the Device**. This new volume acts as a virtual hard drive with its own encryption and is **isolated from other data volumes on the Device**. This volume stores all enrollment-related managed data. **When the Device is unenrolled, the volume is erased**, removing all managed Apps and data and returning the Device to its original state before enrollment. --- ## Apple Configurator Source: https://docs.applivery.com/en/device-management/apple/enrollment/apple-configurator/ Description: Enroll iPhones, iPads, and Apple TVs into MDM using Apple Configurator — supervise Devices and add them to Apple Business. TL;DR: Enroll iOS devices into MDM and Apple Business using Apple Configurator for Mac or iPhone, enabling device supervision and streamlined management. Key topics: Apple Configurator for Mac, Apple Configurator for iPhone, MDM Enrollment, Apple Business, Device Supervision, Apple, Apple Configurator, MDM, Applivery, iPhone, iPad, Apple TV Apple Configurator is a tool created by Apple that allows administrators to add Devices to Apple Business and enroll them in an MDM solution such as Applivery. Devices enrolled this way are **supervised** and behave identically to Devices purchased directly through Apple Business — including mandatory MDM enrollment. :::warning Enrolling Devices through Apple Configurator with supervision enabled requires a **factory reset**. All existing data on the Device will be wiped. ::: Apple Configurator is available in two versions: - **Apple Configurator for Mac**: A macOS app that enrolls **iPhone, iPad, and Apple TV** (Ethernet-only models) by connecting them via USB to a Mac. It adds Devices directly to Apple Business and prepares them with supervision and MDM enrollment in a single workflow. - **Apple Configurator for iPhone**: An iPhone app that wirelessly adds **iPhone (iOS 16+), iPad (iPadOS 16.1+), Mac (macOS 12.0.1+, T2 or Apple Silicon), and Apple Vision Pro (visionOS 2.6+)** to Apple Business by scanning a pairing image during Setup Assistant. It requires no cables or additional hardware. :::warning In both cases, once a Device is added to Apple Business through Apple Configurator, there is a **30-day provisional period** during which the user can release the Device from Apple Business, supervision, and MDM enrollment. After those 30 days, management becomes permanent. ::: ### Enroll an iPhone or iPad using Apple Configurator for Mac This method is recommended for bulk enrollment of **iPhone, iPad, and Apple TV** Devices that are not registered in Apple Business. It requires a Mac and a USB cable for each Device. #### Requirements - A Mac running Apple Configurator for Mac ([download from the Mac App Store](https://apps.apple.com/us/app/apple-configurator-2/id1037126344)). - An Apple Business account with Administrator or Device Enrollment Manager role. - USB cable for each Device to enroll. - The Applivery **Enrollment URL** (found under the **Settings section > Apple DEP**). **Prepare a Wi-Fi profile** Before enrolling any Device, create a Wi-Fi configuration profile so enrolled Devices can connect to your network automatically: 1. In Apple Configurator for Mac, click **File > New Profile**. 2. Select **Wi-Fi** and click **Configure**. 3. Enter the SSID, password, and security type of your network. 4. Save the profile. ![configurator-Wi-Fi](https://www.applivery.com/wp-content/uploads/2022/06/configurator-wifi-1024x939.png "configurator-Wi-Fi | Applivery") **Connect the Device and start preparation** 1. Plug the Device into the Mac via USB. If prompted on the Device, tap **Trust**. 2. Once the Device appears in Apple Configurator, select it and click **Prepare** in the toolbar. ![apple-configurator-mac-prepare](https://www.applivery.com/wp-content/uploads/2022/06/apple-configurator-mac-prepare-1024x651.png "apple-configurator-mac-prepare | Applivery") **Configure the preparation options** In the Prepare Assistant, select **Manual Configuration** and configure the following options: - **Add to Apple Business**: Enable this if you want the Device to be added to Apple Business and enrolled via DEP. This is the recommended option for supervised, managed deployments. - **Activate and complete enrollment**: Leave this **disabled** if the Device requires user authentication to complete MDM enrollment — the Device will stop at Setup Assistant, and the user will finish the process. Enable it only if the Device already has an MDM record and you want to fully prepare it without user interaction. - **Supervise Devices:** Enable putting the Device in supervised mode, which unlocks the full set of MDM management capabilities. - **Allow Devices to pair with other computers**: Discontinued feature from iOS 13. - **Enable shared iPad**: Whether the shared iPad will be enabled or not. ![apple-configurator-manual](https://www.applivery.com/wp-content/uploads/2022/06/apple-configurator-manual-1024x651.png "apple-configurator-manual | Applivery") :::warning In some cases, you may receive the following unexpected error: "Invalid Profile \[MCProfileErrorDomain – 0x3E8 (1000)\]". In that case, just unselect the **Activate and complete enrollment** option and prepare your Device again. ::: **Assign to an MDM server** 1. Select **New Server…** to add Applivery as your MDM server. 2. Enter a name (e.g., "Applivery Device Management") and paste your **Enrollment URL** from the Applivery Dashboard (**under the Settings section > Apple DEP**). 3. Click **Next**. ![apple-configurator-new-server](https://www.applivery.com/wp-content/uploads/2022/06/apple-configurator-new-server-1024x651.png "apple-configurator-new-server | Applivery") ![enrollment url](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/498dcad4-7bc8-4a2b-abd2-9f8f5c1123bb.png) **Trust certificates** Trust anchor certificates are fetched automatically. If the process takes too long, click **Next** to skip and proceed. If you selected **Add to Apple Business** in Step 3, you will be prompted to sign in with your Apple Business Managed Apple Account. ![apple-configurator-trust-anchor](https://www.applivery.com/wp-content/uploads/2022/06/apple-configurator-trust-anchor-1024x651.png "apple-configurator-trust-anchor | Applivery") If you selected **Add to Apple Business** in **Step 3**, you will be prompted with a login screen. Log in with your Apple Business account and click **Next**. **Create or select an organization** After signing in to Apple Business, enter your organization details or select an existing one. This links the supervision identity to your organization in Apple Configurator. ![apple-configurator-create-org](https://www.applivery.com/wp-content/uploads/2022/06/apple-configurator-create-org-1024x651.png "apple-configurator-create-org | Applivery") **Generate a supervision identity** Select **Generate a new supervision identity**. ![apple-configurator-supervision-identity](https://www.applivery.com/wp-content/uploads/2022/06/apple-configurator-supervision-identity-1024x651.png "apple-configurator-supervision-identity | Applivery") You can also configure which Setup Assistant steps to skip for the end user (language, Wi-Fi, Apple ID, etc.). ![apple-configurator-skip-steps](https://www.applivery.com/wp-content/uploads/2022/06/apple-configurator-skip-steps-1024x651.png "apple-configurator-skip-steps | Applivery") **Select the Wi-Fi profile** Select the Wi-Fi profile you created in Step 1 and click **Next**. ![apple-configurator-network-profile](https://www.applivery.com/wp-content/uploads/2022/06/apple-configurator-network-profile-1024x651.png "apple-configurator-network-profile | Applivery") **Finalize and prepare** If you enabled **Add to Apple Business**, enter your Apple Business credentials when prompted. Then click **Prepare**. The process may take a few minutes, and the Device may restart several times — **do not unplug it** until Apple Configurator shows a confirmation and the Device is on the Welcome screen. ![apple-configurator-dep](https://www.applivery.com/wp-content/uploads/2022/06/apple-configurator-dep-1024x651.png "apple-configurator-dep | Applivery") :::tip If you need to enroll multiple Devices with the same configuration, save your settings as a **Blueprint** in Apple Configurator. You can then apply it directly to new Devices without repeating all the steps. ::: ### Enroll an iPhone or iPad using Apple Configurator for iPhone Apple Configurator for iPhone can also add **iPhone (iOS 16+) and iPad (iPadOS 16.1+)** directly to Apple Business — without needing a Mac or USB cable. #### Requirements - An iPhone running iOS 16 or later with Apple Configurator for iPhone installed. - Apple Business account signed in to the App. - The target iPhone or iPad must be at the **Choose a Wi-Fi Network** step of Setup Assistant (new or factory reset). **Sign in and configure Apple Configurator for iPhone** 1. Open the Apple Configurator app on your iPhone. 2. Accept the terms and conditions. 3. Sign in with your **Managed Apple Account** from Apple Business. Two-factor authentication may be required. 4. In **Settings**, configure how the Mac will connect to the internet: - **Share Wi-Fi (default):** The Mac uses the same Wi-Fi credentials as the iPhone. - **Configuration Profile:** Use a pre-created Wi-Fi or 802.1X profile stored in the Files app. - **Ethernet:** Connect the Mac to the internet via Ethernet before proceeding. 5. Configure the **device management service assignment** — you can assign Devices automatically to the default or a specific MDM service in Apple Business, or leave it unassigned to assign manually later. ![apple configurator for iphone](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/0d9b177e-473c-4f4a-be5a-d9b1dbed2ce2.png) **Prepare the target iPhone or iPad** Start up the iPhone or iPad you want to enroll. Go through Setup Assistant and stop at the **Choose a Wi-Fi Network** screen. :::warning If you go past this screen, you will need to restart the Device. ::: **Pair the Devices** Bring your iPhone (with Apple Configurator open) close to the target device. Two pairing options are available: - **Scan the image:** Use Apple Configurator to scan the pairing image shown in Setup Assistant on the target device. - **Manual pairing:** Tap **Pair Manually** in Apple Configurator on the target device, then tap **Manual Pairing** in the App and enter the 6-digit code. The Device's serial number and information are uploaded to Apple Business. ![apple configurator for iphone](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ede5b16e-ecc2-4efe-acb0-e3e484256f04.png) **Complete the assignment** Wait for the process to complete, then tap **Erase and Shut Down**. The Device is now registered in Apple Business. If not automatically assigned, go to Apple Business and manually assign the Device to Applivery as its MDM service. **Enroll in Applivery via DEP** Power on the Device and proceed through Setup Assistant. It will automatically enroll in Applivery following the standard [DEP enrollment process](https://docs.applivery.com/en/device-management/apple/enrollment/dep/). ### Enroll a Mac using Apple Configurator for iPhone This method allows you to add a **Mac with Apple Silicon or T2 chip** to Apple Business using only an iPhone — no Mac or USB cable needed. Once added to Apple Business, the Mac can be enrolled in Applivery through DEP. #### Requirements - An iPhone running iOS 16 or later with [Apple Configurator for iPhone](https://apps.apple.com/us/app/apple-configurator/id1588794674) installed. - An Apple Business account with Administrator or Device Enrollment Manager role signed in to the App. - A Mac with Apple Silicon or T2 Security Chip running macOS 12.0.1 or later. - The Mac must be at the **Select Your Country or Region** step of Setup Assistant (new or factory reset). **Sign in to Apple Configurator for iPhone** 1. Open the Apple Configurator app on your iPhone. 2. Accept the terms and conditions. 3. Sign in with your **Managed Apple Account** from Apple Business. Two-factor authentication may be required. 4. In **Settings**, configure how the Mac will connect to the internet: - **Share Wi-Fi (default):** The Mac uses the same Wi-Fi credentials as the iPhone. - **Configuration Profile:** Use a pre-created Wi-Fi or 802.1X profile stored in the Files app. - **Ethernet:** Connect the Mac to the internet via Ethernet before proceeding. 5. Configure the **device management service assignment** — you can assign Devices automatically to the default or a specific MDM service in Apple Business, or leave it unassigned to assign manually later. ![apple configurator for iphone](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/48dead5d-b4c9-443a-b91d-9b2d35e1f808.png) **Prepare the Mac** If the Mac is **brand new**, start it up, select the language, click **Continue**, and stop at the **Select Your Country or Region** screen. If the Mac has **already been set up**, you must first erase it: 1. Go to **Apple menu > System Settings > General > Transfer or Reset**. 2. Click **Erase All Content and Settings** and follow the instructions. 3. Once the Mac restarts and reaches Setup Assistant, stop at **Select Your Country or Region**. :::warning Erasing a Mac permanently deletes all data. Make sure you have a current backup before proceeding. ::: **Pair the iPhone with the Mac** Bring your iPhone with Apple Configurator close to the Mac. You have two pairing options: - **Scan the image**: Use the Apple Configurator app camera to scan the pairing image shown on the Mac's Setup Assistant screen. - **Manual pairing**: Click **Pair Manually** on the Mac, then tap **Manual Pairing** in Apple Configurator and enter the 6-digit code shown on screen. Once paired, the Mac's serial number and device information are uploaded to Apple Business automatically. ![pair mac](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/a711f1e6-9139-4d13-9201-498169ff0ba5.png) **Complete the assignment** Wait for the process to complete. When finished, tap **Shut Down** on the iPhone (the Mac will power off). The Mac is now registered in Apple Business. If you did not configure automatic MDM assignment in Step 1, go to your Apple Business portal, find the Device under the **Apple Configurator** group in Devices, and manually assign it to Applivery as its MDM service. ![pair success](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/485c4817-2a96-42ed-91bc-bcfbf61f1d02.png) **Enroll in Applivery via DEP** With the Mac now registered in Apple Business and assigned to Applivery, follow the standard [DEP enrollment process](https://docs.applivery.com/en/device-management/apple/enrollment/dep/) to complete the enrollment. When the Mac is powered on and goes through Setup Assistant, it will automatically enroll in Applivery. --- ## Default Assignments Source: https://docs.applivery.com/en/device-management/apple/enrollment/default-assignments/ Description: Configure default DEP Profiles and Smart Enrollment assignments for different Device types in Applivery using Apple Business. TL;DR: Configure default DEP profiles and Smart Enrollment assignments for different device types in Applivery using Apple Business for streamlined device enrollment. Key topics: Apple Business integration, DEP profile assignment, Smart enrollment configuration, Device type management, Apple Business, Applivery, DEP Profile, iPhone, iPad, Mac If you link Apple Business with Applivery, you can choose the default DEP Profile or Smart Enrollment assignments by device type. For example, you will be able to assign your organization’s iPhone Devices to one DEP Profile and Smart Enrollment and iPad Devices or Mac computers to different ones. ### Applivery Default Assignments Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), go to your **Settings** section 1 and locate **Apple Setup** 2 in the left-hand menu. ![apple setup](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/b6274fc5-da49-451c-b808-025df84bdf58.png) In the Default assignment section, click the Device type dropdown menus, and choose the default [**DEP Profile**](https://docs.applivery.com/en/device-management/apple/enrollment/dep/) or [**Smart Enrollment**](https://docs.applivery.com/en/device-management/apple/enrollment/smart-enrollment/) for that Device type. If you choose none for a Device type, you’ll need to manually assign those Devices later. ![default assignment](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/d89354f8-eff5-4225-973c-cc7e2b635c6d.png) ### Complete the Setup with Apple Business **Enter Customer Numbers and Reseller Numbers** Before you can manage default device assignments, you need to enter your **Apple Customer Numbers** or the **Reseller Numbers** of your participating Apple Authorized Reseller or carrier. Once you’ve signed in to Apple Business, click on **Devices** 1 and select **Inventory** from the left-hand menu. Then, select **Customer Numbers** and click the **Add** 3 button. ![reseller number](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/e5e93aa4-cd4c-4286-935b-7c357168780b.png) A modal will appear where you can choose to add an Apple Customer Number or a Reseller Number. When you enter your Apple Customer Numbers, omit any leading zeros. If the Add button is missing or dimmed, the information may already be saved. :::warning The Apple Customer Number or Reseller Number that you entered will appear as pending. Please note that verification and approval of customer numbers may take up to five days. ::: **Choose Default Device Assignments** Now navigate to the **Management Services** 4 section and select **Default Device Assignment** 5. Click the Device type dropdown menus, choose the default MDM server for that Device type. If you choose Unassigned for a Device type, you’ll need to manually assign those Devices later. ![default device assignment](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/39bf7fb8-9261-48fb-a9bd-03cb7145b5a1.png) --- ## DEP Source: https://docs.applivery.com/en/device-management/apple/enrollment/dep/ Description: Configure Apple DEP with Applivery for automated Device Enrollment using Apple Business — streamline iOS and macOS Device Management. TL;DR: Configure Apple DEP in Applivery using Apple Business to automate and simplify Apple device enrollment. Key topics: Apple Device Enrollment Program (DEP), Apple Business setup, Applivery MDM configuration, DEP profile creation and assignment, Device initialization and enrollment, Apple, Applivery, Apple Business, DEP, MDM, iOS, macOS Apple Device Enrollment Program (also known as DEP) is a tool integrated into Apple Business that allows organizations to fully automate the enrollment process of Apple Devices in MDM solutions like Applivery. In the beginning, it was focused on new Devices, but starting with iOS 11, it now supports enrolling already purchased Devices as well. DEP helps organizations enable supervision, MDM enrollment, skip setup steps, and many other features. :::info **If you see `code: 5096`**, retry the operation first — it usually clears on its own. If it persists, check that the DEP token is still valid and that the Device is assigned to the right MDM server. ::: ### How to Configure Apple Device Enrollment Program (DEP) in Applivery Applivery provides seamless integration with the [Apple Volume Purchase Program (VPP)](https://docs.applivery.com/en/device-management/apple/app-management/vpp/) for purchasing app and book licenses and installing company-private Apps to manage Apple Devices running iOS and macOS. There are some prerequisites that you must take into consideration: 1. You already own an [Apple Business](https://business.apple.com/)\-approved account for your organization. 2. You have an **active Applivery Apple Device Management license**. **Configure a new MDM server in Apple Business** Sign in to the [**Applivery Dashboard**](https://dashboard.applivery.io), navigate to the **Settings** 1 section, and locate the **Apple DEP** 2 section in the left-hand menu. Then click the **Download Public Key** 3 button. ![mdm server](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/edc96d80-73f5-4771-a17c-1f33570ba5fd.png) A file called `Applivery DEP PublicKey (ORG NAME).cer` will be downloaded. **Create a new MDM Server in Apple Business** 1. Sign in to [Apple Business](https://business.apple.com/) as a user who has the role of Administrator or Content Manager. 2. Click on **Devices** 1 and select **Management Services** 2 from the left-hand menu. 3. Click on the **Add** button under **Add device management service** 3. ![add device management service](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/bd475d33-9e8c-43bc-a6f5-4e105e6b68da.png) Select the **Connect external device management** option, then name the new MDM server, check **Allow this service to release devices**, and click **Upload Certificate**. Finally, select and upload the _.cer_ file you downloaded in Step 1. Then click **Next**. ![add device management service](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/577a9f6b-2aba-4f11-8521-fa0146621bec.png) In the next step, you’ll be able to **download the token**, and a `.p7m` file will be downloaded. ![download service token](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/d43e7bb8-152b-46dd-a0fb-bc49dfa5f1b1.png) Now, get back to the Applivery Dashboard and scroll down until step 5 of the setup process. Click the Select button and upload the `.p7m` file you downloaded from Apple Business in the previous step. Then click Finish configuration. ![finish setup](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/8e8754b2-8c1e-47e6-b53d-d3e7a825eb49.png) **Create a DEP Profile** DEP profiles define how new Devices will be enrolled in Applivery MDM and the initial configuration of those Apple Devices. They allow you to configure setup screens, multi-user, or supervision mode, besides other features. Let’s get started! Click on DEP profiles. ![dep profiles](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/f28d3566-4a0e-4cef-ba4f-f8d28e7c8e53.png) A modal view will open, providing you with the following options: 1. View all existing DEP profiles. 2. Create a new DEP profile. Then click the **\+ Create DEP Profile** button. As you create the profile, you can assign it a Name for future reference and select the desired **enrollment options**. ![dep profile form](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/3abc7b6b-ff1f-4e22-a9cf-c963a693e4d4.png) Optionally, you can also specify additional information for the profile, such as the Department, support contact information, language, or region. ![dep configuration section](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/b16bd9fc-048c-4dc7-b229-bf5770cb5067.png) Last, you can select the setup steps you want to skip during device provisioning. By default, all of them will be unselected so that the standard setup process is displayed. Once ready, click the Save button to finish. ![skip setup items](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/67b5ee77-7885-4ef2-88d2-7332220686c0.png) The new DEP profile will be added to the list and will be ready to be assigned to new Devices. **Sync with Apple Business** Now that your Applivery account and Apple Business account are connected, you can Sync them to retrieve all the new Devices that have been added to Apple Business and configure them. Just click the Sync with Apple Business button to start the syncing process and get the very latest updates from Apple Business. New Devices will be added to the list below. :::info Note that the **Sync with Apple Business** button has been placed here to allow you to manually trigger a syncing process with Apple Business, but this is a process that will be triggered automatically every hour on your behalf. ::: **Assign DEP Profiles to new Devices** Now that new Devices are properly synced with Applivery, you can start assigning DEP profiles to those Devices so that they can finally get enrolled into Applivery. Follow these steps: 1. Under the list of Devices, just click on the Device. A side view will be opened. 2. Use the Configure button to display the dropdown menu to choose a DEP profile. 3. Click the **Assign** button. Once assigned, the Device will go through the following statuses: - **Assigned**: The enrollment profile has been assigned to the Device, but not applied to the actual device yet. - **Pushed**: The enrollment profile has been correctly applied to the Device Take them into consideration before moving to the next step, since this is an asynchronous process that may take a few minutes depending on Apple’s API. **Initialize device** Now that your Devices have been associated with an Enrollment profile in Applivery, it’s time to start them up: 1. Turn on your Device for the first time. The Device may ask a few initial setup questions. 2. Select a Wi-Fi network with internet access, as it is required to complete the Apple DEP check-in process. 3. Next, the Device will get the DEP profile configuration and will follow the settings you created. 4. Once the setup process is completed, the Device will appear under the **Devices** section in the Applivery Dashboard. :::warning If the device was turned on and set up before being added to Apple Business, it will have missed the DEP check-in at first boot. The standard fix is a factory reset: go to **Settings > General > Reset** and select **Erase all content and settings**. For macOS devices, if you need to avoid wiping them, there is an alternative — see [Trigger DEP Enrollment on a Mac Already Set Up](https://docs.applivery.com/en/device-management/apple/macos/troubleshooting/force-dep-enrollment/). ::: --- ## Enrollment Methods Source: https://docs.applivery.com/en/device-management/apple/enrollment/enrollment-methods/ Description: Apple Enrollment methods in Applivery — DEP, Account-Driven, Manual Enrollment, and Apple Configurator for iOS and macOS Devices. TL;DR: Enroll your Apple devices in Applivery using methods like User Enrollment, Apple Configurator, or DEP for enhanced management. Key topics: Apple Device Enrollment, Mobile Device Management, MDM, Apple, Applivery, Apple Configurator, DEP, User Enrollment Once your [Apple Enterprise](https://docs.applivery.com/en/device-management/apple/get-started/) is configured, you can start enrolling your Apple Devices in Applivery. Let's take a look at the available enrollment methods. :::info If you need to onboard several people at the same time, you can invite them all in one go with a [Bulk Enrollment](https://docs.applivery.com/en/device-management/general-settings/bulk-enrollment/). ::: ### Enrollment options Apple provides multiple ways to enroll Devices depending on your use case, the type of device ownership (corporate-owned vs. BYOD), and the level of control you need over the Device. All enrollment methods result in the Device being managed by Applivery, but they differ in two key aspects: - **Supervision**: Supervised Devices give administrators significantly more control over the Device, including restrictions, silent app installation, and advanced configurations. It's generally intended for corporate-owned Devices. You can learn more about it [here](https://docs.applivery.com/en/device-management/apple/supervision/). - **Unremovable MDM**: Some enrollment methods allow the MDM profile to be locked so the user cannot remove it, ensuring the Device always remains managed. #### Account-Driven User Enrollment Designed for **BYOD scenarios**. The user authenticates with a Managed Apple ID to enroll their personal device. It provides a clear separation between personal and work data, and gives the organization limited visibility over the Device — protecting user privacy. The Device is **not supervised,** and the MDM profile can be removed by the user. You can learn more about it [here](https://docs.applivery.com/en/device-management/apple/enrollment/account-driven-user-enrollment/). #### Account-Driven Device Enrollment A newer method (available since iOS 17 and macOS 14) for **corporate-owned Devices that are not registered in Apple Business**. Uses account-driven authentication and provides more management capabilities than User Enrollment. Mac computers enrolled this way are supervised, but iPhone, iPad, and Apple Vision Pro are not. You can learn more about it [here](https://docs.applivery.com/en/device-management/apple/enrollment/account-driven-device-enrollment/). #### Profile-Based Device Enrollment The **classic manual enrollment method** is typically done by sharing a link or QR code that the user opens in Safari. It does not require Apple Business. Mac computers are supervised upon enrollment, but iPhone, iPad, and Apple TV are not. The MDM profile can be removed by the user. You can learn more about it [here](https://docs.applivery.com/en/device-management/apple/enrollment/manual-enrollment/). #### Automated Device Enrollment (DEP) The most powerful enrollment method, designed for **Zero-touch corporate deployments**. Devices are registered in Apple Business and automatically enroll during initial setup — without any user interaction. All Devices are supervised, and the MDM profile cannot be removed by the user, making it the recommended method for organization-owned Devices. You can learn more about it [here](https://docs.applivery.com/en/device-management/apple/enrollment/dep/). #### Apple Configurator for Mac Allows enrollment by **physically connecting the Device to a Mac** running Apple Configurator via USB. It enables supervision without requiring Apple Business, though Devices enrolled this way have a 30-day provisional period during which the user can still remove the MDM profile. Supports iPhone, iPad, and Apple TV (Ethernet-only models). #### Apple Configurator for iPhone Allows adding **iPhone, iPad, Mac (T2 chip or Apple Silicon), and Apple Vision Pro** to Apple Business using an iPhone running the Apple Configurator app — without needing a Mac. The Device is enrolled by scanning a pairing image during Setup Assistant. Once added to Apple Business, Devices are supervised, though there is a 30-day provisional period during which the user can still release the Device from management. You can learn more about Apple Configurator Enrollment [here](https://docs.applivery.com/en/device-management/apple/enrollment/apple-configurator/). ### Enrollment methods | Enrollment Method | Supported Devices | Min. OS Version | Supervised? | Unremovable MDM? | Typical Use Case | | --- | --- | --- | --- | --- | --- | | **Account-driven User Enrollment** | iPhone, iPad, Mac, Apple Vision Pro | iOS 15, iPadOS 15, macOS 14, visionOS 1.1 | ❌ | ❌ | BYOD | | **Account-driven Device Enrollment** | iPhone, iPad, Mac, Apple Vision Pro | iOS 17, iPadOS 17, macOS 14, visionOS 1.1 | ❌ (iPhone, iPad, Vision Pro) ✅ (Mac) | ❌ | Corporate-owned, no DEP | | **Profile-based Device Enrollment** | iPhone, iPad, Mac, Apple TV | iOS 4, iPadOS 13.1, macOS 10.7, tvOS 9 | ❌ (iPhone, iPad, Apple TV) ✅ (Mac) | ❌ | Manual enrollment via link or profile | | **Automated Device Enrollment (DEP)** | iPhone, iPad, Mac, Apple TV, Apple Watch, Apple Vision Pro | iOS 13, iPadOS 13.1, macOS 10.14.4, tvOS 13, watchOS 10, visionOS 2.0 | ✅ | ✅ | Corporate-owned, Zero-touch deployment | | **Apple Configurator for Mac** | iPhone, iPad, Apple TV (Ethernet only) | macOS (host) | ✅ | ❌ (30-day provisional period) | Add Devices to Apple Business without DEP purchase | | **Apple Configurator for iPhone** | iPhone (iOS 16+), iPad (iPadOS 16.1+), Mac (macOS 12.0.1+, T2/Apple Silicon), Apple Vision Pro (visionOS 26+) | iOS 16 (host) | ✅ | ❌ (30-day provisional period) | Add Devices to Apple Business without a Mac | --- ## Manual Enrollment Source: https://docs.applivery.com/en/device-management/apple/enrollment/manual-enrollment/ Description: Manually enroll Apple Devices in Applivery using Enrollment links and the Enrollment site — covers iOS and macOS Devices. TL;DR: Enroll Apple devices in Applivery MDM using enrollment links or the enrollment site with this step-by-step guide. Key topics: Apple device enrollment, MDM configuration, Enrollment link process, Enrollment site process, Applivery Dashboard, Applivery, Apple, iOS, Apple Configurator, Apple DEP Manual Enrollment (Profile-based Device Enrollment) is the traditional manual enrollment method for Apple Devices. It works by delivering an MDM configuration profile directly to the Device — either via a link, QR code, or a dedicated enrollment site — which the user then installs from the Device Settings. It is one of the most flexible enrollment options since it requires **no Apple Business setup** and works on any iPhone, iPad, Mac, or Apple TV. However, it does not lock the MDM profile to the Device, meaning the **user can remove it at any time**. **Supervision and Mac:** On Mac computers with macOS 11 or later, Profile-based Device Enrollment **automatically enforces supervision**, which unlocks a significantly broader set of management capabilities compared to iOS and iPadOS Devices enrolled the same way. :::info This method is suitable for both corporate-owned and personal Devices where Apple Business or DEP is not available. For a fully locked, supervised, Zero-touch deployment, consider using [Automated Device Enrollment (DEP)](https://docs.applivery.com/en/device-management/apple/enrollment/dep/) instead. ::: ### Requirements - An [Apple Enterprise configured in Applivery](https://docs.applivery.com/en/device-management/apple/get-started/). - At least one [Device Policy created](https://docs.applivery.com/en/device-management/general-settings/create-policies/). - The target device must open the enrollment link in **Safari** (other browsers are not supported for profile installation on iOS/iPadOS). ### Manual enrollment (code or QR) Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), navigate to **Devices** and click **\+ Enroll device**. Fill out the form as follows: **Configure Enrollment Settings** - **Platform:** Make sure to choose **Apple** under Platform. - **Device Employee:** User who owns the Device. You can create a new employee by introducing the email address. - **Policy:** Choose the Policy to apply to the Device. You can do so under Policies if you haven’t created it yet. Alternatively, you can create a new Policy here and configure it later. - **Tags**: Define tags to organize, group, and filter Devices efficiently. - **Display name (optional):** A friendly name to easily identify the Device among the others. - **Expire after:** The expiration time of the enrollment token that will be generated. - **VPP Location**: Define the location to retrieve your VPP-licensed Apps. - **Skip personal information**: To prevent collecting info about personal Apps and network location - **Send instructions email to employee (optional):** Choose whether you want to send a notification to the user, including the enrollment instructions that will vary depending on the enrollment mode. ![enrollment form](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/0b9c7789-91f6-4497-a2db-1d73611a96c1.png) **Enroll the Device** Once the form is submitted, you will be presented with two options to deliver the enrollment profile to the Device: **Enrollment site (recommended for shared workflows)** A hosted website that requires the user to enter an enrollment code before downloading the profile. This adds a layer of security, as the link alone is not enough to enroll. 1. Share the enrollment URL and enrollment code with the user (or scan the QR code). 2. The user opens the link in **Safari** on the target device. 3. Enter the enrollment code and tap **Continue**. 4. Tap **Enroll** to download the configuration profile. 5. On the Device, go to **Settings > General > VPN & Device Management**. 6. Find Applivery's profile and tap **Install**. 7. Back in the Applivery Dashboard, click **Confirm enrollment** to verify the Device has enrolled successfully. If successful, you will be redirected to the Device details view. **Enrollment link (direct profile download)** A direct URL that immediately downloads the configuration profile when opened. Simpler to share but without the code protection layer. 1. Share the enrollment link with the user (or scan the QR code). 2. The user opens the link in **Safari** on the target device. The profile downloads automatically. 3. On the Device, go to **Settings > General > VPN & Device Management**. 4. Find Applivery's profile and tap **Install**. 5. Back in the Applivery Dashboard, click **Confirm enrollment** to verify the Device has enrolled successfully. If successful, you will be redirected to the Device details view. :::info **Note for macOS:** After downloading the profile, users must go to **System Settings > Privacy & Security > Profiles** to install it, as macOS does not install profiles automatically. ::: Select your preferred option, along with the Device type you will be enrolling, and then proceed with the steps. ![enrollment instructions](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/cd74ba4a-ccce-4207-b085-550f1563669f.png) --- ## Device Migration Source: https://docs.applivery.com/en/device-management/apple/enrollment/migrate-apple-devices/ Description: Migrate Apple Devices to Applivery from an existing MDM solution using Apple Business — no factory reset required. TL;DR: Migrate your Apple devices to Applivery seamlessly using Apple Business Manager, preserving data and apps without a factory reset. Key topics: MDM Migration, Apple Business, Device Enrollment, Applivery, iOS, iPadOS, macOS This process enables organizations to maintain business continuity while securely transitioning management, preserving Apps and data, and minimizing user disruption. It applies to Devices running **iOS 26**, **iPadOS 26**, or **macOS 26**, and is intended for users with **Administrator** or **Device Enrollment Manager** roles in Apple Business. :::info You can learn more about roles and privileges in Apple Business by following this [link](https://support.apple.com/en-gb/guide/apple-business-manager/axm97dd59159/web). ::: ### Overview Apple Business enables smooth transitions between MDM solutions—ideal for organizations moving from on-premises to cloud management, consolidating Devices after a merger, or switching providers. Key migration features include: - Setting a migration deadline (1–90 days). - Preserving Managed Apps and data on iPhone and iPad. - Managing Activation Lock settings. - Enforcing migration through device restarts when users don’t take action. - Canceling migrations before they start, reverting Devices to the original MDM. - Migrating iOS and iPadOS Devices **without a factory reset**. ### Requirements Devices must meet the following conditions to be eligible for migration: - Run **iOS 26**, **iPadOS 26**, or **macOS 26**. - Be **organization-owned** and enrolled via **Automated Device Enrollment (ADE)**. - For macOS 26, **profile-based enrollment** is also supported. - Devices enrolled via **Apple Configurator** must be past the **30-day provisional period**. :::warning If these conditions are not met, the migration deadline option will not appear in Apple Business, and bulk migration actions will fail, as logged in Apple Business’s activity log. ::: ### Before you begin **Prepare your Applivery Dashboard** Before starting migration, ensure your Applivery environment is properly configured: The first step is to create your **Apple Enterprise account** by uploading your **Apple Push Certificate** to Applivery. Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), navigate to the **Apple Setup** 1 section under the Settings section and follow the steps in [Get Started](https://docs.applivery.com/en/device-management/apple/get-started/). Once your Apple Enterprise account is set up, the next step is to configure your **Apple Business** integration. Start by connecting your **DEP** and **VPP** tokens, which will allow Applivery to import your Devices and manage app licenses automatically. To connect your **DEP** token, follow [DEP](https://docs.applivery.com/en/device-management/apple/enrollment/dep/). To configure **VPP** licenses, follow [VPP](https://docs.applivery.com/en/device-management/apple/app-management/vpp/). Once this is completed, you can begin creating **DEP profiles** and [assign them as the default](https://docs.applivery.com/en/device-management/apple/enrollment/default-assignments/) for any Device enrolled via Apple Business. If applicable, set up [**Smart Enrollment**](https://docs.applivery.com/en/device-management/apple/enrollment/smart-enrollment/) as the default for Apple Business Devices. Finally, ensure that all **device Policies** include the previously installed Managed Apps to prevent any data loss during the migration process. **Migration process** Sign in to [Apple Business](https://business.apple.com/) as an Administrator or Device Enrollment Manager, navigate to the **Devices** section, and select the **target device**. Select **Assign Device Management**, and choose **Applivery** as the destination MDM. Optionally, you can **set a migration deadline** (1–90 days); if this option is unavailable, the Device does not meet the migration requirements. Once you have verified all settings, click **Confirm** to proceed. ![assign device management](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/80d64054-543b-49bb-b5eb-a207229a86de.png) :::info You can also select multiple Devices for migration by holding the Command key while clicking and selecting the desired Devices. ::: **Sync with Apple Business** Back in the Applivery Dashboard, simply click the **Sync with Apple Business** button to start the synchronization process and retrieve the latest updates from Apple Business. Any newly added Devices will appear in the list below. ![sync with abm](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/b30f7c2c-ed6a-4940-8328-d2aedcaa0ffe.png) :::info After syncing, Devices begin receiving notifications prompting users to start migration. These increase in frequency as the deadline approaches—daily reminders, then hourly alerts during the final 24 hours, and countdown notifications in the last hour. If a Device loses connectivity after unenrollment, a Wi-Fi picker will appear to continue setup. ::: **End-user experience** ##### **Initial notification** Users receive a notification that migration to Applivery has begun. They can choose **Start Enrollment** or **Not Now** (to postpone). ![initial notification](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/f0387cad-67a7-4823-ab8d-8aefd427452b.png) ##### Enrollment Selecting **Start Enrollment** redirects users to **Settings > VPN & Device Management** to initiate Applivery enrollment. ![enrollment](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/dfd98c0d-27f7-4150-a972-ae89290f994d.png) When enrollment starts—or when the migration deadline is reached—the Device automatically restarts to apply the new configuration. After the restart, users are prompted to complete the enrollment process. If the deadline has not yet passed, they can choose to delay one final time; otherwise, enrollment is required. After migration, a Device may either complete successfully or fail. In a **successful enrollment**, the Device confirms the migration and reinstalls Apps and configurations over the air. In the case of a **failed enrollment**, the Device becomes unmanaged, and you should contact the administrator for assistance. **Editing or canceling a migration** To modify or cancel a migration for a single device, sign in to Apple Business, navigate to **Devices**, select the target device, click **Change Deadline** to modify or remove it, and then click **Save**. For multiple Devices, select the desired Devices in Apple Business, click **Unassign or Reassign**, adjust the deadline as needed, and click **Save**. :::warning Canceling a migration restores the Device to its previous MDM configuration and removes migration notifications. ::: **Activation Lock management** During migration, Applivery manages the Device’s Activation Lock status depending on its pre-migration state. | Pre-Migration State | Migration Behavior | Post-Migration Outcome | | --- | --- | --- | | No Activation Lock | Applivery can enable Activation Lock during migration | Device may have Activation Lock enabled and a new bypass code generated | | Activation Lock from previous MDM | Existing Activation Lock is removed during migration | Applivery applies a new Activation Lock, invalidating previous bypass codes | | Activation Lock handling (general) | Applivery sends an Activation Lock request to Apple Business before migration completes | A new bypass code is generated and managed through Applivery | | Migration failure | Apple Business retains the Activation Lock | Device can be unlocked via Apple Business; previous locks and bypass codes are no longer valid | --- ## Smart Enrollments Source: https://docs.applivery.com/en/device-management/apple/enrollment/smart-enrollment/ Description: Automate Apple Device Enrollment and Policy assignment with Applivery Smart Enrollments — define rules based on User and Device attributes. TL;DR: Automate Apple device enrollment and policy assignment with Applivery's Smart Enrollments by defining rules based on user and device data for a streamlined MDM workflow. Key topics: Apple Device Enrollment, Conditional Policy Assignment, Smart Enrollment Configuration, Auxiliary Fields, DEP Integration, Applivery, Smart Enrollments, Apple DEP, Apple Business, SSO If you have ever dreamed of automating 100% of the Device enrollment process and conditional policy assignment based on user data (name, email, User Groups) or the Device data (IMEI, Serial Number, etc), **Smart Enrollments** are the tool you were looking for. ### Introduction Smart Enrollments are the most efficient way to manage device enrollments in an unattended manner since will allow you to **define a set of rules and conditions that must be met for a Device to be enrolled** and, in addition, will allow you to **conditionally assign Policies** based on these rule sets. Smart Enrollments are useful for: - Limit device enrollment. - Based on user authentication through [SSO integrations](https://docs.applivery.com/en/platform/authentication/sso/) (User Groups or email patterns). - Based on device information (IMEI, Serial Number). - Conditionally assign different Policies based on rules. - Automate Apple DEP enrollments to enable unattended Zero-touch experiences. - Create local accounts based on user information retrieved after the authentication through Applivery Connect ([SSO integration](https://docs.applivery.com/en/platform/authentication/sso/)). :::info Smart Enrollments is a feature that **only works with Devices that are enrolled through the Apple Device Enrollment Program (DEP)**. You can read more about Apple DEP [here](https://docs.applivery.com/en/device-management/apple/enrollment/dep/). ::: ### Smart Enrollment configuration Let’s get started configuring your first Smart Enrollment. First, go to **Automation** 1, select **Smart Enrollments** 2, and choose **Apple** 3 as the platform from the left-hand menu. Then click the **\+ Create Smart Enrollment** 4 button. ![Smart Enrollment](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/244f1a61-b7dd-45cc-aeb9-edae4d64d54c.png) **Configure Smart Enrollment** 1. **Name:** Choose a friendly name for your new Smart Enrollment. 2. **Description:** Choose a friendly description for your new Smart Enrollment. 3. **Login providers**: The SSO providers configured at the Workspace level will be displayed. However, you can also configure the specific integration at the Smart Enrollment level by clicking **Override**. 4. **Policy:** Choose the Policy that will be applied to the Device from the Policies library. If you still don’t have any pre-defined Policies, just type a name, and a new empty policy will be created. 5. **Target segment**: Choose the [Segment](https://docs.applivery.com/en/device-management/general-settings/segments/) that enrolled Devices will be assigned to. 6. **Tags**: Used for filtering and grouping. 7. **VPP Location:** Choose the VPP Location that will be used to manage app licenses. 8. **Allow Activation Lock**: Allow Devices to use Activation Lock when the user enables Find My. 9. **Setup assistant**: Activate the Applivery Setup Assistant during enrollment (only for macOS Devices). :::info When the login provider is configured as **Anonymous**, you can enable the **Auto-continue** option, which allows Devices to continue enrollment automatically when no user interaction is required. ::: ![Smart Enrollment form](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/1870be66-fbb7-4a18-9482-813e2471f90a.png) **Configure Auxiliary Fields** 10. **Auxiliary fields**: By filling out this form, you will be able to configure device tags during enrollment. ![auxiliary fields](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ac4d9a03-f6a7-40b8-ac5a-e54e8bf0893c.png) By using Auxiliary fields, you can define a **flexible enrollment structure** that adapts to the organizational characteristics of your company. This allows users to enroll their Devices **according to specific requirements**, while enabling administrators to apply different configurations based on these selections. These Auxiliary fields can be used to generate device tags during enrollment, which function as conditional parameters. You can create as many fields as needed and later associate them with the corresponding Policies for each scenario. :::info For **iOS Devices**, supervision is mandatory. This means that the Device must be enrolled through a **DEP profile** and managed in **Apple Business**. ::: During the initial enrollment process from Apple Business, the Device will display a message indicating that it is managed. ![remote management](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/a7794950-7bfa-4016-80ed-f07c2cd0780d.png) After continuing, the user will be presented with the dropdown menus defined in the Auxiliary fields, based on the organization’s requirements. Once the required fields are selected, the user will authenticate using the method enabled by the organization, and the appropriate Policies will be applied according to the assigned tags. ![auxiliary fields device](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/b72fc972-4563-4cf4-a99d-e021d23eb0c5.png) The Device will then complete the enrollment and apply the configurations in the background. **Configure Display Name Pattern** 11. **Display name pattern**: Assign a display name by combining device properties. ![interpolation tags](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/49359994-18ef-4557-be60-41557704b028.png) If you click **Save** at this point, you will have finished setting up your basic Smart Enrollment and will be able to start enrolling Devices. **Configure Account configuration** 12. Optionally, configure the **Account configuration** form to create local accounts automatically. Note that both Admin and Primary accounts can be created at the same time. You can also use [placeholders](https://docs.applivery.com/en/platform/authentication/sso/) that will be replaced automatically with the information coming from the SSO authentication process. - **Admin account** supports configuring the Full name, User name and password of the user. You can also hide it from the login window and some other options. - **Primary account** supports configuring just the Full name and Username. The password must be selected by the user when configuring the Device for the very first time. ![account configuration](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/6869552a-64e2-4965-8d31-1081eddda608.png) **Applying conditions and rules** Now that you have your basic Smart Enrollment configured, you can add **Conditions** 5 and **Rules** 6 that will make it smarter. ![conditions and rules](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/09a64dfd-32ff-454e-9a31-4c1b5f93efe0.png) Use the **Add condition** option to enable enrollment limits based on user information (such as email patterns or groups) and device information (IMEI, Serial number, and auxiliary fields). You can use conditional operators to make it as complex as you need. ![conditions](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/00339b9d-db99-4d35-aa12-ca663822652d.png) You can also use the **Add additional rule** option to create groups of conditions, each of them with a target policy. As you will see, each group of conditions will also have as many **Conditions** as you need. ![rules](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/4b3e4adf-4d28-4397-bbb8-356f296e5cbe.png) Once done, click **Save**. **Deploying Smart Enrollments** To finish, you have to assign Smart Enrollments to your Apple Business DEP Devices, so head to the **Settings** section and locate the **Apple DPP** 7 section in the left-hand menu. Select one of your **DEP** Devices 8 and click **Configure** 9 below the **Smart Enrollment** option that will appear in the side panel. ![assign Smart Enrollment](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/43b0515a-52f1-4cba-bea9-f570a74fe3b0.png) Last, choose a Smart Enrollment from the dropdown list and then click **Assign** to finish. --- ## Get Started Source: https://docs.applivery.com/en/device-management/apple/get-started/ Description: Set up Apple Push Certificates for Applivery MDM to enable your Workspace to interact with Apple services and manage Devices. TL;DR: Configure Apple Push Certificates in Applivery MDM to enable iOS device management by downloading a CSR, creating a certificate in the Apple Push Certificate Portal, and uploading it back to Applivery. Key topics: Apple Push Certificate, CSR Generation, Applivery MDM Configuration, Applivery, Apple, CSR, PEM Before starting using Applivery Apple Device Management, there are a few steps you must go through in order to enable your Workspace to interact with Apple services and register your Apple Enterprise organization. The next steps will guide you through the process: **Download Applivery's Certificate Signing Request (CSR)** Sign-in to the [**Applivery Dashboard**](https://dashboard.applivery.io/) and navigate to the **Settings** section, and locate the **Apple Setup** section in the left-hand menu. Besides step 1, click the **Download CSR** button. ![apple enterprise setup](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/8b54c912-a61f-4eb0-bf0b-10a49f58307c.png) A file named `Applivery-CSR.csr` will be downloaded to your computer. **Create an Apple Push Certificate** Now visit [Apple Push Certificate Portal](https://identity.apple.com/pushcert/) and log in with your **Apple ID**. Once inside the portal, click on the **Create a Certificate** button. ![](https://www.applivery.com/wp-content/uploads/2022/05/applivery-apple-push-portal-1024x651.png "applivery-apple-push-portal | Applivery") Read and accept the Terms of Use. ![](https://www.applivery.com/wp-content/uploads/2022/05/applivery-apple-push-terms-1024x651.png "applivery-apple-push-terms | Applivery") Select and upload the `Applivery-CSR.csr` file you downloaded in Step 1 and click **Upload**. ![](https://www.applivery.com/wp-content/uploads/2022/05/applivery-apple-push-upload-1024x651.png "applivery-apple-push-upload | Applivery") Click on **Download** and save the certificate `.pem` file. ![](https://www.applivery.com/wp-content/uploads/2022/05/apple-push-download-1024x651.png "apple-push-download | Applivery") **Upload your Apple Push Certificate to Applivery** Now get back to Applivery’s dashboard and, beside step 5, click **Select** and upload the certificate (`.pem` file) downloaded from the previous step. Then click **Finish registration** button to finish. ![finish setup](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/8d48306d-d7f9-4341-aeeb-cdfd0edd8cbf.png) :::warning We highly recommend filling in the **Apple ID** field in Step 2, as the Apple Push Certificate must be renewed annually using the same account to ensure uninterrupted device management. Otherwise, you may lose control over enrolled Devices. See [Renew the Apple Push Certificate](https://docs.applivery.com/en/device-management/apple/renew-push-certificate/) for the renewal, and for what to do if nobody remembers which Apple ID was used. ::: --- ## iOS & iPadOS Source: https://docs.applivery.com/en/device-management/apple/ios-ipados/ Description: iOS and iPadOS Device Management in Applivery — secure, monitor, and manage corporate Devices, automate provisioning and Policy enforcement. TL;DR: Endpoint Management is a centralized platform for managing and securing all corporate devices. Key topics: endpoint management, device security, centralized management, mobile devices, tablets, computers Applivery enables you to manage iPhone and iPad Devices at scale through Apple's official MDM APIs. You can automate enrollment, deploy Apps silently, enforce Policies, run remote commands, and monitor Device status — without ever touching the Device physically. Manage Policies, remote commands, and platform-specific troubleshooting for iOS and iPadOS. --- ## Commands Source: https://docs.applivery.com/en/device-management/apple/ios-ipados/commands/ Description: iOS Commands in Applivery for remote Device Management — lock, wipe, refresh, and manage security on iPhones and iPads. TL;DR: Applivery enables administrators to remotely manage iOS devices using commands for actions like locking, wiping, and refreshing devices. Key topics: iOS device management, Applivery, Remote commands, Security actions, Device management, iPhone, iPad iOS and iPadOS MDM Commands let you perform real-time remote actions on managed iPhones and iPads — locking a Device, clearing a passcode, wiping data, restarting, or sending a push notification to prompt re-enrollment. Each remote command available for iOS and iPadOS includes when to use it and what happens on the Device when it's executed. --- ## Return to Service Source: https://docs.applivery.com/en/device-management/apple/ios-ipados/commands/return-to-service/ Description: Use Apple's Return to Service Command on iOS to securely reset Devices for reuse and simplify Device turnover with MDM Enrollment. TL;DR: The Return to Service command simplifies iOS device resetting and re-enrollment for quick and secure device turnover. Key topics: Return to Service command, iOS device resetting, MDM enrollment, Configuration profiles, Device management automation, Apple, iOS, MDM, Applivery, mobileconfig The **Return to Service** command from Apple is a powerful feature for iOS Devices that streamlines the process of wiping, resetting, and preparing a Device for reuse or reassignment within an organization. It’s designed to minimize manual IT effort while ensuring Devices are securely reset and ready for the next user. ### What does it do? - Securely erases all user data and settings, protecting privacy and maintaining compliance. - Supports automatic reconfiguration by including key profiles (e.g., Wi-Fi, MDM enrollment), enabling the Device to reconnect to the network and re-enroll in management after the reset. - Bypasses initial setup screens so the Device boots directly to the home screen—fully configured and ready to use. ### When is it used? - For rapid redeployment of shared or rotating Devices in schools, healthcare, corporate environments, kiosks, etc. - After device repairs or maintenance, return Devices to a known-good state. - During migration from one MDM system to another. - To meet security and privacy standards for handling corporate or personal data. In summary, the **Return to Service** command simplifies secure device turnover in managed environments. It enables IT teams to remotely reset and prepare Devices for immediate reuse, saving time, reducing manual work, and improving operational efficiency. ### Send the Return to Service command to your iOS device **Prepare your Device** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), go to any of your **Devices**. Select the **Commands** 1 tab and click **\+ New Command** 2. From the list of available commands, choose **Erase Device** 3. ![erase device](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/7afd8152-170e-4641-9e42-ccae768f53a9.png) **Enable Return to Service** In the configuration options for the **Erase Device** command, make sure to enable the **Return to Service** feature. ![enable return to service](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/e0bfbe53-6b37-46a9-9995-f2b269ff5c58.png) **Upload Enrollment Profile** As part of this process, you’ll need to provide an **enrollment** `.mobileconfig` file, which will be automatically applied once the Device is wiped, ensuring it re-enrolls into your MDM environment without manual intervention. To generate this file, just follow the instructions outlined in the [manual enrollment](https://docs.applivery.com/en/device-management/apple/enrollment/manual-enrollment/) section of our documentation. **Optional: Upload Wi-Fi Profile** Optionally, you can also include a Wi-Fi `.mobileconfig` profile to allow the Device to reconnect to the network automatically after the reset. :::info Make sure your `.mobileconfig` files are valid and properly configured for seamless re-enrollment and network connectivity. ::: --- ## Set Time Zone Source: https://docs.applivery.com/en/device-management/apple/ios-ipados/commands/set-time-zone/ Description: Remotely set the time zone on supervised iPads and iPhones running iOS/iPadOS 14 or later using Applivery Device Management Commands. TL;DR: Use Applivery to remotely set the time zone on supervised iOS devices (iOS/iPadOS 14+) via the Device Management section. Key topics: iOS Device Management, Mobile Device Management, Remote Configuration, Applivery, iOS, iPadOS With Applivery, you can change the time zone on a supervised iPad or iPhone with iPadOS or iOS 14 or later. :::info The time zone cannot be changed on Devices with the **Force Automatic Date and Time** restriction enabled. ::: ### Setting the Time Zone Once in the [**Applivery Dashboard**](https://dashboard.applivery.io), go to any of your **Devices**. Click the **Action** button and select **Set Time Zone**. Ensure the time zone entered is a valid **IANA** time zone name. ![time zone](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/6925ed5d-b788-4e99-8697-49ed513b8a8d.png) :::info Additionally, you can set the time zone in bulk from the Devices list by clicking the **Action** button, selecting **Apple** as the platform, and choosing the **Set Time Zone** command. ::: --- ## Policies Source: https://docs.applivery.com/en/device-management/apple/ios-ipados/policies/ Description: iOS Device Management Policies in Applivery — configure and enforce Policies across iPhones and iPads from a centralized Dashboard. TL;DR: Applivery simplifies iOS device management by providing a centralized dashboard to configure and enforce policies across iPhones and iPads. Key topics: iOS device management, Applivery, Security policies, Device configuration, Compliance, iOS, iPhone, iPad iOS and iPadOS Policies in Applivery let you configure and enforce settings across your managed iPhones and iPads. From passcode requirements and restrictions to App behavior, VPN, [Wi-Fi](https://docs.applivery.com/en/device-management/apple/apple-policies/configure-wifi-networks/), and certificates, Policies give you full control over every enrolled Device. Policy settings for iOS and iPadOS are organized by category. --- ## Block or Allow URLs in Chrome Source: https://docs.applivery.com/en/device-management/apple/ios-ipados/policies/block-allow-urls-chrome/ Description: Restrict which websites your users can visit in Google Chrome on managed iPhones and iPads, using Chrome's managed app configuration in Applivery. TL;DR: Add URLBlocklist and URLAllowlist to Chrome's Configuration field in your iOS/iPadOS Policy, as JSON arrays at the root. No supervision needed, and Chrome must be restarted to apply them. Key topics: Chrome URL policies on iOS and iPadOS, Managed app configuration, URL filter syntax, Verification with chrome://policy, Applivery, Apple, Google Chrome, iOS, iPadOS If your users browse with Google Chrome on their iPhones and iPads, you can decide which websites Chrome is allowed to open — block a couple of distracting sites, or lock Chrome down to a short list of work tools. You do it from the Chrome app entry in your Policy, through its managed app configuration. ### Chrome vs. Apple's Web Content Filter These properties only control **Google Chrome**. If you need to restrict Safari, use Apple's native [Web Content Filter](https://docs.applivery.com/en/device-management/apple/ios-ipados/policies/web-content-filter/) instead. The two mechanisms are independent: blocking a URL in one doesn't block it in the other.

Chrome URL blocking

Web Content Filter

Scope

Google Chrome only

Safari and WebKit

Where you set it

Policy → Apps → Google Chrome → Configuration

Policy → Web Content Filter configuration

Supervision required

No

Yes

### Prerequisites - Google Chrome is added as an app in your iOS/iPadOS Policy. The configuration only reaches Chrome when it's installed as a managed app. - **The device doesn't need to be supervised.** - Access to a test device, so you can check the result in `chrome://policy`. ### Configuration **Open your Policy** In the [**Applivery Dashboard**](https://dashboard.applivery.io/), go to **Policies** 1 and select your iOS/iPadOS Policy. **Open Google Chrome** Go to **Apps** 2, and add or edit the **Google Chrome** 3 entry. ![chrome managed properties](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/c3faf3fb-bacb-4deb-88e4-5d8fea337975.png) **Add the properties** In the **Configuration** field, add `URLBlocklist` (and `URLAllowlist` if you need exceptions). You can use either **JSON** mode or **Property** mode — both produce the same result. See the examples below. ![urlblocklist](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ba9c020f-6a3c-47c2-9783-978147e3bc4e.png) **Save and apply** Save the changes and apply the Policy to your devices. **Restart Chrome on the device** Fully close Chrome and open it again so it picks up the new configuration. #### Blocking specific sites **JSON mode** — paste the object with the list as a JSON array: ```json { "URLBlocklist": [ "facebook.com", "x.com" ] } ``` **Property mode** — click **\+ Add Property** and fill it in: - **Key**: `URLBlocklist` - **Value**: `["facebook.com","x.com"]` #### Allowing only a list of sites Block every site with `*`, then list the exceptions in `URLAllowlist`: ```json { "URLBlocklist": [ "*" ], "URLAllowlist": [ "mail.google.com", "applivery.com" ] } ``` In Property mode, add two properties: `URLBlocklist` with the value `["*"]`, and `URLAllowlist` with the value `["mail.google.com","applivery.com"]`. :::warning **Add the properties at the root.** `URLBlocklist` and `URLAllowlist` go directly in the Configuration field. Don't wrap them in a container key such as `ChromePolicy` — Chrome will show them as **Unknown policy** and ignore them. ::: ### URL filter syntax Entries follow Chrome Enterprise's filter format, `[scheme://][.]host[:port][/path][@query]` — the same syntax Applivery uses on every platform where `URLBlocklist` and `URLAllowlist` are available.

Entry

What it matches

facebook.com

The domain and all its subdomains. You don't need a separate *.facebook.com entry.

.www.example.com

Only that exact host. Other subdomains stay reachable.

*

All hosts. It's a special value on its own, not a wildcard you can put inside a hostname.

:::info **When the two lists collide, the most specific filter wins.** Chrome selects the filters with the longest matching host, then the longest matching path, then the longest set of query tokens. If a block and an allow filter are equally specific, **the allow filter takes precedence**. ::: For the full syntax reference, with more examples and special cases, see [URL Filters](https://docs.applivery.com/en/device-management/android/troubleshooting/url-filtering/). ### Checking it applied 1. On the device, open Chrome and go to `chrome://policy`. 2. Tap **Reload policies**. 3. Find `URLBlocklist` and `URLAllowlist`: the **Status** should be **OK** and the **Value** should match what you configured. 4. Try to open one of the blocked sites. Chrome should show its blocked-page message. ### Troubleshooting

What you see in chrome://policy

Likely cause

What to do

Status Error

One of the entries isn't valid syntax — for example *.domain.com, with a wildcard before the host.

Check each entry against the URL Filters syntax. Remember a bare domain already covers its subdomains.

Status Unknown policy

The properties were sent inside a container key such as ChromePolicy.

Move URLBlocklist and URLAllowlist to the root of the Configuration field.

Status OK, but the site still opens

Chrome hasn't been restarted since the Policy was applied.

Fully close Chrome and open it again.

An allowed site is still blocked

A more specific entry in URLBlocklist is matching it, or another app configuration on the same device conflicts.

Check which filter is more specific, and make sure no other configuration for Chrome is applied to the device.

### Blocking the website isn't blocking the app These properties only stop access **through Chrome**. If a service has its own native app, users can keep using it there. To stop people using the service itself, also block the app — see [Block & Allow Apps](https://docs.applivery.com/en/device-management/apple/app-management/block-allow-apps/). --- ## Book Deployment Source: https://docs.applivery.com/en/device-management/apple/ios-ipados/policies/book-deployment/ Description: Deploy and manage books on iOS Devices with Applivery — distribute individually or via Policies for managed Devices. TL;DR: Deploy books to iOS devices individually or via policies using the Applivery dashboard. Key topics: Device Management, Content Management, Policy Management, Applivery, iOS, Books :::warning Books (`.epub`, `.pdf`) are managed differently based on the Device they are deployed on. On iPhone and iPad, books must be deployed through the Device channel, meaning they will be available throughout the entire device for all users. **Please note that books cannot be assigned to macOS Devices**. ::: ### Deploying books to a single device Through the [**Applivery Dashboard**](https://dashboard.applivery.io/), navigate to any of your **Devices** 1. Then go to the **Books** 2 tab and click the **\+ Assign Book** 3 button. You can either select an existing book from the list of resources or upload a new one by clicking the **Upload new resource** 4 button. Choose the resource that you want from the dropdown list and then click **Add** 5. ![add book](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/2d3c3076-faa1-4d70-b79d-494b18299c15.png) The book will be automatically deployed to your Device. To **remove books** from the Device, simply click the **three dots** at the end of each book and choose **Unassign**. ![unassign book](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/326a8fd2-8a7e-4916-8b69-82a2ee994fc9.png) ### Deploying books to multiple Devices at once using Policies You can also manage Books, deploy them to multiple Devices, and maintain them synced by using **Policies**. Go to any of your **Policies** 6. From the left side menu, navigate to **Books** 7. Then click the **\+ Add book** 8 button. ![add book Policies](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/dab2ab09-7ac6-4b24-ab2f-f8bcecbac806.png) As mentioned before, you can either select an existing book from the list of resources or upload a new one by clicking the **Upload new resource** 4 button. Select a `.pdf` or `.epub` file from your files. ### Managing your Books You can see, manage, and download the entire list of books that you have uploaded by going to the **Resources** 9 section and selecting **Books** 10 from the left-hand menu. ![resources books](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/859dcba8-a200-4541-ba8e-20e2a8d73f15.png) --- ## Kiosk Mode Source: https://docs.applivery.com/en/device-management/apple/ios-ipados/policies/kiosk-mode/ Description: Configure Apple Kiosk Mode in Applivery to lock down supervised iOS Devices for single-App or multi-App environments. TL;DR: Apple Kiosk Mode, configurable through Applivery, locks down supervised iOS devices to a single app or a curated home screen layout for dedicated purposes. Key topics: App Lock configuration, Home Screen Layout configuration, Supervised devices requirement, Kiosk mode use cases, Apple, iOS, Applivery, App Store, Apple Volume Purchase Program (VPP) Kiosk mode is one of the most powerful tools available to IT administrators managing Apple device fleets. It allows you to dedicate Devices to a single purpose — locking them down to one App, a curated set of Apps, or a fully controlled home screen layout — preventing users from accessing anything outside of what the organization has defined. Applivery provides two distinct kiosk modes for Apple Devices, each suited to different deployment scenarios. :::warning Kiosk mode is only available on **supervised** Devices. See our [Apple Supervised Devices](https://docs.applivery.com/en/device-management/apple/supervision/) article for more information on how to supervise your fleet. ::: ### Available Kiosk Modes | Mode | Apps allowed | Best for | | --- | --- | --- | | **App Lock** | Single app | Dedicated-purpose Devices locked to one application. | | **Home Screen Layout** | Multiple Apps | Controlled multi-app environments with a curated interface. | * * * ### App Lock App Lock restricts the Device to a single application. Once active, users cannot exit the App or access any other part of the Device — it is the most restrictive kiosk mode available and the go-to choice for point-of-sale terminals, self-service kiosks, digital signage, or any single-purpose deployment. #### How to Configure App Lock App Lock is configured at the Policy level: **Add the App to the Policy** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), go to any of your **Policies** 1. From the left side menu, go to **Apps** 2 and click the **\+ Add App** button 3. ![add app](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/a7200ca3-bc7f-4b2c-a341-d77ff68e3888.png) Search for the App using the **App Store** or **Applivery** tabs, choose **iOS**, and indicate whether the App uses a **VPP license** (see [Apple Volume Purchase Program](https://docs.applivery.com/en/device-management/apple/app-management/vpp/) for details). **Restrict access to only that App** Follow the steps described in the following article to [configure an allow list of Apps](https://docs.applivery.com/en/device-management/apple/app-management/block-allow-apps/) to ensure no other application can be accessed on the Device. ![allow only some Apps](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/64b0d23c-953e-4ead-acae-f0368ead81fd.png) **Enable App Lock** From the left-hand menu, click **\+ Add Configuration** and select **App Lock** 4. ![app lock](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ff19b38b-70ec-4b01-b2f0-08e10ec87fed.png) Enter the **Bundle ID** of the application you want to lock the Device to and configure any additional settings as required (see options below). ![app lock configuration ](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/6c4ee7fd-d72f-42ed-bcc1-f1f23b8a8fc4.png) **Save** and deploy the Policy. #### App Lock configuration options When setting up App Lock, you can fine-tune the user experience and hardware behavior through the following options: **Touch and interaction** | Option | Description | | --- | --- | | Disable touch | Disables the touchscreen entirely. Useful for display-only Devices. | | Disable device rotation | Locks the screen orientation, preventing rotation when the Device moves. | | Disable volume buttons | Prevents the user from changing the Device volume. | | Disable ringer switch | Disables the ringer/silent toggle switch. | | Disable sleep/wake button | Prevents the user from putting the Device to sleep or waking it manually. | | Disable auto lock | Keeps the screen on permanently, overriding the auto-lock setting. | | Enable touch | Explicitly enables touch (useful when combined with other restrictions). | | Enable AssistiveTouch | Enables Apple's AssistiveTouch accessibility overlay. | | Enable zoom | Enables the zoom accessibility feature. | | Enable VoiceOver | Enables the VoiceOver screen reader. | | Enable Invert Colors | Enables the Invert Colors accessibility option. | ### Home Screen Layout Home Screen Layout allows administrators to define exactly which Apps, web clips, and folders appear on the Device's home screen, and in what arrangement. Unlike App Lock, users can switch between the allowed Apps — but they cannot access anything outside the curated layout. This mode is ideal for corporate-owned Devices where employees need access to a controlled set of tools: a field worker's device with only approved productivity Apps, a shared iPad in a meeting room, or a retail device with customer-facing and operational Apps side by side. #### How to configure Home Screen Layout Like App Lock, Home Screen Layout is configured at the Policy level. **Restrict access to the required Apps** Follow the steps described in the following article to [configure an allow list of Apps](https://docs.applivery.com/en/device-management/apple/app-management/block-allow-apps/) to ensure no other application can be accessed on the Device. ![allow only some Apps](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/64b0d23c-953e-4ead-acae-f0368ead81fd.png) **Configure Home Screen Layout** From the left-hand menu, click **\+ Add Configuration** and select **Home Screen Layout** 5. ![home screen layout](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/4bcdc29b-af5a-41e4-ad26-c38419675ea7.png) A Device-like visual editor appears. Use it to add Apps, web clips, and folders, and arrange them as they should appear on the Device's home screen. ![home screen layout configuration](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/1853b4e4-fb5a-4603-97c4-00ff6d65865b.png) **Save** and deploy the Policy. :::warning The **Settings app cannot be blocked** — it will always remain accessible to users regardless of the Home Screen Layout configuration. ::: ### Choosing the right mode | Scenario | Recommended mode | | --- | --- | | Point-of-sale terminal locked to a single POS app | App Lock | | Self-service kiosk or information display | App Lock | | Shared device with a curated set of work tools | Home Screen Layout | | Field worker device with approved Apps only | Home Screen Layout | | Digital signage or a display-only screen | App Lock (with touch disabled) | | Retail device with customer-facing and back-office Apps | Home Screen Layout | --- ## Block or Allow URLs in Safari Source: https://docs.applivery.com/en/device-management/apple/ios-ipados/policies/web-content-filter/ Description: Control which websites your users can visit in Safari on supervised iOS and iPadOS devices, using allowed and denied URL lists. Sometimes you need to decide, centrally, which websites a Device can reach — a shared iPad in a shop that should only open two internal tools, or a fleet where a handful of sites simply shouldn't be reachable. The **Web Content Filter** configuration is where you do that. It gives you two lists: sites you always allow, and sites you always block. Behind them, the matching rules are less literal than they look, and that's where most surprises come from. ### Prerequisites - The Device is **supervised**. System-level web content filtering on iOS and iPadOS, Safari included, only works on supervised Devices. - The Policy is correctly assigned to the target Device(s). ### Configuration **Navigate to Policies** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io), go to the **Policy** 1 you want to modify. From the left side menu, select **\+ Add configuration** and choose **Web Content Filter** 2. ![web content filter](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/5ec728a1-e267-4618-9504-dfa0f14412d2.png) **Fill in the lists** Add the sites you want to block to the denied list, the ones you always want reachable to the permitted list, or both. Once applied, a Device that tries to open a blocked site doesn't fail silently — Safari shows a **Website Blocked** message. #### What you can set

Setting

What it does

Automatic filtering

Apple's built-in filter, which blocks adult content automatically. Required if you want to use the permitted list.

Permitted URLs

Sites allowed even if the automatic filter would treat them as adult content. Leave it empty and every non-adult site is reachable except those you denied.

Denied URLs

Sites that are never reachable, even if the automatic filter considers them fine. Keep this list to no more than 500 URLs.

Hide denied URLs

From iOS 18, hides the denied list from the profile shown in Settings → General → VPN & Device Management.

Plug-in

Hands filtering to a third-party filter instead of Apple's built-in one.

:::info **The permitted list only works with automatic filtering turned on.** Apple ties the two together: if automatic filtering is off, permitted URLs have nothing to make an exception to, and the list does nothing. ::: :::info `*.apple.com` **and** `*.icloud.com` **are always reachable**, whether or not you list them. Don't spend time trying to block them. ::: ### How URLs are matched This is the part worth reading twice, because the filter doesn't compare URLs the way you'd expect. **Include the scheme.** Entries need `https://` or `http://`. If a site answers on both, add an entry for each. **Matching is by substring.** A URL matches an entry if the exact characters of that entry appear anywhere inside the requested URL. Blocking `example.com/a` therefore also blocks `example.com/apple`, `example.com/about` and `example.com/a/b`. :::warning **The** `www` **prefix is discarded before matching, and the consequences are wider than they look.** Blocking `www.example.com` leaves `example.com` as the pattern — which then matches `m.example.com` as well. So a rule you wrote for one hostname can quietly cover mobile subdomains and anything else containing that string. Check what else your entry catches before rolling it out. ::: **A subdomain doesn't cover the main domain.** Blocking `blog.example.com` leaves `example.com` reachable. If you want both, add both. **Trailing slashes are matched explicitly.** An entry ending in `/`, such as `example.com/a/`, covers `example.com/a` and `example.com/a/b`. **Redirects aren't followed.** If a blocked URL redirects somewhere else, the destination has to be on the list too — otherwise the redirect goes through. #### Examples

Goal

Entry

Result

Block a whole domain, subpaths included

https://example.com/

Blocks example.com and everything under it

Block one path prefix

https://example.com/a

Blocks example.com/a, example.com/apple, example.com/a/b — but not the main domain

Block a path explicitly

https://example.com/a/

Blocks example.com/a and example.com/a/b

Allow only a specific set of sites

Automatic filtering on + the sites in the permitted list

Those sites are always reachable

### When several policies apply Every filtering rule is active at the same time, and a site has to **pass all of them** to be reachable. In practice that means the restrictions add up rather than override each other: if any applied Policy denies a site, it's denied. If a site you expect to work is blocked, check **every** Policy assigned to the Device, not just the one you edited. ### Important considerations - **A blocked website is still reachable through its app.** If a social network is on the denied list but its app is installed, the user carries on as normal — the filter only covers web traffic. To close that gap, block the app too, as described in [Block and Allow Apps](https://docs.applivery.com/en/device-management/apple/app-management/block-allow-apps/). - **The filter covers Safari and WebKit.** Third-party browsers that don't use WebKit, and traffic generated by apps, fall outside it. For those, you need a plug-in filter or a network-level control such as a global HTTP proxy or filtered DNS. - **Enabling the filter disables clearing Safari history.** This is a documented Apple side effect, not a bug. From iOS 26 there's an explicit setting for it, which also blocks private browsing, since private mode keeps no history to retain. - **Users can't change any of this on the Device** while the profile is installed. - **This isn't a compliance-grade filter.** For strict regulatory requirements, or coverage beyond Safari, combine it with a global HTTP proxy, filtered DNS, or a third-party filter through the plug-in option. ### Unsupervised and personal Devices The built-in filter needs supervision, so it isn't available on unsupervised or user-enrolled Devices. The route there is the **plug-in** option with a third-party filter, which requires a **content filter UUID** — Apple makes that identifier mandatory precisely for unsupervised Devices and User Enrollment, from iOS 16 onwards. Managed apps carrying the same UUID share the filter. ### Troubleshooting

Symptom

Likely cause

What to check

A blocked URL is still reachable

The user is going through the native app, or a redirect lands on a URL that isn't listed

Block the app as well; add the redirect destination to the list

The profile doesn't install

The Device isn't supervised, or a plug-in filter is missing its identifiers

Confirm supervision; check the content filter UUID

A permitted site is still blocked

A contradicting entry exists in a denied list — possibly in a different Policy

Review every Policy applied to the Device; denied entries win

The permitted list has no effect

Automatic filtering is off

Turn automatic filtering on; the permitted list depends on it

Filtering doesn't cover other browsers or app traffic

Expected — the built-in filter covers Safari and WebKit

Consider a plug-in filter or a global HTTP proxy

--- ## Troubleshooting Source: https://docs.applivery.com/en/device-management/apple/ios-ipados/troubleshooting/ Description: Troubleshoot iOS device management issues in Applivery. Learn to resolve enrollment, configuration, & connectivity problems for iOS/iPadOS. TL;DR: Learn how to troubleshoot common iOS device management issues in Applivery, including enrollment, configuration, and connectivity problems. Key topics: iOS troubleshooting, Applivery, Enrollment issues, Configuration errors, Connectivity issues, iOS, iPadOS Diagnose and resolve common issues with iOS and iPadOS Device Management in Applivery — including enrollment failures, MDM profile installation errors, Policy conflicts, and App installation problems. Each article explains the likely cause and the steps to resolve it, so you can get Devices back under management quickly. --- ## Disable Lost Mode Without Internet Source: https://docs.applivery.com/en/device-management/apple/ios-ipados/troubleshooting/disable-lost-mode-without-internet/ Description: Disable Lost Mode on iOS Devices without an internet connection — solutions using SIM cards and RJ45 adapters. TL;DR: Disable lost mode on a device without internet by using a SIM card with data or a Lightning to RJ45 adapter to restore connectivity. Key topics: Lost Mode, Internet Connectivity, Troubleshooting, Device Management, Applivery, Apple, SIM Card, Lightning to RJ45 adapter Sometimes, when enabling lost mode on a Device, it can lose its internet connection, making it unreachable from Applivery. This prevents you from disabling the lost mode. The most common scenario is when an Apple device in lost mode runs out of battery and turns off. When it's turned on again, the Device has lost its internet connection. Therefore, it's impossible to send the ‘Disable lost mode’ command (or any command) through Applivery because there's no communication between the Device and Applivery. It's also not possible to connect it to a Wi-Fi network (neither through USB connecting it to the computer, nor sharing data from another Device…) since the screen will be locked down in lost mode. However, there are a couple of potential solutions: **Using a SIM Card** The first option is to use a SIM card with the PIN deactivated and an active data network. Insert it into the Device, and it will automatically connect to the internet and receive all pending commands, including the “disable lost mode” command. **Using a Lightning to RJ45 Adapter** A second option is to use a Lightning to RJ45 adapter to connect to an existing wired internet network. This achieves the same goal. :::info Ensure the SIM card has sufficient data and the Lightning to RJ45 adapter is compatible with the Device. ::: --- ## Restore in DFU Mode Source: https://docs.applivery.com/en/device-management/apple/ios-ipados/troubleshooting/restore-dfu-mode/ Description: Restore your iPhone or iPad using DFU mode — step-by-step instructions for reinstalling firmware when standard recovery fails. TL;DR: Restore your iPhone or iPad to factory settings using DFU mode by following these steps: backup, enter DFU mode, and restore using your computer. Key topics: DFU mode, iPhone restore, iPad restore, Firmware update, iPhone, iPad, Apple, Finder, iTunes, Apple Devices :::warning This process will erase all data on your Device, so make sure you back up your data first. - **Device Models:** The button combo can vary even within the same generation of Devices. - **Updated Software:** Make sure you have the latest version of Finder, Apple Devices, or iTunes installed. - **Official Docs:** Always refer to Apple’s official documentation for the most accurate and up-to-date instructions for your Device. ::: Restoring your Device in **DFU mode** (Device Firmware Update) is a deep-level process that lets you reinstall the firmware on your iOS device. It’s typically a last resort when other restore methods have failed and your Device isn’t responding. #### But, how do I restore the Device? **Preparation** - **Backup:** Make a full backup of your data on iCloud or iTunes. - **Connection:** Plug your iOS device into your computer using the original USB cable. **Entering DFU Mode** - **Power Off:** Turn off your iOS device. - **Button Combo:** The exact button combo depends on your Device model. Check out the official Apple guides for detailed instructions: - [Restore your iPad](https://support.apple.com/en-gb/108925) - [Restore your iPhone or iPod touch](https://support.apple.com/en-gb/118106) **Restoring** - **Software:** Open the right app on your computer: - macOS: Finder - Windows 10 or later: “Apple Devices” app - Older Windows versions: iTunes - **Recovery Mode:** Your Device should show up in the App as being in recovery mode. DFU mode is powerful, but use it carefully. Always back up your data before starting. If you’re unsure, check Apple’s official docs or get help from a professional. --- ## macOS Device Management Source: https://docs.applivery.com/en/device-management/apple/macos/ Description: macOS Device Management in Applivery — automate provisioning, enforce security Policies, and maintain compliance at scale. TL;DR: macOS device management allows organizations to manage, secure, and maintain compliance of macOS devices at scale using MDM solutions like Applivery. Key topics: macOS Device Management, Mobile Device Management (MDM), Device Security, App Provisioning, Device Compliance, macOS, Applivery, MDM Applivery enables you to manage macOS Devices at scale through Apple's official MDM APIs. You can automate enrollment via Apple Business, deploy Apps and scripts, enforce security Policies, manage FileVault and activation lock, and run remote commands. Manage Apps, Policies, remote commands, and platform-specific troubleshooting for macOS. --- ## App Management Source: https://docs.applivery.com/en/device-management/apple/macos/app-management/ Description: Simplify macOS app management with Applivery. Deploy, update, and secure apps on macOS devices from a centralized dashboard. Learn more! TL;DR: Applivery simplifies macOS app management with a centralized dashboard for deploying, updating, and securing apps at scale. Key topics: macOS App Management, Applivery Features, App Deployment, Security Policies, Centralized Management macOS App Management in Applivery lets you deploy and maintain applications on managed Mac computers at scale. You can distribute Apps from the Mac App Store via VPP, deploy PKG installers, push third-party security tools, and configure App behavior through Policies. Distribute Apps on macOS with different methods, deploy common enterprise applications step by step, and manage App updates and configurations. --- ## App Catalog Source: https://docs.applivery.com/en/device-management/apple/macos/app-management/app-catalog/ Description: Easily install and manage macOS applications not available on the App Store with Applivery's macOS App Catalog. Simplify deployment and control user access. Can’t find it on the App Store? No worries! The **Applivery macOS App Catalog** manages it all. With the Applivery macOS App Catalog, you can easily install macOS applications that aren’t yet on the App Store. Our platform simplifies the entire process, from downloading to installing any application. We host and update all applications for you, giving you full control over deployment and user access. You decide how Apps are deployed to your users, whether by enforcing installations or making them available for self-service. ### What is Applivery macOS App Catalog? The Applivery macOS App Catalog consists of popular macOS software, ready for you to include in your Policies and distribute to your Devices. Current Apps are updated regularly, with new ones continuously being added. ### How to add an App to your macOS Policy **Navigate to Policies** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), go to any of your **Policies** 1 or [create a new one](https://docs.applivery.com/en/device-management/general-settings/create-policies/). From the left-hand menu, select the **Apps** 2 section and click the **\+ Add App** 3 button. ![add app](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/c3deae50-2369-4ae7-b89b-c9b310e91a50.png) **Adding Apps from the App catalog** Once the modal view appears, navigate to the **Applivery** tab and select **macOS** as the platform. For the App Origin, select **App Catalog**. This will display the complete list of currently available applications. Additionally, in the **Build selection**, you can choose whether you want to install the latest version automatically or manually specify the version you wish to install. ![app catalog](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/5b50886e-9497-436f-967a-862c01329f4d.png) ### Available Apps Here's a glimpse of some of the Apps available in the catalog: **1Clipboard** Utilities. **1Password** Productivity. **Adobe Acrobat Reader** Productivity. **Aircall** Communication. **Android Studio** Developer Tools. **AnyDo** Productivity. Explore all Apps on the [Applivery macOS App Catalog](https://www.applivery.com/macos-app-catalog/). ### Requesting an App If you have an App in mind that you’d like us to include, please let us know through the [App request form](https://www.applivery.com/macos-app-catalog/app-request/). The demand for an App will greatly determine its priority for becoming an App of the Applivery macOS App Catalog. In addition, the basic requirements for an App to be included are: - The App must not be available on the Mac App Store or Apple Business. - The application must be intended for business or enterprise use. --- ## App Permissions with PPPC Profiles Source: https://docs.applivery.com/en/device-management/apple/macos/app-management/app-permissions/ Description: Use PPPC Profiles to remotely manage App permissions on macOS Devices — control access to services and enhance security with Applivery. TL;DR: PPPC profiles let IT admins remotely manage macOS app permissions, enhancing security and streamlining workflows. Key topics: PPPC profiles, macOS app permissions, Device Management, Security and Privacy, macOS, PPPC, Applivery, Apple, Photo Booth, FaceTime **PPPC profiles** (or Privacy Preferences Policy Control) enable IT admins to remotely manage privacy settings on macOS Devices (version 10.14 Mojave and later). With these profiles, you can pre-authorize or deny specific applications access to macOS services such as Contacts, Camera, Microphone, and more. This streamlines workflows by removing permission prompts for users and enhances security by preventing unauthorized access. ### Identifying App Permissions Before creating a PPPC profile, it’s important to identify the specific permissions an application requires: - **Test environment**: Install the App on a dedicated test Mac or virtual machine. - **Monitor user prompts**: Launch the App and take note of any pop-up prompts requesting access to services like the Camera or Documents. - **Check System Preferences**: Go to  **System Preferences > Security & Privacy > Privacy**. Look for the App under services such as Contacts or Camera. If the App appears, it requires access to that service. ### Creating and assigning a PPPC profile Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), go to any of your **Policies** or [create a new one](https://docs.applivery.com/en/device-management/general-settings/create-policies/). Click the **\+ Add configuration** button and locate the **Privacy Preferences Policy Control** option. ![privacy preferences](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/02586ccd-53c5-4aed-808e-ca4b08680d6d.png) You will need to click the **\+ Add element** button for the Apps where you want to configure permissions. :::info You can also choose to **Allow** or deny specific App access to each service. ::: ![ppc policy](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/08443b02-4be3-4f5d-ae33-42934564c26f.png) You will need to define the App to which you are granting permissions by specifying the **Identifier type** 4 and the **Bundle ID** or the App’s **path** identifier. Additionally, you must add the [**App’s Code Requirement**](https://docs.applivery.com/en/device-management/apple/macos/troubleshooting/app-code-requirements/). :::warning **Validate code requirement**. Check this option to ensure the App complies with the code signing requirements. ::: ### Important considerations - **Conflicting Policies**: If multiple PPPC profiles with conflicting settings are applied, the most restrictive setting (deny) will take precedence. - **User control**: Although Policies pre-configure App permissions, users can still access certain settings in Apple-developed Apps like Photo Booth or FaceTime. - **Device update**: Users must relaunch the configured Apps after Policy deployment for the changes to take effect. --- ## App Updates Source: https://docs.applivery.com/en/device-management/apple/macos/app-management/app-updates/ Description: Control when new app versions reach your Macs with Applivery's Update Policy: turn on Auto-updates, set a quarantine and a grace period per update type. TL;DR: On each app in a Policy, open Update Policy, turn on Auto-updates and set a quarantine and a grace period. New builds wait out the quarantine, stay optional during grace and are installed automatically after the deadline. Key topics: Auto-updates, Quarantine period, Grace period, Update deadline, Install types, Applivery, macOS, Applivery agent Every app you assign to a macOS Policy has an **Update Policy**. It lets you decide when new versions reach your Macs and when they stop being optional. You turn on **Auto-updates**, set how long a new build waits before it's offered (**quarantine**), and how long users have to install it before it's enforced (**grace period**). ### Before you start - macOS Devices managed by Applivery. - An app assigned to a Policy. The app's **install type** (Force installed, Required for setup or Available) changes what happens when Auto-updates is off. You'll find the three types explained in [Manage Apps](https://docs.applivery.com/en/device-management/apple/app-management/manage-apps/). - Access to the [Applivery Dashboard](https://dashboard.applivery.io/) with permission to edit Policies. ### The Update Policy options

Option

Range

What it does

Auto-updates

On / Off

Turns automatic updates on for this app. Quarantine and grace only apply when it's on.

Quarantine

0–30 days

Days a new build waits after its release before it's offered. One value for major, minor and patch updates.

Grace period (major, minor, patch)

0–90 days each

Days the update stays optional once quarantine ends. You set a separate value for each update type. With 0, there's no optional window.

:::info As soon as you set any grace period, Auto-updates must be on. ::: ### Configure the Update Policy **Open the app in the Policy** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), go to any of your **Policies** 1 or [**create a new one**](https://docs.applivery.com/en/device-management/general-settings/create-policies/). Select the Apps 2 section from the left-hand menu, and add the app or open one that's already assigned 3. ![app updates](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/22d3a0d8-f732-4469-9aad-64f784b1a884.png) **Set the Update Policy** Open **Update Policy** 4, turn on **Auto-updates,** and set the **quarantine** and the **grace period** for major, minor, and patch updates. ![automatic updates](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/4e108f25-d3b6-499d-89c1-eb4cf9db3a75.png) **Save** Save your changes. ### How the deadline is calculated Applivery calculates the deadline for each new build and sends it to the Applivery agent on the Mac: **Deadline = release date + quarantine + grace period for that update type** The grace period used depends on whether the new build is a major, minor or patch update. :::info The deadline is always counted from the build's release date. If the build reaches a Mac earlier for some reason, the deadline doesn't move. ::: ### What happens at each stage

Stage

What happens

Quarantine

The new build isn't offered. Your Macs get the newest build that has already cleared quarantine. If no build has cleared it yet, the app isn't served.

Grace period

The update is available, but installing it is optional until the deadline.

After the deadline

The Applivery agent installs the update. If the app is open, it's closed first and then updated.

:::info Quarantine doesn't hold back installs sent with an Apple MDM command, installs during Setup Assistant, assignments pinned to a specific build or [Policy Composition](https://docs.applivery.com/en/device-management/general-settings/policy-composition/). ::: ### When Auto-updates is off With Auto-updates off, there are no automatic updates after the first install. What that means depends on the install type:

Install type

Behavior

Force installed

First version only. No later automatic updates.

Required for setup

First version only. No later automatic updates.

Available

Users install updates themselves from the Self-Service app.

If you've never configured Auto-updates for an app, Applivery doesn't send any update policy and the Applivery agent keeps its default behavior. That isn't the same as turning Auto-updates off. ### Example **Patch update with Auto-updates on.** Quarantine is 3 days and the patch grace period is 7 days. A new build is released on Monday: 1. **Monday to Wednesday:** the build is in quarantine and isn't offered. 2. **Thursday:** quarantine ends and the grace period starts. Users can install the update whenever they want. 3. **The following Thursday:** the deadline passes and the Applivery agent installs the update on every Mac that's still on the previous version. **Force installed app with Auto-updates off.** New builds aren't applied automatically. Your Macs stay on the first version installed until you change the assignment or turn Auto-updates on. --- ## Cloudflare WARP Deployment Source: https://docs.applivery.com/en/device-management/apple/macos/app-management/cloudflare-warp-deployment/ Description: Distribute and enroll the Cloudflare WARP Zero Trust client on managed Macs from an Applivery Policy, with no user interaction. **Cloudflare WARP** is the client behind Cloudflare Zero Trust: it routes device traffic through Cloudflare's network so policies, filtering and identity checks apply wherever the Mac is. Deploying it by hand means installing the client on each machine and typing the organization name into it, which does not scale and rarely survives contact with a real fleet. With Applivery you push both halves from one Policy — the package and its configuration — so the client installs and enrolls itself with nobody touching the Mac. ### Requirements To deploy Cloudflare WARP on macOS through Applivery, make sure you have the following: - **The Cloudflare WARP package.** The macOS `.pkg` is available in the [Applivery App Catalog](https://docs.applivery.com/en/device-management/apple/macos/app-management/app-catalog/). - **A Cloudflare Zero Trust organization.** Free, Standard or Enterprise. The **Free plan covers up to 50 users**, which is usually enough for a pilot or a small team — check the seat count in the Cloudflare dashboard before assuming it covers everyone. - **Your Cloudflare team name.** The unique identifier of your Zero Trust organization. It goes into the profile as `organization`, so it has to exist before you generate the profile. - **Macs enrolled in Applivery.** Through Apple Business and Automated Device Enrollment for a silent, zero-touch rollout, or through manual enrollment. Without enrollment there is no managed way to push the profile. **Get your values from Cloudflare** Everything the profile needs comes from the **Cloudflare Zero Trust** dashboard:

Value

Where to find it

Team name (organization)

In Overview, shown as the team domain in the form your-team.cloudflareaccess.com. The value you need is just your-team, without the domain.

Service mode (service_mode)

Your own choice: warp for a full tunnel, which is the usual option for a VPN, or 1dot1dot1dot1 for DNS-only.

:::info The team name is not a secret. Any parameter that **forces behavior**, though — disabling logout, forcing auto-connect — changes the end user's experience, so agree those with the team before rolling out to production. ::: **Prepare the configuration profile** Cloudflare recommends keeping the payload minimal, so it configures enrollment without overriding what you already manage from the Zero Trust dashboard. If you would rather not write the XML by hand, [iMazing Profile Editor](https://apps.apple.com/us/app/imazing-profile-editor/id1487860882?mt=12) generates it for you. ```xml PayloadContent PayloadDisplayName Cloudflare WARP Client PayloadIdentifier com.example.profiles.warp-vpn.client PayloadType com.cloudflare.warp PayloadUUID GENERATE-A-UNIQUE-UUID-HERE PayloadVersion 1 display_name Example-Corp-WARP organization example-corp service_mode warp PayloadDisplayName Cloudflare WARP Configuration PayloadIdentifier com.example.profiles.warp-vpn PayloadType Configuration PayloadUUID GENERATE-A-UNIQUE-UUID-HERE PayloadVersion 1 ``` Before uploading it, adapt four things: - `organization`: your real Cloudflare team name, not the placeholder. - `service_mode`: `warp` for a full VPN tunnel. Change it only if your use case is different. - **Both** `PayloadUUID` **values**: generate fresh, unique UUIDs for every profile — the WARP payload's and the root profile's. Reusing them causes conflicts, especially if you keep several variants such as pilot and production. - `PayloadIdentifier`: use your own reverse-domain naming rather than whatever the editing tool generated. You can also set `display_name` to whatever the end user should see in the WARP client. It is worth doing if you will end up managing more than one organization. **Add the WARP package** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), go to any of your **Policies** 1 or [create a new one](https://docs.applivery.com/en/device-management/general-settings/create-policies/). From the left-hand menu, select the **Apps** 2 section and click the **\+ Add App** 3 button. ![add app](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/c3deae50-2369-4ae7-b89b-c9b310e91a50.png) In the modal view, navigate to the **Applivery** tab. Set the platform to **macOS**, choose **App Catalog** as the App origin, and search for **Cloudflare WARP**. For the **Build selection**, choose **Last** to ensure the latest version is always deployed. ![cloudflare warp](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/251eb271-dea4-40a2-bb98-39f748603342.png) **Import the configuration profile** Within the Policy, select **\+ Add configuration** from the left-hand menu, then choose **\+ Import** and upload your adapted `.mobileconfig`. This is the piece that actually sets `organization` and `service_mode`, and the reason no user interaction is needed. ![import profile](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/5a21e731-5b2a-4600-a14a-c2ebbad50d51.png) Once done, make sure to **Save changes** to apply the configuration. --- ## Cortex XDR Deployment Source: https://docs.applivery.com/en/device-management/apple/macos/app-management/cortex-xdr-deployment/ Description: Deploy Cortex XDR silently to macOS Devices using Applivery MDM — configure Profiles, activation Scripts, and silent install. [Cortex XDR by Palo Alto Networks](https://www.paloaltonetworks.es/cortex/cortex-xdr) is an advanced endpoint protection platform that integrates detection, prevention, and response capabilities. Installing Cortex XDR on macOS Devices via your MDM solution enables centralized deployment and ensures all endpoints are secured without requiring manual installation. ### Requirements Before deploying Cortex XDR on macOS Devices through Applivery, make sure you have the following: - **Cortex XDR client package** (`.pkg`). - **Distribution ID** and **Cloud ELB Address** (from your Cortex XDR dashboard). - **Activation Script** (for agent licensing). - **Full Disk Access policy** (via configuration profile). - **Custom Cortex XDR** `.mobileconfig` **profile**. - **1 Applivery license** for App Distribution. **Prepare Cortex XDR** To deploy Cortex XDR using Applivery, you will need to upload the compressed app package (`.zip`) to your App Distribution section and configure it with a pre-installation activation script. First, download the Cortex XDR `.pkg` installer from your **Cortex XDR Dashboard** and make sure to copy your **Distribution ID** and **Cloud ELB Address**, as you’ll need these later for the activation script. Once downloaded, compress the `.pkg` file by right-clicking on it and selecting **Compress**, which will generate a `.zip` file. Next, log in to the [**Applivery Dashboard**](https://dashboard.applivery.io) and navigate to the **App Distribution** section. From there, follow the steps outlined in our documentation: 1. [Create your first App](https://docs.applivery.com/en/app-distribution/getting-started/create-first-app/). 2. [Upload your first Build](https://docs.applivery.com/en/app-distribution/getting-started/upload-first-build/). ![app distribution](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ae4cc3a4-bfa2-4904-9b6e-d6d42544f6b1.png) **Configure your Cortex XDR Policy** Next, head to the **Device Management** section and select any of your **Policies** 1 or [create a new one](https://docs.applivery.com/en/device-management/general-settings/create-policies/). From the left-hand menu, select the **Apps** 2 section and click the **\+ Add App** 3 button. ![add app](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/574db999-782f-45a1-b794-89631e0407e9.png) In the modal view, navigate to the **Applivery** tab. Set the platform to **macOS**, choose **Your Workspace** as the App origin, and search for the **Cortex XDR** App you previously created. For the Build selection, choose **Last** to ensure the latest version is always deployed. ![cortex xdr](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ac813cb1-b3b1-4cc8-9942-50ab636d4929.png) Continue to the next step and select your preferred **install mode**—**Force Install**, **Required for setup**, or **Available**—depending on your deployment strategy. In the **Configuration** section, select **Pre-install** and paste your Activation Script, making sure to replace the placeholder values with your actual **Distribution ID** and **Cloud ELB Address**. ![cortex pre install](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/32e89e42-a7a8-45f0-8176-f81a975859fc.png) ``` #!/bin/bash ## Get current session user currentUser=$(scutil <<< "show State:/Users/ConsoleUser" | awk '/Name :/ && ! /loginwindow/ { print $3 }') #Cortex XDR Distribution ID and Cloud Address <---- MODIFY VARIABLES WITH YOURS distribution="DISTRIBUTION_ID" cloud="CLOUD_ADDRESS" # https:// format ## Path where Config.xml will be saved folderPath="/Users/$currentUser/Library/Application Support/auditApps" filePath="$folderPath/Config.xml" ## Ensure auditApps folder exists and adjust permissions sudo mkdir -p "$folderPath" sudo chown "$currentUser" "$folderPath" sudo chmod 700 "$folderPath" ## Write content to Config.xml using cat sudo cat << EOF > "$filePath" $distribution $cloud EOF ## Adjust file permissions sudo chown "$currentUser" "$filePath" sudo chmod 600 "$filePath" sudo installer -applyChoiceChangesXML "/Users/$currentUser/Library/Application Support/auditApps/Config.xml" -pkg "/Users/$currentUser/Library/Application Support/auditApps/Cortex XDR.pkg" -target / ## Verify if the file was created successfully if [[ -f "$filePath" ]]; then echo "Config.xml created at $filePath" else echo "Error creating Config.xml" exit 1 fi ``` **Custom Cortex XDR .mobileconfig** To apply the custom configuration, navigate to the desired Policy and click + Add configuration from the menu on the left-hand side. Then, select the + Import button and paste the provided .xml content into the editor: ```xml PayloadContent PayloadDisplayName Cortex XDR Privacy Preferences Policy Control PayloadIdentifier com.apple.TCC.configuration-profile-policy.7388C706-49BA-4067-BADE-8D031B084B69 PayloadType com.apple.TCC.configuration-profile-policy PayloadUUID 7388C706-49BA-4067-BADE-8D031B084B69 PayloadVersion 1 Services Accessibility Allowed CodeRequirement identifier "com.paloaltonetworks.cortex.agent" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = PXPZ95SK77 Identifier com.paloaltonetworks.cortex.agent IdentifierType bundleID StaticCode SystemPolicyAllFiles Allowed CodeRequirement identifier "com.paloaltonetworks.traps.securityextension" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = PXPZ95SK77 Identifier com.paloaltonetworks.traps.securityextension IdentifierType bundleID StaticCode Allowed CodeRequirement identifier pmd and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = PXPZ95SK77 Identifier /Library/Application Support/PaloAltoNetworks/Traps/bin/pmd IdentifierType path StaticCode AllowUserOverrides AllowedSystemExtensions PXPZ95SK77 com.paloaltonetworks.traps.securityextension com.paloaltonetworks.traps.networkextension PayloadDisplayName Cortex XDR System Extensions PayloadIdentifier com.apple.system-extension-policy.93526FBD-2421-4402-9CAF-210780E2D0FF PayloadType com.apple.system-extension-policy PayloadUUID 93526FBD-2421-4402-9CAF-210780E2D0FF PayloadVersion 1 FilterDataProviderBundleIdentifier com.paloaltonetworks.traps.networkextension FilterDataProviderDesignatedRequirement identifier "com.paloaltonetworks.traps.networkextension" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = PXPZ95SK77 FilterGrade firewall FilterPacketProviderBundleIdentifier com.paloaltonetworks.traps.networkextension FilterPacketProviderDesignatedRequirement identifier "com.paloaltonetworks.traps.networkextension" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = PXPZ95SK77 FilterPackets FilterSockets FilterType Plugin PayloadDescription Content Filter for the Cortex XDR agent network extension PayloadDisplayName Cortex XDR Network Content Filter PayloadIdentifier com.apple.webcontent-filter.CA9C208A-EC6D-4565-864D-02B30DE9D56A PayloadType com.apple.webcontent-filter PayloadUUID CA9C208A-EC6D-4565-864D-02B30DE9D56A PayloadVersion 1 PluginBundleID com.paloaltonetworks.cortex.app UserDefinedName Cortex XDR Network Filter NotificationSettings AlertType 1 BadgesEnabled BundleIdentifier com.paloaltonetworks.traps-agent CriticalAlertEnabled GroupingType 0 NotificationsEnabled PreviewType 0 ShowInCarPlay ShowInLockScreen ShowInNotificationCenter SoundsEnabled AlertType 1 BadgesEnabled BundleIdentifier com.paloaltonetworks.cortex.agent CriticalAlertEnabled GroupingType 0 NotificationsEnabled PreviewType 0 ShowInCarPlay ShowInLockScreen ShowInNotificationCenter SoundsEnabled PayloadDisplayName Cortex XDR Notifications PayloadIdentifier com.apple.notificationsettings.FE495ADF-1E68-4486-9BB6-0E75D6C3177E PayloadType com.apple.notificationsettings PayloadUUID FE495ADF-1E68-4486-9BB6-0E75D6C3177E PayloadVersion 1 PayloadDisplayName Cortex XDR Managed Login Items PayloadIdentifier com.apple.servicemanagement.1645DB60-CBC6-4AE2-A679-BC52DD4C85CE PayloadType com.apple.servicemanagement PayloadUUID 1645DB60-CBC6-4AE2-A679-BC52DD4C85CE PayloadVersion 1 Rules Comment Allows Cortex XDR launch daemons and launch agents RuleType LabelPrefix RuleValue com.paloaltonetworks.cortex TeamIdentifier PXPZ95SK77 PayloadDescription Cortex XDR Config: PPPC + SE + Content Filter + Notifications + BTM PayloadDisplayName Cortex XDR Agent Unified Config Profile v5 PayloadIdentifier com.paloaltonetworks.cortex.AA16E926-D153-4B2E-B4CC-342BB PayloadOrganization Palo Alto Networks PayloadRemovalDisallowed PayloadScope System PayloadType Configuration PayloadUUID AA16E926-D153-4B2E-B4CC-342BB PayloadVersion 1 TargetDeviceType 5 ``` Once done, make sure to **Save changes** to apply the configuration. --- ## CrowdStrike Falcon Deployment Source: https://docs.applivery.com/en/device-management/apple/macos/app-management/crowdstrike-falcon-deployment/ Description: Deploy and configure CrowdStrike Falcon sensor on macOS Devices using Applivery for enhanced endpoint protection and security management. **CrowdStrike Falcon** is a powerful, cloud-native security platform designed to deliver industry-leading antivirus and endpoint protection for macOS and Windows Devices. Leveraging cutting-edge technologies such as **artificial intelligence (AI)** and **machine learning (ML)**, Falcon proactively detects, prevents, and responds to threats before they can impact your systems. Whether you’re managing a fleet of endpoints or securing a hybrid work environment, CrowdStrike Falcon offers real-time protection, minimal system impact, and robust integration capabilities. ### Requirements To successfully deploy CrowdStrike Falcon on macOS through Applivery, make sure you have the following: - **CrowdStrike Falcon client package** (`.pkg`). - **Customer Identification (CID)** and **Grouping Tag** provided by CrowdStrike. - **Activation Script** (for agent licensing). - **Full Disk Access policy** (via configuration profile). - **Custom** `.mobileconfig` **profile**. - **Web Content Filter Configuration** to ensure full protection coverage. - **1 Applivery license** for App Distribution. **Prepare your CrowdStrike Falcon** To deploy CrowdStrike Falcon using Applivery, you will need to upload the compressed App package (`.zip`) to your App Distribution section and configure it with a post-installation activation script. First, download the CrowdStrike Falcon `.pkg` installer from your **CrowdStrike Dashboard** and make sure to copy your **CID** and **Grouping Tag**, as you’ll need these later for the activation script. Once downloaded, compress the `.pkg` file by right-clicking on it and selecting **Compress**, which will generate a `.zip` file. Next, log in to the [**Applivery Dashboard**](https://dashboard.applivery.io) and navigate to the **App Distribution** section. From there, follow the steps outlined in our documentation: 1. [Create your first App](https://docs.applivery.com/en/app-distribution/getting-started/create-first-app/). 2. [Upload your first Build](https://docs.applivery.com/en/app-distribution/getting-started/upload-first-build/). ![app distribution](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ae4cc3a4-bfa2-4904-9b6e-d6d42544f6b1.png) **Configure your CrowdStrike Falcon policy** Next, head to the **Device Management** section and select any of your **Policies** 1 or [create a new one](https://docs.applivery.com/en/device-management/general-settings/create-policies/). From the left-hand menu, select the **Apps** 2 section and click the **\+ Add App** 3 button. ![add app](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/574db999-782f-45a1-b794-89631e0407e9.png) In the modal view, navigate to the **Applivery** tab. Set the platform to **macOS**, choose **Your Workspace** as the App origin, and search for the **Falcon Sensor** App you previously created. For the Build selection, choose **Last** to ensure the latest version is always deployed. ![falcon sensor](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/d09c789d-ce9c-453f-a9de-d50effd7dbcc.png) Continue to the next step and select your preferred **install mode**—**Force Install**, **Required for setup**, or **Available**—depending on your deployment strategy. In the **Configuration** section, select **Post-install** 9 and paste your Activation Script, making sure to replace the placeholder values with your actual **CID** and **Grouping Tag**. ![falcon sensor post install](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/1e55f53d-4292-4393-aedd-01bfb445a602.png) ``` #!/bin/bash ## Configure CID and Grouping Tag <----- MODIFY WITH YOUR VARIABLES CID="CID" GROUPING_TAG="TAG" #OPTIONAL ## Apply CID license sudo /Applications/Falcon.app/Contents/Resources/falconctl license "$CID" ## Set Grouping Tag. Comment it if you will not use tags. sudo /Applications/Falcon.app/Contents/Resources/falconctl grouping-tags set "$GROUPING_TAG" ## Restart the service to apply changes sudo /Applications/Falcon.app/Contents/Resources/falconctl unload sudo /Applications/Falcon.app/Contents/Resources/falconctl load echo "Configuration successfully updated." ``` **Full Disk Access Policy** To ensure the proper functioning of the App after installation, we must grant it **Full Disk Access** permissions. Within the Policy, select **+Add Configuration** from the left-hand menu, then choose **Privacy Preferences Policy Control**. ![privacy preferences](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/3d322909-6c49-44dc-a842-e313d8c6f036.png) Next, we’ll add **two entries related to System Policy All Files**. For each element added to this configuration, set the access to **Allowed**. The first configuration should include the following params: - **Code requirement**: `identifier "com.crowdstrike.falcon.Agent" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists / and certificate leaf[field.1.2.840.113635.100.6.1.13] / exists */ and certificate leaf[subject.OU] = X9E956P446` - **Identifier**: `com.crowdstrike.falcon.Agent`. - **Identifier Type**: Bundle ID. - **Static Code**: Disabled. For the second configuration: - **Code requirement**: `identifier "com.crowdstrike.falcon.App" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists / and certificate leaf[field.1.2.840.113635.100.6.1.13] / exists */ and certificate leaf[subject.OU] = X9E956P446` - **Identifier**: `com.crowdstrike.falcon.App`. - **Identifier Type**: Bundle ID. - **Static Code**: Disabled. **Custom CrowdStrike Falcon .mobileconfig** To apply the custom configuration, navigate to the desired Policy and click **\+ Add configuration** from the menu on the left-hand side. Then, select the **\+ Import** button and paste the provided `.xml` content into the editor: ```xml PayloadDescription Network Content Filter, System Extensions, and Privacy Preferences PayloadDisplayName Crowdstrike Settings PayloadEnabled PayloadIdentifier com.applivery.crowdstrike PayloadOrganization Applivery, Inc. PayloadRemovalDisallowed PayloadScope System PayloadType Configuration PayloadUUID bbc888dc-6f2c-479d-9f3a-ce0593e6420e PayloadVersion 1 PayloadContent FilterBrowsers FilterDataProviderBundleIdentifier com.crowdstrike.falcon.Agent FilterDataProviderDesignatedRequirement identifier "com.crowdstrike.falcon.Agent" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] and certificate leaf[field.1.2.840.113635.100.6.1.13] and certificate leaf[subject.OU] = "X9E956P446" FilterGrade inspector FilterPacketProviderBundleIdentifier com.crowdstrike.falcon.Agent FilterPacketProviderDesignatedRequirement identifier "com.crowdstrike.falcon.Agent" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] and certificate leaf[field.1.2.840.113635.100.6.1.13] and certificate leaf[subject.OU] = "X9E956P446" FilterPackets FilterSockets FilterType Plugin Organization CrowdStrike Inc. PayloadDisplayName Web Content Filter PayloadIdentifier io.applivery.crowdstrike.2C5CBFD0-7CFE-41CB-95BC-A681F4D293B8 PayloadType com.apple.webcontent-filter PayloadUUID 2C5CBFD0-8CFE-41CB-95BC-A681F4D293B8 PayloadVersion 1 PluginBundleID com.crowdstrike.falcon.App UserDefinedName Falcon AllowUserOverrides AllowedSystemExtensionTypes X9E956P446 EndpointSecurityExtension NetworkExtension AllowedSystemExtensions X9E956P446 com.crowdstrike.falcon.Agent NonRemovableFromUISystemExtensions X9E956P446 com.crowdstrike.falcon.Agent PayloadDescription Configures System Extensions Policy settings PayloadDisplayName System Extensions PayloadIdentifier 20258B06-5889-4424-8893-A3AF1AFAAEDC PayloadOrganization CrowdStrike Inc. PayloadType com.apple.system-extension-policy PayloadUUID 20258B06-5889-4424-8893-A3AF1AFAAEDC PayloadVersion 1 NotificationSettings BundleIdentifier com.crowdstrike.falcon.UserAgent NotificationsEnabled PayloadDisplayName Notifications PayloadIdentifier 61090B22-3DCD-435E-ABB2-BE997B3CB78D PayloadType com.apple.notificationsettings PayloadUUID 61090B22-3DCD-435E-ABB2-BE997B3CB78D PayloadVersion 1 PayloadDescription Configures Privacy Preferences Policy Control settings PayloadDisplayName Privacy Preferences PayloadIdentifier 9A10BE5D-5E57-4C22-89C9-20597A04B616 PayloadOrganization CrowdStrike Inc. PayloadType com.apple.TCC.configuration-profile-policy PayloadUUID 9A10BE5D-5E57-4C22-89C9-20597A04B616 PayloadVersion 1 Services SystemPolicyAllFiles Allowed CodeRequirement identifier "com.crowdstrike.falcon.Agent" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = "X9E956P446" Comment Identifier com.crowdstrike.falcon.Agent IdentifierType bundleID StaticCode Allowed CodeRequirement identifier "com.crowdstrike.falcon.App" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = X9E956P446 Comment Identifier com.crowdstrike.falcon.App IdentifierType bundleID StaticCode PayloadDescription PayloadDisplayName Crowdstrike Falcon Content Filter PayloadEnabled PayloadRemovalDisallowed PayloadScope System PayloadType Configuration PayloadVersion 1 ``` Once done, make sure to **Save changes** to apply the configuration. --- ## Escrow Buddy Deployment Source: https://docs.applivery.com/en/device-management/apple/macos/app-management/escrow-buddy-deployment/ Description: Escrow FileVault recovery keys to your MDM using Escrow Buddy and Applivery — silent deployment and configuration for macOS Devices. **Escrow Buddy** is a lightweight utility designed to securely escrow FileVault Recovery Keys to your MDM. When managing macOS Devices with Applivery, using Escrow Buddy simplifies compliance with disk encryption Policies and ensures Recovery Keys are safely stored and accessible when needed. ### Requirements Before deploying Escrow Buddy on macOS Devices through Applivery, make sure you have the following: - **Escrow Buddy package** (`.pkg`). - **Post-installation script**. - **FileVault is enabled in the Device policy**. - **FileVault Recovery Key Rotation Script**. - **1 Applivery license** for App Distribution. ### Escrow Budy configuration **Prepare Escrow Buddy** To deploy Escrow Buddy using Applivery, you will need to upload the compressed App package (`.zip`) to your **App Distributio**n section and configure it with a post-installation script. First, download the Escrow Buddy `.pkg` installer from the [GitHub](https://github.com/macadmins/escrow-buddy?tab=readme-ov-file) repo. Once downloaded, compress the `.pkg` file by right-clicking on it and selecting **Compress**, which will generate a `.zip` file. Next, log in to the [**Applivery Dashboard**](https://dashboard.applivery.io) and navigate to the **App Distribution** section. From there, follow the steps outlined in our documentation: 1. [Create your first App](https://docs.applivery.com/en/app-distribution/getting-started/create-first-app/). 2. [Upload your first Build](https://docs.applivery.com/en/app-distribution/getting-started/upload-first-build/). ![](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/9d2785ae-7ef4-44f7-aa46-3d0a6a49a09a.png) :::tip To ensure that the FileVault Recovery Key is properly escrowed and remains valid over time, we recommend using a monitoring script that runs regularly, such as once every 7 days. This script, when applied to the Policy and scheduled accordingly, will help detect any issues with the current FileVault Key. If a problem is identified, the script will automatically remove the invalid key, generate a new one, and escrow it securely into the Device inventory within Applivery. ::: **Upload the FileVault Recovery Key Rotation Script** Next, head to the **Device Management** section and select **Resources** 1. Select the **Scripts** 2 section from the left-hand menu and click on the **\+ Create Script** button 3. ![escrow budy script creation](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/f34c71ab-171c-4023-985e-10728ab718e2.png) Copy the provided bash script, and **Create** 4 it as **Rotation FileVault Key Script**. ``` #!/bin/bash defaults write /Library/Preferences/com.netflix.Escrow-Buddy.plist GenerateNewKey -bool true exit 0 ``` **Configure your Escrow Buddy Policy** Now, head to any of your **Policies** 1 or [create a new one](https://docs.applivery.com/en/device-management/general-settings/create-policies/). From the left-hand menu, select the **Apps** 2 section and click the + Add App 3 button. ![add app](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/8c66994f-4986-499c-8b3e-95e410066115.png) In the modal view, navigate to the **Applivery** tab. Set the platform to **macOS**, choose **Your Workspace** as the App origin, and search for the **Escrow Buddy** App you previously created. For the Build selection, choose **Last** to ensure the latest version is always deployed. ![add app form](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/039eeedd-3507-4463-ad1b-8667a0dd7dd9.png) Continue to the next step and select **Force Install** as the **install mode**. In the **Configuration** section, select **Post-install** and paste your script. ![escrow buddy post install](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/c083dfab-a672-45ff-8ea5-3c1a38bf589b.png) ``` #!/bin/bash APP_NAME="Escrow Buddy.app" APP_BUNDLE_ID="com.netflix.Escrow-Buddy" APP_PATH="/Applications/${APP_NAME}" ## Create the app structure with appropriate permissions sudo mkdir -p "${APP_PATH}/Contents/MacOS" sudo mkdir -p "${APP_PATH}/Contents/Resources" ## Verify if the structure was created successfully if [[ ! -d "${APP_PATH}/Contents/MacOS" ]]; then echo "Error: Could not create the application structure" exit 1 fi ## Create Info.plist file sudo tee "${APP_PATH}/Contents/Info.plist" > /dev/null < CFBundleIdentifier ${APP_BUNDLE_ID} CFBundleName Escrow Buddy CFBundleVersion 1.0.0 CFBundleShortVersionString 1.0.0 CFBundleExecutable EscrowSecurityAlert EOF ## Create an empty executable with appropriate permissions sudo touch "${APP_PATH}/Contents/MacOS/${APP_NAME}" sudo chmod +x "${APP_PATH}/Contents/MacOS/${APP_NAME}" ## Verify that the app exists ls -ld "${APP_PATH}" ``` **Configure FileVault** Next, we need to configure the Policy to enable FileVault on the Devices. To do this, follow the steps outlined in our [documentation](https://docs.applivery.com/en/device-management/apple/macos/policies/filevault/) under the **Recovery Key Management – Auto** section. **Add script to the Policy** Once FileVault is properly enabled, it’s important to add the **Rotation FileVault Key Script** to ensure that any invalid or missing FileVault recovery keys are automatically detected and remediated. This guarantees that Applivery always retains a valid, escrowed key for each Device. To add the script, navigate to **Scripts** from the left-hand menu and click on the + Add Script button. Then search for and select the **Rotation FileVault Key Script** that was previously uploaded to the **Resources** section. For the Execution method, we recommend choosing **Loop** and setting the repetition interval according to your organizational needs (e.g., every 7 days). ![](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/b98076d2-9821-4605-b473-2b86dab4d054.png) Finally, click **Add** to include the script in the Policy and **Save changes** to deploy it.. --- ## PKG Deployment Source: https://docs.applivery.com/en/device-management/apple/macos/app-management/pkg-deployment/ Description: Deploy PKG files to macOS Devices using Applivery MDM for streamlined App installation and App Management. Packages are like neatly wrapped parcels for your software – they come with all the necessary bits and bobs to install or update applications on your Device. These files often end in `.pkg` or `.mpkg`, contain everything needed for smooth installations, updates, and removals of your Apps. Moreover, you may find yourself needing these application packages (PKGs) to deploy Apps on Devices running macOS version 10.13.6 or above. :::info Depending on your subscription plan, you can either distribute them to individual Devices or manage deployment through Policies for a more streamlined approach. Review the available pricing options to see which features are included [here](https://www.applivery.com/device-management-pricing/). ::: Let’s now explore how to achieve this. **Deploying PKGs to individual Devices** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), locate the Device you want to install the PKG to in the **Devices** section. Navigate to the **Apps** tab and click on the **Install from file** button. This will allow you to select the PKG from your drive and **install** it on your Device. ![install form file](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/044427a1-b6e1-4133-943a-e758ed692e1e.png) **Using Policies to optimize PKGs management** Alternatively, PKGs can be managed through **Applivery** **App Distribution**. This feature enables you to deploy packages from **Applivery** at the **Policy level**, in addition to maintaining updated versions of PKGs. Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), navigate to the **App Distribution** section and follow the steps outlined in our documentation to [create your first App](https://docs.applivery.com/en/app-distribution/getting-started/create-first-app/) and [upload your first Build](https://docs.applivery.com/en/app-distribution/getting-started/upload-first-build/). ![app distribution](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/f339a905-22de-4c47-8238-98face2a90a9.png) After uploading your PKG, head to any of your **Policies** or [create a new one](https://docs.applivery.com/en/device-management/general-settings/create-policies/). Navigate to the **Apps** section from the left side menu and click the **\+ Add App** button. In the modal view, navigate to the **Applivery** tab. Set the platform to **macOS**, choose **Your Workspace** as the App origin, and search for the App you want to deploy to your Devices. For the Build selection, choose **Last** to ensure the latest version is always deployed. ![add app from app distribution](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/dd275dc6-bd0b-4762-ba0e-3da44321a83b.png) :::info You can also deploy Apps not available on the App Store to your macOS Devices using the **Applivery macOS App Catalog**. By selecting **App Catalog** as the App origin, you gain access to a repository with up-to-date applications and automated patch management for macOS. For more details, refer to our in-depth documentation here. ::: --- ## SentinelOne Deployment Source: https://docs.applivery.com/en/device-management/apple/macos/app-management/sentinelone-deployment/ Description: Secure macOS endpoints with SentinelOne! This guide details MDM deployment via Applivery, including configuration profiles and activation scripts. **SentinelOne Agent** is an advanced, AI-powered cybersecurity platform designed to provide autonomous endpoint protection across Windows, macOS, and Linux environments. Leveraging a single-agent architecture, SentinelOne unifies prevention, detection, response, and threat hunting capabilities in real time—without relying on cloud connectivity or constant human intervention. Built for modern security teams, SentinelOne offers robust protection against malware, ransomware, fileless attacks, and zero-day threats by combining behavioral AI, machine learning, and automated remediation. Its powerful EDR (Endpoint Detection and Response) functionality empowers organizations to not only detect and respond to threats rapidly, but also to gain deep visibility into the entire attack lifecycle. Whether you’re managing a remote workforce or securing enterprise infrastructure, SentinelOne provides scalable, resilient, and easy-to-manage endpoint security tailored for today’s evolving threat landscape. ### Important updates #### Changes in macOS Sequoia 15 macOS Sequoia 15 introduces a new interface that allows users to view and manage all installed system extensions, including network extensions. This update provides users with greater control over these components. ![network-extensions](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/34caf3c6-e8df-4f47-b640-ae2c6c937332.png "network-extensions | Applivery") As an administrator, you may want to prevent users from disabling certain system extensions via System Settings. To support this, macOS Sequoia 15 includes a new key `NonRemovableFromUISystemExtensions` within the `com.apple.system-extension-policy` payload. By specifying the **SentinelOne Network Monitoring extension** in this payload, users will still be able to view the extension details—but they won’t be able to modify or disable it. :::warning The `NonRemovableFromUISystemExtensions` key **is not supported in macOS Ventura 13 or macOS 14 Sonoma**. Therefore, it’s recommended to create a separate configuration profile specifically for macOS Sequoia 15 and later. This ensures that when users upgrade to Sequoia, the correct restrictions are automatically applied and enforced. ::: ### Requirements To successfully deploy SentinelOne on macOS through Applivery, make sure you have the following: - **SentinelOne Agent package** (`.pkg`). - **SentinelOne Token**. - **Activation Script** (for agent licensing). - **Full Disk Access policy** (via configuration profile). - **Custom** `.mobileconfig` **profile**. - **System Extensions**. - **1 Applivery license** for App Distribution. **Prepare SentinelOne** To deploy SentinelOne using Applivery, you will need to upload the compressed app package (`.zip`) to your App Distribution section and configure it with a post-installation activation script. First, download the SentinelOne `.pkg` installer from your **SentinelOne dashboard** and make sure to copy your **organization’s token**, as you’ll need this later for the activation script. Once downloaded, compress the `.pkg` file by right-clicking on it and selecting **Compress**, which will generate a `.zip` file. Next, log in to the [**Applivery Dashboard**](https://dashboard.applivery.io) and navigate to the **App Distribution** section. From there, follow the steps outlined in our documentation: 1. [Create your first App](https://docs.applivery.com/en/app-distribution/getting-started/create-first-app/). 2. [Upload your first Build](https://docs.applivery.com/en/app-distribution/getting-started/upload-first-build/). **Configure SentinelOne policy** Head to the **Device Management** section and go to any of your **Policies** 1 or create a new one. From the left-hand menu, select the **Apps** 2 section and click the **\+ Add App** 3 button. ![add app](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/69d0a55b-d5ad-4e1d-b3a1-236d7f5ac46d.png) In the modal view, navigate to the **Applivery tab**. Set the platform to **macOS**, choose **Your Workspace** as the App origin, and search for the SentinelOne App you previously created. For the Build selection, choose **Last** to ensure the latest version is always deployed. ![sentinel one](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/6c91c80d-3764-4a89-9827-b2128f4f74a6.png) Continue to the next step and select your preferred **install mode**—**Force Install**, **Required for setup**, or **Available**—depending on your deployment strategy. In the **Configuration** section, select **Pre-install** and paste your Activation Script, making sure to replace the placeholder values with the **organization’s token**. ![sentinel one pre install](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/e6d12abc-0691-496f-b452-69f1146c08c5.png) ``` #!/bin/bash ## Get the currently logged-in user (macOS) currentUser=$(/bin/ls -l /dev/console | /usr/bin/awk '{ print $3 }') ## Ensure we have a valid username if [ -z "$currentUser" ]; then echo "Error: Unable to determine the current user." exit 1 fi ## Define the registration token <<<<---- MODIFY BY YOUR ORGANIZATION'S TOKEN token="TOKEN" ## Define the folder and file path folderPath="/Users/$currentUser/Library/Application Support/auditApps" filePath="$folderPath/com.sentinelone.registration-token" ## Ensure the auditApps folder exists and set proper permissions if ! sudo mkdir -p "$folderPath"; then echo "Error: Failed to create directory $folderPath" exit 1 fi if ! sudo chown "$currentUser" "$folderPath"; then echo "Error: Failed to change ownership of $folderPath" exit 1 fi if ! sudo chmod 700 "$folderPath"; then echo "Error: Failed to set permissions on $folderPath" exit 1 fi ## Write the token to the file and set proper permissions if ! echo "$token" | sudo tee "$filePath" > /dev/null; then echo "Error: Failed to write the token to $filePath" exit 1 fi if ! sudo chown "$currentUser" "$filePath"; then echo "Error: Failed to change ownership of $filePath" exit 1 fi if ! sudo chmod 600 "$filePath"; then echo "Error: Failed to set permissions on $filePath" exit 1 fi ## Open the token file with nano for manual editing as the regular user if ! sudo -u "$currentUser" nano "$filePath"; then echo "Error: Failed to open $filePath in nano" exit 1 fi ## Check if sentinelctl exists before executing if ! command -v /usr/local/bin/sentinelctl &> /dev/null; then echo "Error: sentinelctl command not found." exit 1 fi ## Register the token with SentinelOne if ! sudo -u "$currentUser" /usr/local/bin/sentinelctl set registration-token -- "$token"; then echo "Error: Failed to register the token with SentinelOne." exit 1 fi ## Exit successfully echo "Registration token successfully written and applied." exit 0 ``` **Full Disk Access Policy** To ensure the proper functioning of the App after installation, we must grant it **Full Disk Access** permissions. Within the Policy, select **+Add Configuration** from the left-hand menu, then choose **Privacy Preferences Policy Control**. ![privacy preferences](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/2c1e22c7-09ff-4df0-9548-785445a57e6c.png) Next, we’ll add several entries related to **System Policy All Files**. For each element added to this configuration, set the access to **Allowed**. The first configuration should include the following params: - **Code requirement**: `anchor apple generic and identifier "com.sentinelone.sentineld" and (certificate leaf[field.1.2.840.113635.100.6.1.9] /* exists */ or certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = "4AYE5J54KN")` - **Identifier**: `com.sentinelone.sentineld`. - **Identifier Type**: Bundle ID. - **Static Code**: Disabled. For the second configuration: - **Code requirement**: `anchor apple generic and identifier "com.sentinelone.sentineld-shell" and (certificate leaf[field.1.2.840.113635.100.6.1.9] /* exists */ or certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = "4AYE5J54KN")` - **Identifier**: `com.sentinelone.sentineld-helper`. - **Identifier Type**: Bundle ID. - **Static Code**: Disabled. For the third configuration: - **Code requirement**: `anchor apple generic and identifier "com.sentinelone.sentineld-helper" and (certificate leaf[field.1.2.840.113635.100.6.1.9] /* exists / or certificate 1[field.1.2.840.113635.100.6.2.6] / exists / and certificate leaf[field.1.2.840.113635.100.6.1.13] / exists */ and certificate leaf[subject.OU] = "4AYE5J54KN")` - **Identifier**: `com.sentinelone.sentineld-shell`. - **Identifier Type**: Bundle ID. - **Static Code**: Disabled. For the last configuration: - **Code requirement**: `anchor apple generic and identifier "com.sentinelone.sentinel-shell" and (certificate leaf[field.1.2.840.113635.100.6.1.9] /* exists */ or certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = "4AYE5J54KN")` - **Identifier**: `com.sentinelone.sentinel-shell`. - **Identifier Type**: Bundle ID. - **Static Code**: Disabled. **Custom Sentinel .mobileconfig** To apply the custom configuration, navigate to the desired Policy and click **\+ Add configuration** from the menu on the left-hand side. Then, select the **\+ Import** button and paste the provided `.xml` content into the editor: ```xml PayloadContent NotificationSettings BundleIdentifier com.sentinelone.SentinelAgent CriticalAlertEnabled PayloadDescription Configures notifications settings for apps PayloadDisplayName Notifications PayloadIdentifier com.apple.notificationsettings.26E82306-CDA4-4AF0-9714-0B8363D2A26F PayloadType com.apple.notificationsettings PayloadUUID 26E82306-CDA4-4AF0-9714-0B8363D2A26F PayloadVersion 1 PayloadDescription Configures Conference Room Display mode PayloadDisplayName Conference Room Display PayloadIdentifier com.apple.conferenceroomdisplay.B64EF9CA-0B32-43F9-82D7-5ABB51D1422B PayloadType com.apple.conferenceroomdisplay PayloadUUID B64EF9CA-0B32-43F9-82D7-5ABB51D1422B PayloadVersion 1 FilterBrowsers FilterSockets FilterType Plugin Organization Applivery Inc PayloadDescription Configures content filtering settings PayloadDisplayName SentinelOne PayloadIdentifier com.apple.webcontent-filter.B456B4A3-5794-4C8E-99FA-9148C6458AEE PayloadType com.apple.webcontent-filter PayloadUUID B456B4A3-5794-4C8E-99FA-9148C6458AEE PayloadVersion 1 PluginBundleID com.sentinelone.extensions-wrapper UserDefinedName SentinelOne PayloadDisplayName SentinelOne Config PayloadIdentifier com.applivery.sentinelone PayloadOrganization Applivery PayloadRemovalDisallowed PayloadType Configuration PayloadUUID 9B3EA38F-D1C7-4045-A745-AE3AA25ACCEE PayloadVersion 1 ``` Once done, make sure to **Save changes** to apply the configuration. --- ## Commands Source: https://docs.applivery.com/en/device-management/apple/macos/commands/ Description: macOS Commands in Applivery for remote Device Management — lock, wipe, restart, and refresh Devices from a centralized Dashboard. TL;DR: Applivery's macOS commands provide administrators with the ability to remotely manage and control macOS devices in real-time. Key topics: macOS device management, Remote commands, Applivery, Device security, Centralized management, macOS macOS MDM Commands let you perform real-time remote actions on managed Mac computers — locking a Device, clearing a passcode, restarting, wiping, or refreshing the MDM configuration without physical access. Each remote command available for macOS includes its prerequisites, such as supervision status, and what happens on the Device when it's sent. --- ## Recovery Lock Source: https://docs.applivery.com/en/device-management/apple/macos/commands/recovery-lock/ Description: Remotely set, verify, and remove macOS Recovery Lock using Applivery MDM Commands for enhanced Device security. TL;DR: Remotely manage macOS Recovery Lock with Applivery for enhanced device security. Key topics: macos, security, mdm, recovery lock, Applivery, Apple, macOS Recovery **Recovery Lock** is a native macOS security feature designed to **protect access to macOS Recovery**. When enabled, it prevents unauthorized users from reinstalling macOS, erasing the disk, or modifying critical system settings outside the managed operating system. Through Applivery, IT administrators can remotely **set**, **verify**, and **remove** Recovery Lock using official Apple MDM commands, without requiring physical access to the Device or user interaction. ### What does Recovery Lock do? When Recovery Lock is enabled on a Mac, access to Recovery Mode is protected by a password. Without this password, it is not possible to reinstall macOS, erase the Device, or perform system-level recovery actions. This adds an extra layer of protection against theft, unauthorized access, or physical tampering, especially for Fully Managed corporate Devices. ### Setting a Recovery Lock Applivery allows administrators to set a custom Recovery Lock password by sending an MDM command directly to the Device. **Navigate to the target Device** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io), go to any of your **Devices** 1 and open the **Commands** 2 tab. **Set Recovery Lock** Click **\+ New command** 3 and, under the **Recovery Lock** section, choose **Set Recovery Lock** 4. ![set recovery lock](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/121ad47a-f4c3-4312-9d2f-8be01b3d92cf.png) Define the **desired password** and click **Send** to execute the command. The password is applied immediately. No action is required from the end user, and the Device will be protected the next time macOS Recovery is accessed. This approach is especially recommended for Fully Managed Macs in corporate environments. ### Verifying the Recovery Lock password Applivery also allows administrators to **verify whether a Recovery Lock password is valid**, without rebooting the Device or accessing Recovery Mode. **Navigate to Device Commands** From the Device’s **Commands** tab, click **\+ New command**. **Select Verify Recovery Lock** Select **Verify Recovery Lock**, enter the password you want to validate, and execute the command. ![verify recovery lock](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/76305dbc-1864-4c33-8c95-9cfc75cfb520.png) The system will return a clear result indicating whether the password is **correct** or **incorrect**. :::warning This verification process does not modify the current Recovery Lock state. ::: This capability helps IT teams validate passwords before performing sensitive operations, avoid unnecessary physical access to Devices, and reduce errors during support or maintenance tasks. ### Removing the Recovery Lock **Navigate to Device Commands and provide current password** From the Device’s **Commands** tab, click **\+ New command** and select **Set Recovery Lock** again. You must provide the **currently active Recovery Lock password**. If the password is correct, the lock is removed successfully. If the correct password is not provided, Recovery Lock cannot be removed via MDM. :::warning Apple does not store the Recovery Lock password, and the MDM protocol does not allow it to be retrieved once it is lost. **If the password is forgotten or unavailable, the only recovery option is to contact Apple directly**. This process requires the original proof of purchase for the Device and may result in a full device erase. ::: :::warning The use of Recovery Lock must be carefully planned, with clear internal procedures for password storage, access control, and recovery scenarios. ::: Recovery Lock is a powerful security feature for protecting corporate macOS Devices against unauthorized recovery access. With Applivery, administrators can manage Recovery Lock centrally and remotely using the Set Recovery Lock and Verify Recovery Lock commands, without end-user involvement. However, because Recovery Lock passwords cannot be recovered if lost, it is essential to apply this feature with a well-defined strategy that balances strong security with operational continuity and supportability. --- ## Unlock User Accounts Source: https://docs.applivery.com/en/device-management/apple/macos/commands/unlock-user-accounts/ Description: Remotely unlock macOS User accounts disabled due to failed login attempts using Applivery MDM Commands to restore access. TL;DR: Unlock blocked macOS user accounts remotely using Applivery to restore access and maintain security. Key topics: macOS user account lockout, Remote unlocking with Applivery, FileVault considerations, Password policy management, Troubleshooting, macOS, Applivery, FileVault, MDM Managing user access issues is an essential part of maintaining smooth operations and security across corporate macOS Devices. Occasionally, a user account may become blocked after exceeding the allowed number of failed login attempts—typically due to password Policies enforced. When this occurs, users may see the message “Your account has been disabled” after waiting and entering the correct password. :::warning Users cannot attempt to enter the password again until the lockout period has fully expired. If the next password entered is incorrect, the lockout duration will increase. **This lockout cannot be removed using any command or script due to macOS security restrictions**. However, if the lockout period ends and the next password entered is correct, the user will still receive the “Your account has been disabled” message. ::: To restore access, you can remotely unlock the affected user account directly from the Applivery Dashboard. ### How to unlock a user account **Navigate to the target Device** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io), go to any of your **Devices** 1 and open the **Commands** 2 tab. **Find the Device** Click **\+ New command** 3 and select **Unlock User Account** 4 ![unlock user account](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/7ebcc2c9-ecf8-4daf-905d-4dab286e35d4.png) The command status should change to **Done** within a few minutes, after which you can notify the user so they can attempt to log in again. :::info If the command remains **Pending** or does not change, check the following: - The Mac is connected to a valid, managed Wi-Fi network. - The MDM profile is correctly installed and has the required permissions for user management. ::: ### Special cases: Devices with FileVault enabled If FileVault is active: - The unlock command will not work until the disk is unlocked at login using the user password or the FileVault recovery key. - If the user cannot unlock the disk, the only solution is to reset the password through [Recovery Mode using the FileVault Recovery Key](https://docs.applivery.com/en/device-management/apple/macos/policies/reset-password/#reset-mac-password-with-filevault-recovery-key). ### Recommendations To maintain efficient and secure account management: - Periodically review password Policies and lockout thresholds applied via Applivery. - Communicate expected wait times and unlock procedures to users to reduce confusion. - Document each unlock request or support action for proper traceability. By keeping these practices in place and maintaining clear communication with users, you can quickly and proactively resolve account lockouts, reinforcing security and improving the user experience across your macOS fleet. --- ## Policies Source: https://docs.applivery.com/en/device-management/apple/macos/policies/ Description: macOS Policies in Applivery — centralized management, security, and compliance for your organization's macOS Devices. TL;DR: Applivery's macOS Policies offer a centralized dashboard to manage system settings, security, and compliance for macOS devices at scale. Key topics: macOS device management, Applivery policies, Security configuration, Compliance enforcement, Centralized management, Applivery, macOS macOS Policies in Applivery let you define and enforce configurations across your managed Mac computers. From system preferences and security rules to FileVault, firewall, scripts, certificates, and custom PPPC profiles — Policies give you deep control over every enrolled Mac. Policy settings for macOS are organized by category, with step-by-step guidance for the most common configurations. --- ## Automate Admin Account Source: https://docs.applivery.com/en/device-management/apple/macos/policies/automate-admin-account/ Description: Automate the creation and management of local administrator accounts on macOS Devices using Applivery Scripts and Policies. TL;DR: Automate macOS admin account creation and management using Applivery scripts for streamlined device provisioning and improved security. Key topics: macOS Management, Mobile Device Management, Scripting, Applivery, macOS Managing user accounts on macOS Devices is an essential part of enterprise Device administration. With Applivery, IT teams can automate the creation of local administrator accounts, update credentials, and optionally hide user profiles—ensuring consistent configuration, improved security, and reduced manual effort across the entire macOS fleet. :::info The **Applivery Agent App for macOS** must be enabled on the Device. You can learn more about it [here](https://docs.applivery.com/en/device-management/apple/apple-policies/agent/). ::: **Create your script** To begin, learn how to create scripts by following [this link](https://docs.applivery.com/en/device-management/apple/macos/scripts/). Assign a descriptive name to the script and copy and paste the following script into the editor, then adjust the necessary parameters: - **USERNAME** (`username`): The short name of the account to be created. - **FULLNAME** (`Full Name`): The full display name of the user. - **PASSWORD** (`password`): The password that will be assigned to the user. - **HIDDEN** (`no`): Change to `yes` if you want the user account to be hidden from the login window. ```typescript title="example.ts" #!/bin/sh export PATH=/usr/bin:/bin:/usr/sbin:/sbin ## User details USERNAME="username" FULLNAME="Full Name" PASSWORD="password" HIDDEN="no" # Change to "yes" if you want the user to be hidden ## Function to check if user exists check_user_exists() { dscl . -list /Users | grep -q "^$USERNAME$" return $? } ## Function to check if user is hidden is_user_hidden() { dscl . -read /Users/$USERNAME IsHidden 2>/dev/null | grep -q "1" return $? } ## Function to hide user hide_user() { sudo defaults write /Library/Preferences/com.apple.loginwindow HiddenUsersList -array-add $USERNAME sudo chown root:wheel /Library/Preferences/com.apple.loginwindow.plist } ## Function to unhide user unhide_user() { sudo defaults delete /Library/Preferences/com.apple.loginwindow HiddenUsersList } ## Function to update password update_password() { sudo dscl . -passwd /Users/$USERNAME "$PASSWORD" } ## Check if user exists if check_user_exists; then echo "Usuario $USERNAME ya existe." ## Update password automatically update_password echo "Contraseña actualizada para $USERNAME" ## Check and update hidden status if needed current_hidden=$(is_user_hidden && echo "yes" || echo "no") if [ "$current_hidden" != "$HIDDEN" ]; then if [ "$HIDDEN" = "yes" ]; then hide_user echo "Usuario $USERNAME ha sido ocultado" else unhide_user echo "Usuario $USERNAME ha sido des-ocultado" fi fi else ## Create new user if [ "$HIDDEN" = "yes" ]; then HIDDEN_FLAG="-hidden" else HIDDEN_FLAG="" fi ## Create the user with or without the hidden option sysadminctl -addUser "$USERNAME" -fullName "$FULLNAME" -password "$PASSWORD" -admin $HIDDEN_FLAG echo "Usuario $USERNAME creado exitosamente" fi ``` **Assign Script to Policy** Next, go to any of your **Policies** 1 and select the **Scripts** 2 section from the left-hand menu. Click the **\+ Add Script** 3 button. ![add script to policy](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/e3750ae5-46fc-4673-87bf-47fe706a6c25.png) Next, select the script by typing its name, choose the execution method, and add any required arguments. Depending on the selected execution method, the script will run automatically in **Loop,** or **Once** mode, or it can be **manually triggered** from the **Actions** section within the Applivery Agent when configured as **On-demand**. ![actions self service](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/be26aa8c-99bd-4cfd-ae23-97c97e636757.png) This automated method for creating administrator users on macOS helps standardize device provisioning and ensures a unified security posture across the organization. The script intelligently handles both the creation of new accounts and the updating of existing ones, making it a flexible and powerful tool for multiple deployment scenarios. By leveraging Applivery and scripted automation, IT teams can manage admin accounts efficiently at scale, reduce repetitive workload, and maintain consistent configuration across all managed macOS Devices. Whether rolling out new hardware or updating current deployments, this workflow provides a reliable, secure, and repeatable way to provision administrator users in macOS environments. --- ## Automate Standard User Account Source: https://docs.applivery.com/en/device-management/apple/macos/policies/automate-standard-user-account/ Description: Automate the creation of standard (non-administrator) User accounts on macOS Devices using Applivery Scripts and Policies. TL;DR: Automate macOS standard user account creation with Applivery scripts for enhanced security and efficiency. Key topics: macos, mdm, user account management, scripting, automation, Applivery, IT administrators Managing user accounts with the appropriate privilege levels is essential for maintaining both security and operational efficiency in corporate environments. Standard (non-administrator) users help reduce security risks by preventing unauthorized system-level changes, while still allowing employees to perform everyday tasks without restrictions. Through Applivery, IT teams can automate the creation of these standard accounts across all managed macOS Devices, ensuring consistency, reducing manual work, and enforcing a strong least-privilege security model. :::info The **Applivery Agent App for macOS** must be enabled on the Device. You can learn more about it [here](https://docs.applivery.com/en/device-management/apple/apple-policies/agent/). ::: **Create your script** To begin, learn how to create scripts by following this link Assign a descriptive name to the script and copy and paste the following script into the editor, then adjust the necessary parameters: - **USERNAME** (`username`): The short name of the account to be created. - **FULLNAME** (`Full Name`): The full display name of the user. - **PASSWORD** (`password`): The password that will be assigned to the user. ``` #!/bin/sh export PATH=/usr/bin:/bin:/usr/sbin:/sbin #User details USERNAME="User" FULLNAME="Full Name" PASSWORD="Password" ## Create the user with the specified username, full name and password sysadminctl -addUser "$USERNAME" -fullName "$FULLNAME" -password "$PASSWORD" ``` **Assign script to Policy** Next, go to any of your **Policies** 1 and select the **Scripts** 2 section from the left-hand menu. Click the **\+ Add Script** 3 button. ![add script to policy](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/91d154f5-98af-4536-bc1e-be612c2faad5.png) Next, select the script by typing its name, choose the execution method, and add any required arguments. Depending on the selected execution method, the script will run automatically in **Loop,** or **Once** mode, or it can be manually triggered from the **Actions** section within the Applivery Agent when configured as **On-demand**. ![actions agent](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/366dd41e-14ee-4560-87af-35cbf23fb91d.png) Creating standard users with limited privileges is a recommended security practice that helps safeguard macOS Devices against unintended modifications or unauthorized access. Automating this process through Applivery ensures consistent configuration across the entire Device fleet, supports compliance with internal Policies, and minimizes operational overhead. By leveraging Applivery’s scripting capabilities, IT teams can efficiently deploy standard user accounts at scale, maintain system integrity, and streamline the onboarding and management of macOS Devices. This approach offers a simple, reliable, and repeatable method to enforce least-privilege access across your organization. --- ## Block or Allow URLs in Chrome and Safari Source: https://docs.applivery.com/en/device-management/apple/macos/policies/block-allow-urls-chrome-safari/ Description: Control which websites your users can reach on macOS. Safari and Chrome use different payloads, and this guide covers how to deploy both from Applivery. TL;DR: Block websites on Macs with two separate payloads: URLBlocklist for Chrome and the Parental Controls content filter for Safari. No supervision needed, and the user must restart the browser afterwards. Key topics: Chrome URL policies on macOS, Safari content filtering, Custom configuration import, Browser versus native app access, Applivery, Apple, Google Chrome, Safari, macOS On macOS, Safari and Chrome don't share a management mechanism. Each is controlled by a different payload inside the configuration profile, so restricting web access means configuring both — there's no single setting that covers the two. ### Before you start - The Mac is enrolled in Applivery through Apple MDM, Automated Device Enrollment, or manual enrollment. **Neither payload requires supervision.** - Both payloads can be imported as a custom configuration: go to **Policies**, select your macOS Policy, then **\+ Add configuration → + Import**, and either paste the XML or upload it with **Load XML**. - For Safari, there's a better route — Applivery exposes the payload as a native configuration under **\+ Add configuration → Parental Controls: Content Filter**. - You can combine both payloads in the same `.mobileconfig` under one `PayloadContent`, or import them as independent configurations in the same Policy. :::warning **The user has to restart the browser.** Until the browser is relaunched, it keeps running with the configuration it read at startup, so the restriction looks like it didn't apply. This is the first thing to check before troubleshooting anything else. ::: ### Google Chrome Chrome on macOS is managed through managed preferences injected into the `com.google.Chrome` domain, using its native `URLBlocklist` and `URLAllowlist` policies. Go to **Policies** 1, select your macOS Policy, then **\+ Add configuration → + Import** 2, and paste or upload the XML. ![import](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/9c208869-9433-463e-8af8-7f14b056b603.png) #### Blocking specific domains ```xml PayloadContent PayloadType com.google.Chrome PayloadUUID 7D9A8B87-7A4F-4B9E-9C75-111111111111 PayloadDisplayName Google Chrome - URL Blocklist PayloadIdentifier com.google.Chrome.7D9A8B87-7A4F-4B9E-9C75-111111111111 PayloadVersion 1 URLBlocklist website1.com website2.com PayloadDisplayName Chrome URL Policy macOS PayloadIdentifier com.applivery.profile.f537cccc-6b42-4a4d-a432-9ef86ae7366a PayloadType Configuration PayloadUUID 8c99db2f-eb79-4b1a-9099-827422b47588 PayloadVersion 1 ``` #### Allowing only a list of sites Block every host with a single asterisk, then list the exceptions: ```xml URLBlocklist * URLAllowlist mail.google.com applivery.com ``` #### Filter format Entries follow the pattern `[scheme://][.]host[:port][/path][@query]`.

Entry

What it matches

website1.com

The domain and all its subdomains. You don't need a separate *.website1.com entry.

.www.example.com

Only that exact host. Other subdomains stay reachable.

*

All hosts. It's a special value on its own, not a wildcard you can put inside a hostname.

Two limits worth knowing: - **The asterisk isn't a general wildcard.** `*.website1.com` doesn't work as a way to cover subdomains — a bare `website1.com` already does that. It isn't accepted at the end of a path either, so `https://example.com/*` is not a valid entry. - **You can list up to 1,000 entries.** :::info **When the two lists collide, the most specific filter wins.** Chrome selects the filters with the longest matching host, then the longest matching path, then the longest set of query tokens. If a block and an allow filter are equally specific, **the allow filter takes precedence**. ::: #### Checking it applied On the Mac, open `chrome://policy` and confirm that `URLBlocklist` or `URLAllowlist` appear with **Source: Platform** and the value you expect. If they're not there, the profile hasn't landed; if they're there but browsing still works, the browser hasn't been restarted. Once it's working, visiting a listed site shows Chrome's blocked-page message. ### Safari Safari on macOS **doesn't** use the `WebContentFilter` payload from iOS and iPadOS — that one is supervised-only and iOS-specific. On macOS, the equivalent is the Parental Controls payload, `com.apple.familycontrols.contentfilter`. You can import it as custom XML, but the native form is the better route. Both are covered below. #### Using the native form Applivery exposes this payload as a native configuration, with the fields translated and validated in the Dashboard. **Open your macOS Policy** Go to **Policies** 3, and select the macOS Policy you want to modify. **Add the configuration** From the left side menu, click **\+ Add configuration**, search for **parent**, select **Parental Controls: Content Filter** 4, and click **\+ Add**. ![parental control](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/934a5330-e5ae-40d5-b409-43c82303bcf0.png) :::warning **Use the fields marked as deprecated.** The form recommends the newer _Denylist_ and _Allowlist_ fields, and at the time of writing **you should ignore that recommendation**: the new keys don't block reliably on macOS, and the deprecated ones do. Use **Filter Blacklist** and **Filter Whitelist**. Apple deprecated them in macOS 15.2, but they keep working — including on macOS 26 Tahoe. ::: ##### The master switches **Restrict Web** must be **ON** for any filtering to happen at all. With it off, nothing else in the configuration has any effect. The same applies to **Use Content Filter**, which turns on Apple's automatic content filtering. ##### Two modes, mutually exclusive The form follows the same logic as the payload: only one mode applies at a time. **Selective blocking** — block specific sites, everything else stays reachable: - **Filter Blacklist**: the sites to block, one per entry with **\+ Add element**. - **Filter Whitelist**: exceptions within that blocking. Useful mainly when **Use Content Filter** is on, and the automatic adult-content filter is catching a site it shouldn't. - **Whitelist Enabled** must stay **OFF**. Turning it on switches you to the other mode and the blacklist stops applying. **Allow only listed sites** — block everything except a list: - **Whitelist Enabled**: ON. - **Site Whitelist**: the only field that has any effect in this mode, and required once Whitelist Enabled is on. - **Filter Blacklist** is ignored while this mode is active. You don't need to empty it.

Goal

Restrict Web

Whitelist Enabled

Field to fill

Block specific sites, allow the rest

ON

OFF

Filter Blacklist

Allow only certain sites, block the rest

ON

ON

Site Whitelist

#### Using custom XML If you'd rather import the payload directly, this blocks specific sites: ```xml PayloadContent PayloadType com.apple.familycontrols.contentfilter PayloadUUID A2B3C4D5-6E7F-4A1B-9C2D-222222222222 PayloadDisplayName Safari - Content Filter PayloadIdentifier com.applivery.safari.A2B3C4D5-6E7F-4A1B-9C2D-222222222222 PayloadVersion 1 restrictWeb useContentFilter filterBlacklist https://www.website1.com https://www.website2.com https://website3.com PayloadDisplayName Safari URL Policy macOS PayloadIdentifier com.applivery.profile.b6d1e2f3-4a5b-4c6d-8e9f-0a1b2c3d4e5f PayloadType Configuration PayloadUUID b6d1e2f3-4a5b-4c6d-8e9f-0a1b2c3d4e5f PayloadVersion 1 ``` And this allows only the listed sites: ```xml restrictWeb whitelistEnabled siteWhitelist https://mail.google.com https://applivery.com ``` :::info `whitelistEnabled` and `useContentFilter` are mutually exclusive. Use one or the other, never both in the same payload. ::: #### URL format in Safari - **URLs must start with** `http://` **or** `https://`**.** If a site answers on both, add an entry for each. - **Matching is by string root.** Blocking `https://www.website1.com` also blocks `www.website1.com/example` and any path underneath it — but it does **not** automatically cover other subdomains such as `example.website1.com`. Add those as separate entries if you need them. - **Redirects aren't followed.** If a blocked or allowed URL redirects elsewhere, the destination has to be on the list too. - **The filter also disables clearing Safari history and browsing data, and turns off private browsing.** ### Blocking the website isn't blocking the tool Blocking a domain in Chrome or Safari only stops access **through the browser**. Plenty of tools ship a **native desktop app** that talks to its servers directly, never touching a browser, and is therefore untouched by `URLBlocklist` or `filterBlacklist`. If the goal is to stop people using a service rather than just visiting its website, pair this configuration with app control — see [Block & Allow Apps](https://docs.applivery.com/en/device-management/apple/app-management/block-allow-apps/). ### Payload summary

Browser

PayloadType

Blocking keys

Allowing keys

Supervision

Google Chrome

com.google.Chrome

URLBlocklist

URLAllowlist

Not required

Safari

com.apple.familycontrols.contentfilter

filterBlacklist

filterWhitelist / siteWhitelist

Not required

:::info Apple introduced renamed keys in **macOS 15.2** — `filterDenyList`, `filterAllowList`, `siteAllowList` and `allowListEnabled` — and deprecated the originals at the same time. The table above deliberately uses the deprecated names, because those are the ones that currently block reliably. ::: ### Before you roll it out Deploy to one Mac first and confirm two things: that the policy arrived, using `chrome://policy` for Chrome, and that the browser has been restarted. Most reports of "the block isn't working" come down to one of those two, not to the payload itself. --- ## Block USB & External Drives Source: https://docs.applivery.com/en/device-management/apple/macos/policies/block-usb-external-drives/ Description: Block USB drives and external storage Devices on macOS using Applivery MDM Profiles to prevent data leakage and enhance security. TL;DR: Block USB drives and external storage on macOS using MDM configuration profiles to enhance data security and prevent unauthorized data transfer. Key topics: macOS media control, MDM configuration profiles, USB drive blocking, Data loss prevention, Applivery, macOS, USB drives, SystemUIServer, mobileconfig In corporate environments, the use of external storage Devices such as USB drives, external hard disks, CDs, or DVDs represents a significant risk to information security and regulatory compliance. macOS provides native mechanisms to restrict these Devices through configuration profiles, allowing organizations to enforce strict media control Policies without installing additional agents or relying on monitoring scripts. This approach is based on a `.mobileconfig` configuration profile that applies restrictions to macOS system behavior—specifically through the **SystemUIServer** component—controlling how the operating system reacts when external storage media is connected. When applied, the profile can detect the insertion of external media, prevent it from being mounted, automatically eject it, and display a system notification informing the user that the Device is blocked. Other peripherals, such as keyboards, mice, or charging cables, are not affected, as long as they are not recognized by macOS as storage Devices. ### Blocked media types Using this configuration, macOS can restrict multiple types of removable storage, including external USB hard drives, USB flash drives, CDs and DVDs, optical media, and other mass storage Devices recognized by the system. When one of these Devices is connected, macOS automatically ejects it and prevents it from being mounted, making it inaccessible to the user. ### Configuration Once in the [**Applivery Dashboard**](https://dashboard.applivery.io), head to any of your **Policies** or [create a new one](https://docs.applivery.com/en/device-management/general-settings/create-policies/). From the left-hand menu, navigate to the **\+ Add configuration** option and then choose **Media Management: Allowed Media**. ![media management allowed media](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/913878c7-e1a2-451a-a712-8e187f47546b.png) This payload is structured into three distinct sections, each applied at a different stage of the Device lifecycle and serving a specific security purpose. #### Logout eject: Device control at user logout This section **defines which storage Devices are automatically ejected when a user logs out** of macOS. It does not block Device usage during an active session but ensures that no external storage remains mounted once the user session ends. This is particularly useful on shared Devices, preventing external drives from being accessed by subsequent users and reinforcing security without impacting day-to-day workflows. For example, external hard drives can be configured to be automatically ejected upon logout. #### Mount controls: control of Device mounting This is the most critical section of the payload, as it **determines whether a storage Device can be mounted at all when it is connected**. macOS evaluates these rules immediately upon Device insertion. Administrators can completely block access, allow read-only access, or permit full usage depending on the organization’s requirements. Mount controls are commonly used to block USB drives to prevent data exfiltration, allow optical media in read-only mode, or strictly control non-corporate storage Devices. If a Device type is blocked here, it cannot be used under any circumstances, regardless of any other configuration sections. #### Unmount controls: manual Device ejection control This section governs **whether a user is allowed to manually eject a Device that is already mounted**. It does not affect the initial connection or mounting of the Device. Typical use cases include preventing accidental disconnection of critical network drives or protecting specific corporate environments where manual ejection could cause operational issues. #### Functional summary | Section | Applied when | Main function | | --- | --- | --- | | Logout eject | User logout | Automatic device ejection | | Mount controls | Device connection | Allow or block mounting | | Unmount controls | Manual ejection | Allow or block device unmounting | ### Available actions Within the logout eject, mount controls, and unmount controls sections, administrators can define how macOS reacts to each media type: - The **Authenticate** action allows Device usage only after the user successfully authenticates with their macOS credentials. This option is suitable when access should be restricted to authorized users without fully blocking the Device. - The **Read-only** action permits access to files while preventing any data from being written to the Device. Users can view and copy files from the Device to the Mac, but cannot modify files or copy corporate data to external storage, making this option ideal for preventing data leakage. - The **Deny** action fully blocks the Device, preventing it from being mounted or accessed in any way. In this case, the Device may briefly appear and then disappear, or not appear at all. If a media type is set to Deny in mount controls, no other configuration will override this behavior. - The **Eject** action allows normal usage during the active session but automatically ejects the Device when the configured event occurs, such as user logout. This option is commonly used on shared Macs to ensure external Devices are not left mounted. | Action | Access allowed | Write allowed | Auth required | Typical use | | --- | --- | --- | --- | --- | | Authenticate | ✅ | ✅ | ✅ | User-based control | | Read-only | ✅ | ❌ | ❌ | Prevent data exfiltration | | Deny | ❌ | ❌ | ❌ | Total blocking | | Eject | ✅ (temporary) | ✅ | ❌ | Cleanup at logout | ### General recommendation In most Applivery-managed corporate environments, media control Policies typically rely on **mount controls** as the primary enforcement mechanism, complemented by **logout eject** as an additional safeguard. **Unmount controls** are usually reserved for very specific scenarios. Combining these sections appropriately allows organizations to implement strong security controls without unnecessarily impacting user productivity. ### Restriction removal behavior If the configuration profile is removed from the Device, **a system restart is required** for all restrictions to be fully lifted. Until the restart occurs, macOS may continue enforcing the media block. This behavior is inherent to the operating system and should be considered during troubleshooting or Policy changes. :::tip Remember to restart the macOS device after removing the configuration profile to fully lift the restrictions. ::: By distributing configuration profiles through Applivery, organizations can natively and effectively block external storage Devices on macOS in a centralized, scalable, and non-intrusive manner. This approach improves data security, integrates seamlessly with macOS, and provides IT teams with precise control over removable media usage while maintaining a balanced user experience. --- ## Deploy Check Point Source: https://docs.applivery.com/en/device-management/apple/macos/policies/deploy-checkpoint/ Description: Automate the installation and configuration of Check Point Endpoint Security on macOS Devices using an Applivery Script. TL;DR: Automate Check Point Endpoint Security installation on macOS using a script for faster, more reliable, and consistent deployment. Key topics: Endpoint Security, macOS Automation, Scripting, Check Point Endpoint Security, macOS Deploying security software across a fleet of macOS Devices can be time-consuming and error-prone when done manually. To address this, we’ve created a script that automates the installation and initial configuration of the **Check Point Endpoint Security** client for macOS. This approach ensures a faster, more reliable rollout while maintaining consistency in how each Device is configured. By embedding essential settings—such as server addresses, certificates, and policy configurations—the script enables each Mac to securely connect to your Check Point management infrastructure immediately after installation. ### Purpose This script is designed to streamline the deployment of the **Check Point Endpoint Security** client across macOS Devices by automating both installation and initial configuration. It aims to: - **Automate deployment**: Eliminate manual steps by automating the distribution and installation of the security client on multiple Macs, reducing the likelihood of user error and saving valuable IT resources. - **Enable pre-configuration**: Embed all necessary configuration data—including certificates, server addresses, and Policy settings—so that the client is immediately ready to connect to your Check Point management infrastructure after installation. - **Ensure consistency**: Guarantee that every endpoint receives the same configuration and security Policies, enhancing uniformity and compliance across the organization. ### General workflow The script follows a structured workflow to ensure reliable and consistent deployment: **Preparation** Key system utilities such as `base64`, `curl`, and `unzip` are defined and validated at the beginning of the script to ensure compatibility and avoid execution errors. **Embedding configuration data** The script contains a large block of configuration information encoded in Base64 format, typically exported from the Check Point Management Portal. This block includes required elements like certificates, server URLs, and Policy settings. **Decoding and applying configuration** The Base64-encoded configuration is decoded and saved to a temporary or predefined location where the Check Point client expects to find its configuration files. **Installer download** Using `curl` or a similar utility, the script retrieves the Check Point Endpoint Security installer—usually packaged as a ZIP file—from a trusted internal or external repository. **Installation process** The downloaded installer is extracted, and the installation is executed using macOS-native tools, such as the `installer` command line or by launching the included `.app`. Administrative privileges may be required. **Cleanup and post-install validation** After installation, the script removes any temporary files and optionally performs a validation step, such as checking for the presence of the installed application or verifying its operational status. ``` #!/bin/sh -x set -e BASE64=/usr/bin/base64 UNZIP=/usr/bin/unzip CURL=/usr/bin/curl INSTALLER=/usr/sbin/installer ECHO=/bin/echo RM=/bin/rm PKGUTIL=/usr/sbin/pkgutil CONFIG_DAT_B64=PERBX0NPTkZJRz48QUxMT1dfTk9OX1RSVVNURURfQ0E+MTwvQUxMT1dfTk9OX1RSVVNURURfQ0E+PEFMTE9XX0lOVkFMSURfQ0VSVF9EQVRFPjE8L0FMTE9XX0lOVkFMSURfQ0VSVF9EQVRFPjxBTExPV19JTlZBTElEX1NJVEVfTkFNRT4xPC9BTExPV19JTlZBTElEX1NJVEVfTkFNRT48Q0hFQ0tfRk9SX1JFVk9DQVRJT04+MDwvQ0hFQ0tfRk9SX1JFVk9DQVRJT04+PFZEU19MT0NBVElPTj48L1ZEU19MT0NBVElPTj48SEVBREVSPlgtQ1BFUFA6dllvaWdkR0Zubm9RYzc8L0hFQURFUj48VkVSSUZfS0VZPk1JR0pBb0dCQUkxdU9RQml6NzRsdVYzV1BpZERCZStKSW5QQzRmUm8vUHkvNTNLRGtZNlJaQnhRdG5xZmkydFZFS29kQmhGK0dsa0lTM09Oc2R3eC9ZN05GdDhrSk9OZXdlN3hsZktVc2xrL0ViZGVTSERSQzNKMCs1VDZaVUszSXViU0JRYnEzeWExRUI3SmpFU3hITDF0RXIxR3FjaUZ3RnFZN0IvdmV2Q3VneE9OZzdDTEFnTUJBQUU9PC9WRVJJRl9LRVk+PExPQ1BPTEw+NjA8L0xPQ1BPTEw+PENBX0NFUlQ+LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUUwRENDQTdpZ0F3SUJBZ0lCQnpBTkJna3Foa2lHOXcwQkFRc0ZBRENCZ3pFTE1Ba0dBMVVFQmhNQ1ZWTXgKRURBT0JnTlZCQWdUQjBGeWFYcHZibUV4RXpBUkJnTlZCQWNUQ2xOamIzUjBjMlJoYkdVeEdqQVlCZ05WQkFvVApFVWR2UkdGa1pIa3VZMjl0TENCSmJtTXVNVEV3THdZRFZRUURFeWhIYnlCRVlXUmtlU0JTYjI5MElFTmxjblJwClptbGpZWFJsSUVGMWRHaHZjbWwwZVNBdElFY3lNQjRYRFRFeE1EVXdNekEzTURBd01Gb1hEVE14TURVd016QTMKTURBd01Gb3dnYlF4Q3pBSkJnTlZCQVlUQWxWVE1SQXdEZ1lEVlFRSUV3ZEJjbWw2YjI1aE1STXdFUVlEVlFRSApFd3BUWTI5MGRITmtZV3hsTVJvd0dBWURWUVFLRXhGSGIwUmhaR1I1TG1OdmJTd2dTVzVqTGpFdE1Dc0dBMVVFCkN4TWthSFIwY0RvdkwyTmxjblJ6TG1kdlpHRmtaSGt1WTI5dEwzSmxjRzl6YVhSdmNua3ZNVE13TVFZRFZRUUQKRXlwSGJ5QkVZV1JrZVNCVFpXTjFjbVVnUTJWeWRHbG1hV05oZEdVZ1FYVjBhRzl5YVhSNUlDMGdSekl3Z2dFaQpNQTBHQ1NxR1NJYjNEUUVCQVFVQUE0SUJEd0F3Z2dFS0FvSUJBUUM1NE1zUTFLOTJ2ZFNUWXVzd1pMaUJDR3pECkJObGlGNDR2L3o1bHo0L09ZdVk4VWh6YUZrVkxWYXQ0YTJPRFlwRE9EMmxzbWNnYUZJdE16RVV6Nm9qY25xT3YKSy82QVlaMTVWOFRQTHZRL01EeGRSL3lhRnJ6RE41WkJVWTRSUzFUNEtMN1FqTDd3TURnZTg3QW0rR1pIWTIzZQpjU1pIanpoSFU5RkdIYlRqM0FEcVJheTl2SEhacW04QTI5dk5NRHA1VDE5TVIvZ2Q3MXZDeEoxZ083R3lRNUhZCnBETk82clBXSjArdEpZcWx4dlRWMEthdWRBVmtWNGkxUkZYVUxTbzZQdmk0dmVreUNnS1VaTVFXT2xEeFNxN24KZVRPdkRDQUhmK2pmQkRuQ2FRSnNZMUw2ZDhFYnlIU0h5TG1UR0ZCVU5VdHBUcnc3MDBrdUg5ekIwbEw3QWdNQgpBQUdqZ2dFYU1JSUJGakFQQmdOVkhSTUJBZjhFQlRBREFRSC9NQTRHQTFVZER3RUIvd1FFQXdJQkJqQWRCZ05WCkhRNEVGZ1FVUU1LOUo0N01OSU13b2pQWCsyeXo4TFFzZ000d0h3WURWUjBqQkJnd0ZvQVVPcHFGQnhCbktMYnYKOXIwRlFXNGd3WlRhRDk0d05BWUlLd1lCQlFVSEFRRUVLREFtTUNRR0NDc0dBUVVGQnpBQmhoaG9kSFJ3T2k4dgpiMk56Y0M1bmIyUmhaR1I1TG1OdmJTOHdOUVlEVlIwZkJDNHdMREFxb0NpZ0pvWWthSFIwY0RvdkwyTnliQzVuCmIyUmhaR1I1TG1OdmJTOW5aSEp2YjNRdFp6SXVZM0pzTUVZR0ExVWRJQVEvTUQwd093WUVWUjBnQURBek1ERUcKQ0NzR0FRVUZCd0lCRmlWb2RIUndjem92TDJObGNuUnpMbWR2WkdGa1pIa3VZMjl0TDNKbGNHOXphWFJ2Y25rdgpNQTBHQ1NxR1NJYjNEUUVCQ3dVQUE0SUJBUUFJZm15VEVNZzR1SmFwa0V2L29WOVBCTzlzUHB5SUJzbFFqNlp6CjkxY3hHNzY4NUMvYitMclRXK0MwNStaNVlnNE1vdGRxWTNNeHRmV29TS1E3Q0MyaVhaRFh0SHdsVHhGV01NUzIKUkoxN0xKM2xYdWJ2REdHcXYrUXFHKzZFbnJpRGZjRkR6a1NuRTNBTmtSLzB5Qk90ZzJEWjJIS29jeVFldGF3aQpEc29YaVdKWVJCdXJpU1VCQUEvTnhCdGkyMUcwMHc5UktwdjB2SFA4ZHM0MnBNM1oyQ3pxcnB2MUtyS1EwVTExCkdJby9pa0dRSTMxYlMvNmtBMWliUnJMRFlHQ0QrSDFRUWM3Q29aRER1KzhDTDlJVlZPNUVGZGtLcnFlS00rMngKTFhZMkp0d0U2NS8zWVI4VjNJZHY3a2FXS0syaEpuMEtDYWN1QktPTnZQaThCREFCCi0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0KLS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUVmVENDQTJXZ0F3SUJBZ0lERytjVk1BMEdDU3FHU0liM0RRRUJDd1VBTUdNeEN6QUpCZ05WQkFZVEFsVlQKTVNFd0h3WURWUVFLRXhoVWFHVWdSMjhnUkdGa1pIa2dSM0p2ZFhBc0lFbHVZeTR4TVRBdkJnTlZCQXNUS0VkdgpJRVJoWkdSNUlFTnNZWE56SURJZ1EyVnlkR2xtYVdOaGRHbHZiaUJCZFhSb2IzSnBkSGt3SGhjTk1UUXdNVEF4Ck1EY3dNREF3V2hjTk16RXdOVE13TURjd01EQXdXakNCZ3pFTE1Ba0dBMVVFQmhNQ1ZWTXhFREFPQmdOVkJBZ1QKQjBGeWFYcHZibUV4RXpBUkJnTlZCQWNUQ2xOamIzUjBjMlJoYkdVeEdqQVlCZ05WQkFvVEVVZHZSR0ZrWkhrdQpZMjl0TENCSmJtTXVNVEV3THdZRFZRUURFeWhIYnlCRVlXUmtlU0JTYjI5MElFTmxjblJwWm1sallYUmxJRUYxCmRHaHZjbWwwZVNBdElFY3lNSUlCSWpBTkJna3Foa2lHOXcwQkFRRUZBQU9DQVE4QU1JSUJDZ0tDQVFFQXYzRmkKQ1BINldUVDNHOGtZby9lQVNWanBJb01UcHNVZ1F3RTdoUEhtaFVtZkorcjJoQnRPb0xUYmNKakhNZ0d4QlQ0SApUdTcwK2s4dldUQWk1NnNaVm12aWdBZjg4eFoxZ0RsUmUrWDVOYlowVHFtTmdoUGt0aitwQTRQNm9yNktGV3AvCjNndkR0aGtVQmNycXc2Z0VsRHRHZkRJTjh3Qm1Jc2lOYVcwMmpCRVl0OU95SEdDME9Qb0NqTTdUM1VZSDNnbysKNjExOHlIejdzQ3RUcEpKaWFWRWxCV0VhUklHTUxLbERsaVBmckRxQm1nNHB4UnlwNlYwZXRwNmVNQW81enZHSQpnUHRMWGN3eTdJVmlReVUwQWxZbkFaRzBPM0FxUDI2eDZKeUlBWDJmMVBuYlUyMWduYjhzNTFpcnVGOUcvTTdFCkd3TThDZXRKTVZ4cFJyUGdSd0lEQVFBQm80SUJGekNDQVJNd0R3WURWUjBUQVFIL0JBVXdBd0VCL3pBT0JnTlYKSFE4QkFmOEVCQU1DQVFZd0hRWURWUjBPQkJZRUZEcWFoUWNRWnlpMjcvYTlCVUZ1SU1HVTJnL2VNQjhHQTFVZApJd1FZTUJhQUZOTEVzTktSMUV3UmNiTmh5ejJoL3Qyb2F0VGpNRFFHQ0NzR0FRVUZCd0VCQkNnd0pqQWtCZ2dyCkJnRUZCUWN3QVlZWWFIUjBjRG92TDI5amMzQXVaMjlrWVdSa2VTNWpiMjB2TURJR0ExVWRId1FyTUNrd0o2QWwKb0NPR0lXaDBkSEE2THk5amNtd3VaMjlrWVdSa2VTNWpiMjB2WjJSeWIyOTBMbU55YkRCR0JnTlZIU0FFUHpBOQpNRHNHQkZVZElBQXdNekF4QmdnckJnRUZCUWNDQVJZbGFIUjBjSE02THk5alpYSjBjeTVuYjJSaFpHUjVMbU52CmJTOXlaWEJ2YzJsMGIzSjVMekFOQmdrcWhraUc5dzBCQVFzRkFBT0NBUUVBV1F0VHZaS0dFYWNrZSsxYk1jOGQKSDJ4d3hiaHV2azY3OXI2WFVPRXdmN29vWEdLVXd1TitNL2Y3UW5hRjI1VWNqQ0pZZFFrTWlHVm5PUW9XQ2NXZwpPSmVreFNPVFA3UVlwZ0VHUkpIanAya250Rm9sZnpxM01zM2RoUDhxT0NrenBOMW5zb1grb1lnZ0hGQ0p5TndxCjlrSUROMHptaU4vVnJ5VHlzY1BmekxYczRKbGV0MGxVSUR5VUdBekhIRklZU2FSdDRiTllDOG5ZN05tdUhES08KS0hBTjR2Nm1GNTZFRDcxWGNMTmE2UitnaGxPNzczei9hUXZnU01PM2t3dklDbFRFckYwVVp6ZHN5cVV2TVFnMwpxbTV2akx5YjRsZGRKSUd2bDVlY2hLMXNyRGRNWnZOaGtSRWc1TDR3bjNxa0tRbXc0VFJmWkhjWVFGSGZqRENtCnJ3PT0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQotLS0tLUJFR0lOIENFUlRJRklDQVRFLS0tLS0KTUlJRUFEQ0NBdWlnQXdJQkFnSUJBREFOQmdrcWhraUc5dzBCQVFVRkFEQmpNUXN3Q1FZRFZRUUdFd0pWVXpFaApNQjhHQTFVRUNoTVlWR2hsSUVkdklFUmhaR1I1SUVkeWIzVndMQ0JKYm1NdU1URXdMd1lEVlFRTEV5aEhieUJFCllXUmtlU0JEYkdGemN5QXlJRU5sY25ScFptbGpZWFJwYjI0Z1FYVjBhRzl5YVhSNU1CNFhEVEEwTURZeU9URTMKTURZeU1Gb1hEVE0wTURZeU9URTNNRFl5TUZvd1l6RUxNQWtHQTFVRUJoTUNWVk14SVRBZkJnTlZCQW9UR0ZSbwpaU0JIYnlCRVlXUmtlU0JIY205MWNDd2dTVzVqTGpFeE1DOEdBMVVFQ3hNb1IyOGdSR0ZrWkhrZ1EyeGhjM01nCk1pQkRaWEowYVdacFkyRjBhVzl1SUVGMWRHaHZjbWwwZVRDQ0FTQXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRU4KQURDQ0FRZ0NnZ0VCQU42ZDErcFhHRW1oVyt2WFgwaUc2cjdkLytUdlp4ejBaV2l6VjNHZ1huZTc3WnRKNlhDQQpQVllZWXdodjJ2TE0wRDkvQWxRaVZCRFlzb0hVd0hVOVMzL0hkOE0rZUtzYUE3VWdheTlxSzdIRmlIN0V1eDZ3CndkaEZKMitxTjFqM2h5YlgyQzMycVJlM0gzSTJUcVlYUDJXWWt0c3FibDJpL29qZ0M5NS81WTBWNGV2TE90WGkKRXFJVExkaU9yMThTUGFBSUJRaTJYS1ZsT0FSRm1SNmpZR0IweFVHbGNtSWJZc1VmYjE4YVFyNENVV1dvcmlNWQphdng0QTZsTmY0REQrcXRhL0tGQXBNb1pGdjZ5eU85ZWN3M3VkNzJhOW5tWXZMRUhaNklWRGQyZ1dNWkVld28rCllpaGZ1a0VIVTFqUEVYNDRkTVg0LzdWcGtJK0VkT3FYRzY4Q0FRT2pnY0F3Z2Iwd0hRWURWUjBPQkJZRUZOTEUKc05LUjFFd1JjYk5oeXoyaC90Mm9hdFRqTUlHTkJnTlZIU01FZ1lVd2dZS0FGTkxFc05LUjFFd1JjYk5oeXoyaAovdDJvYXRUam9XZWtaVEJqTVFzd0NRWURWUVFHRXdKVlV6RWhNQjhHQTFVRUNoTVlWR2hsSUVkdklFUmhaR1I1CklFZHliM1Z3TENCSmJtTXVNVEV3THdZRFZRUUxFeWhIYnlCRVlXUmtlU0JEYkdGemN5QXlJRU5sY25ScFptbGoKWVhScGIyNGdRWFYwYUc5eWFYUjVnZ0VBTUF3R0ExVWRFd1FGTUFNQkFmOHdEUVlKS29aSWh2Y05BUUVGQlFBRApnZ0VCQURKTDg3TEtQcEg4RXNhaEI0eU9kNkF6QmhSY2tCNFk5d2ltUFFvWitZZUFFVzVwNUpZWE1QODBrV055Ck9PN01IQUdqSFpRb3BESDJlc1JVMS9ibE1WZ0Rvc3pPWXR1VVJYTzF2MFhKSkxYVmdnS3RJM2xwamJpMlRjN1AKVE1vekkrZ2NpS3FkaTBGdUZza2c1WW1lelR2YWNQZCttU1lnRkZRbHEyNXpoZWFiSVowS2JJSU9xUGpDRFBvUQpIbXlXNzRjTnhBOWhpNjN1Z3l1VitJNlNoSEk1NnlEcWcrMkR6WmR1Q0x6clRpYTJjeXZrMC9aTS9pWng0bUVSCmRFci9WeHFIRDNWSUxzOVJhUmVnQWhKaGxkWFJRTElRVE83RXJCQkRwcVdlQ3RXVllwb056NGlDeFRJTTVDdWYKUmVZTm55aWNzYmtxV2xldE53K3ZIWC9idlo4PQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCjwvQ0FfQ0VSVD48Q1BFUFNOZXR3b3JrIHhtbG5zPSJodHRwOi8vc2NoZW1hLmNoZWNrcG9pbnQuY29tL25ldHdvcmsvY3Blc25ldHdvcmsvdjEvIj4KICAgIDxwcm94aW1pdHlUaW1lb3V0PjEyMDwvcHJveGltaXR5VGltZW91dD4KICAgIDxvcEdyb3Vwcz4KICAgICAgICA8b3BHcm91cCBuYW1lPSJkZWZhdWx0Ij4KICAgICAgICAgICAgPG9wIHBhdGg9Ii9jcC9jb25uZWN0aW9uUG9pbnQvZmlsZXNGb3JEeW5hbWljUGFja2FnZSIgYXV0aGVudGljYXRpb25UeXBlPSJERVZJQ0UiIHByb3RvPSJIVFRQU0VTUCIgdHlwZT0iRklMRVNfRk9SX0RZTkFNSUNfUEFDS0FHRSIgcG9ydD0iNDQzIj48L29wPgogICAgICAgICAgICA8b3AgcGF0aD0iL2NwL2Nvbm5lY3Rpb25Qb2ludC9nZXRGREVDcmVkIiBhdXRoZW50aWNhdGlvblR5cGU9IkJPVEgiIHByb3RvPSJIVFRQU0VTUCIgdHlwZT0iR0VUX0ZERV9DUkVERU5USUFMUyIgcG9ydD0iNDQzIj48L29wPgogICAgICAgICAgICA8b3AgcGF0aD0iL2NwL2Nvbm5lY3Rpb25Qb2ludC9kZWNyeXB0RkRFIiBhdXRoZW50aWNhdGlvblR5cGU9Ik5PTkUiIHByb3RvPSJIVFRQUyIgdHlwZT0iREVDUllQVF9GREUiIHBvcnQ9IjQ0MyI+PC9vcD4KICAgICAgICAgICAgPG9wIHBhdGg9Ii9jcC9jb25uZWN0aW9uUG9pbnQvc2V0RkRFUmVjRmlsZSIgYXV0aGVudGljYXRpb25UeXBlPSJERVZJQ0UiIHByb3RvPSJIVFRQU0VTUCIgdHlwZT0iU0VUX0ZERV9SRUNPVkVSWV9GSUxFIiBwb3J0PSI0NDMiPjwvb3A+CiAgICAgICAgICAgIDxvcCBwYXRoPSIvY3AvZmlsZSIgYXV0aGVudGljYXRpb25UeXBlPSJOT05FIiBwcm90bz0iSFRUUFMiIHR5cGU9IlBPTElDWSIgcG9ydD0iNDQzIj48L29wPgogICAgICAgICAgICA8b3AgcGF0aD0iL2NwL2Nvbm5lY3Rpb25Qb2ludC9Ta2VsZXRvbl9wYXlsb2FkVHlwZTEiIGF1dGhlbnRpY2F0aW9uVHlwZT0iTk9ORSIgcHJvdG89IkhUVFBTRVNQIiB0eXBlPSJTS0VMRVRPTl9QQVlMT0FEMSIgcG9ydD0iNDQzIj48L29wPgogICAgICAgICAgICA8b3AgcGF0aD0iL2NwL2Nvbm5lY3Rpb25Qb2ludC90b2tlbiIgYXV0aGVudGljYXRpb25UeXBlPSJOT05FIiBwcm90bz0iSFRUUFMiIHR5cGU9IkdFVF9UT0tFTiIgcG9ydD0iNDQzIj48L29wPgogICAgICAgICAgICA8b3AgcGF0aD0iL2NwL2Nvbm5lY3Rpb25Qb2ludC9nZXRlcGxpY2Vuc2VpbmZvIiBhdXRoZW50aWNhdGlvblR5cGU9Ik5PTkUiIHByb3RvPSJIVFRQU0VTUCIgdHlwZT0iR0VUX0VQX0xJQ0VOU0VfSU5GTyIgcG9ydD0iNDQzIj48L29wPgogICAgICAgICAgICA8b3AgcGF0aD0iL2NwL2Nvbm5lY3Rpb25Qb2ludC9zZXRNRURldkluZm8iIGF1dGhlbnRpY2F0aW9uVHlwZT0iTk9ORSIgcHJvdG89IkhUVFBTRVNQIiB0eXBlPSJTRVRfTUVfREVWSUNFX0lORk8iIHBvcnQ9IjQ0MyI+PC9vcD4KICAgICAgICAgICAgPG9wIHBhdGg9Ii9jcC9jb25uZWN0aW9uUG9pbnQvc3luY3JlcSIgYXV0aGVudGljYXRpb25UeXBlPSJOT05FIiBwcm90bz0iSFRUUFNFU1AiIHR5cGU9IlNZTkNfUkVRVUVTVCIgcG9ydD0iNDQzIj48L29wPgogICAgICAgICAgICA8b3AgcGF0aD0iL2NwL2Nvbm5lY3Rpb25Qb2ludC9sb2d1cGxvYWQiIGF1dGhlbnRpY2F0aW9uVHlwZT0iTk9ORSIgcHJvdG89IkhUVFBTRVNQIiB0eXBlPSJMT0dfVVBMT0FEIiBwb3J0PSI0NDMiPjwvb3A+CiAgICAgICAgICAgIDxvcCBwYXRoPSIvY3AvY29ubmVjdGlvblBvaW50L3JlZ2VwIiBhdXRoZW50aWNhdGlvblR5cGU9IkRFVklDRSIgcHJvdG89IkhUVFBTIiB0eXBlPSJSRUdJU1RFUl9FTkRQT0lOVCIgcG9ydD0iNDQzIj48L29wPgogICAgICAgICAgICA8b3AgcGF0aD0iL2NwL2Nvbm5lY3Rpb25Qb2ludC9zZXRGREVDcmVkIiBhdXRoZW50aWNhdGlvblR5cGU9IkJPVEgiIHByb3RvPSJIVFRQU0VTUCIgdHlwZT0iU0VUX0ZERV9DUkVERU5USUFMUyIgcG9ydD0iNDQzIj48L29wPgogICAgICAgICAgICA8b3AgcGF0aD0iL2NwL2Nvbm5lY3Rpb25Qb2ludC9yZW1vdGVIZWxwRkRFIiBhdXRoZW50aWNhdGlvblR5cGU9Ik5PTkUiIHByb3RvPSJIVFRQUyIgdHlwZT0iUkVNT1RFX0hFTFBfRkRFIiBwb3J0PSI0NDMiPjwvb3A+CiAgICAgICAgICAgIDxvcCBwYXRoPSIvY3AvY29ubmVjdGlvblBvaW50L2NoZWNrTG9nU2NoZW1hIiBhdXRoZW50aWNhdGlvblR5cGU9IkRFVklDRSIgcHJvdG89IkhUVFBTRVNQIiB0eXBlPSJDSEVDS19MT0dfU0NIRU1BIiBwb3J0PSI0NDMiPjwvb3A+CiAgICAgICAgICAgIDxvcCBwYXRoPSIvZXBzL3NiYTRiL3JlZ2lzdGVyIiBhdXRoZW50aWNhdGlvblR5cGU9IkRFVklDRSIgcHJvdG89IkhUVFBTRVNQIiB0eXBlPSJTQkE0Ql9SRUdJU1RFUiIgcG9ydD0iNDQzIj48L29wPgogICAgICAgICAgICA8b3AgcGF0aD0iL2NwL2Nvbm5lY3Rpb25Qb2ludC9nZXRVbmluc3RhbGxBdXRoSW5mbyIgYXV0aGVudGljYXRpb25UeXBlPSJCT1RIIiBwcm90bz0iSFRUUFNFU1AiIHR5cGU9IkdFVF9VTklOU1RBTExfQVVUSF9JTkZPIiBwb3J0PSI0NDMiPjwvb3A+CiAgICAgICAgICAgIDxvcCBwYXRoPSIvY3AvY29ubmVjdGlvblBvaW50L2VuY3J5cHRSTU0iIGF1dGhlbnRpY2F0aW9uVHlwZT0iVVNFUiIgcHJvdG89IkhUVFBTRVNQIiB0eXBlPSJFTkNSWVBUX1JNTSIgcG9ydD0iNDQzIj48L29wPgogICAgICAgICAgICA8b3AgcGF0aD0iL2Vwcy9zYmE0Yi9wb2xpY3kiIGF1dGhlbnRpY2F0aW9uVHlwZT0iREVWSUNFIiBwcm90bz0iSFRUUFNFU1AiIHR5cGU9IlNCQTRCX1BPTElDWSIgcG9ydD0iNDQzIj48L29wPgogICAgICAgICAgICA8b3AgcGF0aD0iL2NwL2Nvbm5lY3Rpb25Qb2ludC90cmRSZXBvcnRJbmZvIiBhdXRoZW50aWNhdGlvblR5cGU9Ik5PTkUiIHByb3RvPSJIVFRQU0VTUCIgdHlwZT0iVFJEX1JFUE9SVF9JTkZPIiBwb3J0PSI0NDMiPjwvb3A+CiAgICAgICAgICAgIDxvcCBwYXRoPSIvY3AvY29ubmVjdGlvblBvaW50L2dldER5bmFtaWNQYWNrYWdlTG9jYXRpb24iIGF1dGhlbnRpY2F0aW9uVHlwZT0iREVWSUNFIiBwcm90bz0iSFRUUFNFU1AiIHR5cGU9IkdFVF9EWU5BTUlDX1BBQ0tBR0VfTE9DQVRJT04iIHBvcnQ9IjQ0MyI+PC9vcD4KICAgICAgICAgICAgPG9wIHBhdGg9Ii9jcC9jb25uZWN0aW9uUG9pbnQvZ2VuZXJpY1BheWxvYWQiIGF1dGhlbnRpY2F0aW9uVHlwZT0iTk9ORSIgcHJvdG89IkhUVFBTRVNQIiB0eXBlPSJHRU5FUklDX1BBWUxPQUQiIHBvcnQ9IjQ0MyI+PC9vcD4KICAgICAgICAgICAgPG9wIHBhdGg9Ii9jcC9jb25uZWN0aW9uUG9pbnQvbmV3a2V5IiBhdXRoZW50aWNhdGlvblR5cGU9Ik5PTkUiIHByb3RvPSJIVFRQUyIgdHlwZT0iTkVXX1pQRE9DX0tFWSIgcG9ydD0iNDQzIj48L29wPgogICAgICAgICAgICA8b3AgcGF0aD0iL2Vwcy9zYmE0Yi9sb2d1cGxvYWQiIGF1dGhlbnRpY2F0aW9uVHlwZT0iREVWSUNFIiBwcm90bz0iSFRUUFNFU1AiIHR5cGU9IlNCQTRCX0xPR1VQTE9BRCIgcG9ydD0iNDQzIj48L29wPgogICAgICAgICAgICA8b3AgcGF0aD0iL2NwL2Nvbm5lY3Rpb25Qb2ludC91cGxvYWRMb2dTY2hlbWEiIGF1dGhlbnRpY2F0aW9uVHlwZT0iREVWSUNFIiBwcm90bz0iSFRUUFNFU1AiIHR5cGU9IlVQTE9BRF9MT0dfU0NIRU1BIiBwb3J0PSI0NDMiPjwvb3A+CiAgICAgICAgICAgIDxvcCBwYXRoPSIvY3AvZmlsZSIgYXV0aGVudGljYXRpb25UeXBlPSJOT05FIiBwcm90bz0iSFRUUFMiIHR5cGU9IlNFUlZFUkxJU1QiIHBvcnQ9IjQ0MyI+PC9vcD4KICAgICAgICAgICAgPG9wIHBhdGg9Ii9jcC9jb25uZWN0aW9uUG9pbnQvdXNlckNoZWNrSW5mbyIgYXV0aGVudGljYXRpb25UeXBlPSJOT05FIiBwcm90bz0iSFRUUFNFU1AiIHR5cGU9IlVTRVJfQ0hFQ0tfSU5GTyIgcG9ydD0iNDQzIj48L29wPgogICAgICAgICAgICA8b3AgcGF0aD0iL2NwL2ZpbGUiIGF1dGhlbnRpY2F0aW9uVHlwZT0iTk9ORSIgcHJvdG89IkhUVFBTIiB0eXBlPSJEU01fU1NMX0RPV05MT0FEIiBwb3J0PSI0NDMiPjwvb3A+CiAgICAgICAgICAgIDxvcCBwYXRoPSIvY3AvY29ubmVjdGlvblBvaW50L2dldEZERURldkluZm8iIGF1dGhlbnRpY2F0aW9uVHlwZT0iREVWSUNFIiBwcm90bz0iSFRUUFNFU1AiIHR5cGU9IkdFVF9GREVfREVWSUNFX0lORk8iIHBvcnQ9IjQ0MyI+PC9vcD4KICAgICAgICAgICAgPG9wIHBhdGg9Ii9jcC9jb25uZWN0aW9uUG9pbnQvYWJCb3RzSW5mbyIgYXV0aGVudGljYXRpb25UeXBlPSJOT05FIiBwcm90bz0iSFRUUFNFU1AiIHR5cGU9IkFCX0JPVFNfSU5GTyIgcG9ydD0iNDQzIj48L29wPgogICAgICAgICAgICA8b3AgcGF0aD0iL2NwL2Nvbm5lY3Rpb25Qb2ludC9zZXRBY3Rpb25TdGF0dXMiIGF1dGhlbnRpY2F0aW9uVHlwZT0iREVWSUNFIiBwcm90bz0iSFRUUFNFU1AiIHR5cGU9IlNFVF9BQ1RJT05fU1RBVFVTIiBwb3J0PSI0NDMiPjwvb3A+CiAgICAgICAgICAgIDxvcCBwYXRoPSIvY3AvYXNrIiBhdXRoZW50aWNhdGlvblR5cGU9Ik5PTkUiIHByb3RvPSJIVFRQUyIgdHlwZT0iQVNLIiBwb3J0PSI0NDMiPjwvb3A+CiAgICAgICAgICAgIDxvcCBwYXRoPSIva2F2OHVwZGF0ZS9wcm9kdWN0aW9uIiBhdXRoZW50aWNhdGlvblR5cGU9Ik5PTkUiIHByb3RvPSJIVFRQUyIgdHlwZT0iQVZfUFJPRCIgcG9ydD0iNDQzIj48L29wPgogICAgICAgICAgICA8b3AgcGF0aD0iL2F2c2lnbmF0dXJlcy9hdjMiIGF1dGhlbnRpY2F0aW9uVHlwZT0iTk9ORSIgcHJvdG89IkhUVFBTIiB0eXBlPSJBVl9TT1BIT1NfUFJPRCIgcG9ydD0iNDQzIj48L29wPgogICAgICAgICAgICA8b3AgcGF0aD0iL2NwL2Nvbm5lY3Rpb25Qb2ludC91bnJlZ2VwIiBhdXRoZW50aWNhdGlvblR5cGU9Ik5PTkUiIHByb3RvPSJIVFRQU0VTUCIgdHlwZT0iVU5SRUdJU1RFUl9FTkRQT0lOVCIgcG9ydD0iNDQzIj48L29wPgogICAgICAgICAgICA8b3AgcGF0aD0iL2NwL2Nvbm5lY3Rpb25Qb2ludC9nZXRGREVOb2RlSW5mbyIgYXV0aGVudGljYXRpb25UeXBlPSJERVZJQ0UiIHByb3RvPSJIVFRQU0VTUCIgdHlwZT0iR0VUX0ZERV9OT0RFX0lORk8iIHBvcnQ9IjQ0MyI+PC9vcD4KICAgICAgICAgICAgPG9wIHBhdGg9Ii9jcC9jb25uZWN0aW9uUG9pbnQvc2V0RkRFRGV2SW5mbyIgYXV0aGVudGljYXRpb25UeXBlPSJERVZJQ0UiIHByb3RvPSJIVFRQU0VTUCIgdHlwZT0iU0VUX0ZERV9ERVZJQ0VfSU5GTyIgcG9ydD0iNDQzIj48L29wPgogICAgICAgICAgICA8b3AgcGF0aD0iL2FzdXBkYXRlL3Byb2R1Y3Rpb24iIGF1dGhlbnRpY2F0aW9uVHlwZT0iTk9ORSIgcHJvdG89IkhUVFBTIiB0eXBlPSJBU19QUk9EIiBwb3J0PSI0NDMiPjwvb3A+CiAgICAgICAgICAgIDxvcCBwYXRoPSIvY3AvY29ubmVjdGlvblBvaW50L211bHRpUGF5bG9hZHMiIGF1dGhlbnRpY2F0aW9uVHlwZT0iTk9ORSIgcHJvdG89IkhUVFBTRVNQIiB0eXBlPSJNVUxUSV9QQVlMT0FEUyIgcG9ydD0iNDQzIj48L29wPgogICAgICAgICAgICA8b3AgcGF0aD0iL2NwL2Nvbm5lY3Rpb25Qb2ludC90ZWxlbWV0cnkiIGF1dGhlbnRpY2F0aW9uVHlwZT0iTk9ORSIgcHJvdG89IkhUVFBTRVNQIiB0eXBlPSJURUxFTUVUUlkiIHBvcnQ9IjQ0MyI+PC9vcD4KICAgICAgICAgICAgPG9wIHBhdGg9Ii9jcC9maWxlIiBhdXRoZW50aWNhdGlvblR5cGU9Ik5PTkUiIHByb3RvPSJIVFRQUyIgdHlwZT0iUEFSIiBwb3J0PSI0NDMiPjwvb3A+CiAgICAgICAgICAgIDxvcCBwYXRoPSIvY3AvY29ubmVjdGlvblBvaW50L2dldEZERVVzZXJJbmZvIiBhdXRoZW50aWNhdGlvblR5cGU9IkRFVklDRSIgcHJvdG89IkhUVFBTRVNQIiB0eXBlPSJHRVRfRkRFX1VTRVJfSU5GTyIgcG9ydD0iNDQzIj48L29wPgogICAgICAgICAgICA8b3AgcGF0aD0iL2NwL2Nvbm5lY3Rpb25Qb2ludC9nZXRBY3Rpb25zIiBhdXRoZW50aWNhdGlvblR5cGU9IkRFVklDRSIgcHJvdG89IkhUVFBTRVNQIiB0eXBlPSJHRVRfQUNUSU9OUyIgcG9ydD0iNDQzIj48L29wPgogICAgICAgICAgICA8b3AgcGF0aD0iL2NwL2ZpbGUiIGF1dGhlbnRpY2F0aW9uVHlwZT0iTk9ORSIgcHJvdG89IkhUVFBTIiB0eXBlPSJEU01fRE9XTkxPQUQiIHBvcnQ9IjQ0MyI+PC9vcD4KICAgICAgICAgICAgPG9wIHBhdGg9Ii9jcC9jb25uZWN0aW9uUG9pbnQvdXBkYXRlRFNJbnN0YW5jZSIgYXV0aGVudGljYXRpb25UeXBlPSJERVZJQ0UiIHByb3RvPSJIVFRQU0VTUCIgdHlwZT0iVVBEQVRFX0RTX0lOU1RBTkNFIiBwb3J0PSI0NDMiPjwvb3A+CiAgICAgICAgICAgIDxvcCBwYXRoPSIvY3AvY29ubmVjdGlvblBvaW50L2luY2lkZW50cmVwb3J0IiBhdXRoZW50aWNhdGlvblR5cGU9Ik5PTkUiIHByb3RvPSJIVFRQU0VTUCIgdHlwZT0iSU5DSURFTlRfUkVQT1JUIiBwb3J0PSI0NDMiPjwvb3A+CiAgICAgICAgICAgIDxvcCBwYXRoPSIvY3AvY29ubmVjdGlvblBvaW50L3VwZGF0ZURpcmVjdG9yeUluZm8iIGF1dGhlbnRpY2F0aW9uVHlwZT0iREVWSUNFIiBwcm90bz0iSFRUUFNFU1AiIHR5cGU9IlVQREFURV9ESVJFQ1RPUllfSU5GTyIgcG9ydD0iNDQzIj4KICAgICAgICAgICAgICAgIDxhdHRyIG5hbWU9IkRJX1JFU1RSSUNUIiB2YWx1ZT0iKiI+PC9hdHRyPgogICAgICAgICAgICAgICAgPGF0dHIgbmFtZT0iRElfSU5URVJWQUwiIHZhbHVlPSI3MjAwIj48L2F0dHI+CiAgICAgICAgICAgICAgICA8YXR0ciBuYW1lPSJESV9QUk9QRVJUSUVTIiB2YWx1ZT0ib2JqZWN0Q2F0ZWdvcnksb2JqZWN0Q2xhc3Msb2JqZWN0R1VJRCxuYW1lLGRpc3BsYXlOYW1lLGRpc3Rpbmd1aXNoZWROYW1lLGNhbm9uaWNhbE5hbWUsZG9tYWluTmFtZSxkZXNjcmlwdGlvbixvYmplY3RTaWQsc0FNQWNjb3VudE5hbWUsb3BlcmF0aW5nU3lzdGVtLG9wZXJhdGluZ1N5c3RlbVZlcnNpb24sbGFzdExvZ29uVGltZXN0YW1wLHVzZXJBY2NvdW50Q29udHJvbCxhY2NvdW50RXhwaXJlcyxsb2Nrb3V0VGltZSx1c2VyUHJpbmNpcGFsTmFtZSxtYWlsLHRlbGVwaG9uZU51bWJlcixtb2JpbGUsdXNlckNlcnRpZmljYXRlLGdyb3VwVHlwZSxtZW1iZXJPZix1U05DaGFuZ2VkLGlzRGVsZXRlZCI+PC9hdHRyPgogICAgICAgICAgICA8L29wPgogICAgICAgICAgICA8b3AgcGF0aD0iL2NwL2Nvbm5lY3Rpb25Qb2ludC9zZXRGREVVc2VySW5mbyIgYXV0aGVudGljYXRpb25UeXBlPSJVU0VSIiBwcm90bz0iSFRUUFNFU1AiIHR5cGU9IlNFVF9GREVfVVNFUl9JTkZPIiBwb3J0PSI0NDMiPjwvb3A+CiAgICAgICAgICAgIDxvcCBwYXRoPSIvY3AvY29ubmVjdGlvblBvaW50L2dldERTQ29uZmlnIiBhdXRoZW50aWNhdGlvblR5cGU9IkRFVklDRSIgcHJvdG89IkhUVFBTRVNQIiB0eXBlPSJHRVRfRFNfQ09ORklHIiBwb3J0PSI0NDMiPgogICAgICAgICAgICAgICAgPGF0dHIgbmFtZT0iRFNfTEFTVFVQREFURUQiIHZhbHVlPSIwIj48L2F0dHI+CiAgICAgICAgICAgIDwvb3A+CiAgICAgICAgICAgIDxvcCBwYXRoPSIvY3AvY29ubmVjdGlvblBvaW50L2FtSW5mZWN0aW9uc0luZm8iIGF1dGhlbnRpY2F0aW9uVHlwZT0iTk9ORSIgcHJvdG89IkhUVFBTRVNQIiB0eXBlPSJBTV9JTkZFQ1RJT05TX0lORk8iIHBvcnQ9IjQ0MyI+PC9vcD4KICAgICAgICAgICAgPG9wIHBhdGg9Ii9jcC9jb25uZWN0aW9uUG9pbnQvZWZySW5jaWRlbnRSZXBvcnQiIGF1dGhlbnRpY2F0aW9uVHlwZT0iTk9ORSIgcHJvdG89IkhUVFBTRVNQIiB0eXBlPSJFRlJfSU5DSURFTlRfUkVQT1JUIiBwb3J0PSI0NDMiPjwvb3A+CiAgICAgICAgICAgIDxvcCBwYXRoPSIvYXN1cGRhdGUvc3RhZ2luZyIgYXV0aGVudGljYXRpb25UeXBlPSJOT05FIiBwcm90bz0iSFRUUFMiIHR5cGU9IkFTX1NUQUciIHBvcnQ9IjQ0MyI+PC9vcD4KICAgICAgICAgICAgPG9wIHBhdGg9Ii9jcC9jb25uZWN0aW9uUG9pbnQvaGIiIGF1dGhlbnRpY2F0aW9uVHlwZT0iTk9ORSIgcHJvdG89IkhUVFBTRVNQIiB0eXBlPSJIQiIgcG9ydD0iNDQzIj4KICAgICAgICAgICAgICAgIDxhdHRyIG5hbWU9IkhCX1JFU1RSSUNUIiB2YWx1ZT0iNSI+PC9hdHRyPgogICAgICAgICAgICAgICAgPGF0dHIgbmFtZT0iSEJfVEVSTUlOQVRFIiB2YWx1ZT0iLTEiPjwvYXR0cj4KICAgICAgICAgICAgICAgIDxhdHRyIG5hbWU9IkhCX0lOVEVSVkFMIiB2YWx1ZT0iOTAiPjwvYXR0cj4KICAgICAgICAgICAgPC9vcD4KICAgICAgICAgICAgPG9wIHBhdGg9Ii9jcC9jb25uZWN0aW9uUG9pbnQvZGVjcnlwdFJNTSIgYXV0aGVudGljYXRpb25UeXBlPSJVU0VSIiBwcm90bz0iSFRUUFNFU1AiIHR5cGU9IkRFQ1JZUFRfUk1NIiBwb3J0PSI0NDMiPjwvb3A+CiAgICAgICAgICAgIDxvcCBwYXRoPSIvY3AvY29ubmVjdGlvblBvaW50L3VwcmVnIiBhdXRoZW50aWNhdGlvblR5cGU9IkRFVklDRSIgcHJvdG89IkhUVFBTIiB0eXBlPSJVUERBVEVfUkVHSVNURVIiIHBvcnQ9IjQ0MyI+PC9vcD4KICAgICAgICAgICAgPG9wIHBhdGg9Ii9jcC9jb25uZWN0aW9uUG9pbnQvU2V0VW5pbnN0YWxsS2V5IiBhdXRoZW50aWNhdGlvblR5cGU9IkRFVklDRSIgcHJvdG89IkhUVFBTRVNQIiB0eXBlPSJTRVRfVU5JTlNUQUxMX0tFWSIgcG9ydD0iNDQzIj48L29wPgogICAgICAgICAgICA8b3AgcGF0aD0iL2thdjh1cGRhdGUvc3RhZ2luZyIgYXV0aGVudGljYXRpb25UeXBlPSJOT05FIiBwcm90bz0iSFRUUFMiIHR5cGU9IkFWX1NUQUciIHBvcnQ9IjQ0MyI+PC9vcD4KICAgICAgICA8L29wR3JvdXA+CiAgICA8L29wR3JvdXBzPgogICAgPHNlcnZlcnM+CiAgICAgICAgPHNlcnZlciB0eXBlPSJFUFMiIGFjY2VwdHNDbGllbnRzPSJ0cnVlIiBhZGRyPSIiIGZxZG49IldhbGxib3gtZmE2ZDgwYjAtaGFwMi5lcG1nbXQuY2hlY2twb2ludC5jb20iIG9wR3JvdXA9ImRlZmF1bHQiIGFkZHI2PSIiIGRuPSJDTj0qLmVwbWdtdC5jaGVja3BvaW50LmNvbSI+CiAgICAgICAgICAgIDxncm91cCBuYW1lPSJkZWZhdWx0Ij48L2dyb3VwPgogICAgICAgIDwvc2VydmVyPgogICAgPHNlcnZlciB0eXBlPSJFUFMiIHhtbG5zPSIiIGFjY2VwdHNDbGllbnRzPSJ0cnVlIiBhZGRyPSIiIGZxZG49IldhbGxib3gtZmE2ZDgwYjAtaGFwMjEuZXBtZ210LmNoZWNrcG9pbnQuY29tIiBvcEdyb3VwPSJkZWZhdWx0IiBhZGRyNj0iIiBkbj0iQ049Ki5lcG1nbXQuY2hlY2twb2ludC5jb20iPjxncm91cCBuYW1lPSJkZWZhdWx0Ij48L2dyb3VwPjwvc2VydmVyPjwvc2VydmVycz4KICAgIDxhdXRoUHJpbmNpcGFscz48L2F1dGhQcmluY2lwYWxzPgogICAgPG9wZXJhdGlvbk1vZGU+CiAgICAgICAgPGF1dGhlbnRpY2F0ZUVuZHBvaW50cz5mYWxzZTwvYXV0aGVudGljYXRlRW5kcG9pbnRzPgogICAgPC9vcGVyYXRpb25Nb2RlPgogICAgPHN1cHBvcnRlZEZlYXR1cmVzPgogICAgICAgIDxmZWF0dXJlIG5hbWU9IkNvbW1vbiBDcml0ZXJpYSIgdmVyc2lvbj0iMiI+PC9mZWF0dXJlPgogICAgICAgIDxmZWF0dXJlIG5hbWU9Ik1FUFBfU1RPUkVfREVWSUNFSU5GTyIgdmVyc2lvbj0iMSI+PC9mZWF0dXJlPgogICAgICAgIDxmZWF0dXJlIG5hbWU9IkZJTEVWQVVMVF9SRUNPVkVSWSIgdmVyc2lvbj0iMSI+PC9mZWF0dXJlPgogICAgICAgIDxmZWF0dXJlIG5hbWU9IkZERV9BVVRIRU5USUNBVElPTl9USU1FU1RBTVAiIHZlcnNpb249IjEiPjwvZmVhdHVyZT4KICAgICAgICA8ZmVhdHVyZSBuYW1lPSJBWlVSRV9BRF9TVVBQT1JUIiB2ZXJzaW9uPSIxIj48L2ZlYXR1cmU+CiAgICA8L3N1cHBvcnRlZEZlYXR1cmVzPgo8L0NQRVBTTmV0d29yaz48L0RBX0NPTkZJRz4= MANIFEST_B64=PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0idXRmLTgiPz48IURPQ1RZUEUgcGxpc3QgUFVCTElDICItLy9BcHBsZS8vRFREIFBMSVNUIDEuMC8vRU4iICJodHRwOi8vd3d3LmFwcGxlLmNvbS9EVERzL1Byb3BlcnR5TGlzdC0xLjAuZHRkIj48cGxpc3QgdmVyc2lvbj0iMS4wIj48ZGljdD48a2V5PkJsYWRlczwva2V5PjxkaWN0IC8+PGtleT5Db25maWc8L2tleT48ZGljdD48a2V5PmNvbmZpZy5kYXQ8L2tleT48c3RyaW5nPi5jb25maWdfZGF0PC9zdHJpbmc+PC9kaWN0PjxrZXk+RmVhdHVyZXM8L2tleT48ZGljdD48a2V5PlN1cGVyTm9kZTwva2V5Pjx0cnVlIC8+PGtleT5GaXJld2FsbElQVjY8L2tleT48dHJ1ZSAvPjxrZXk+UG9ydFByb3RlY3Rpb248L2tleT48dHJ1ZSAvPjxrZXk+UHVzaE9wZXJhdGlvbnM8L2tleT48dHJ1ZSAvPjxrZXk+VGVsZW1ldHJ5PC9rZXk+PHRydWUgLz48a2V5PldlYkd1aTwva2V5Pjx0cnVlIC8+PC9kaWN0PjwvZGljdD48L3BsaXN0Pgo= URL="https://ep-client-installers-prd-public.s3.amazonaws.com/eps-clients/mac/88.40.5927/EPS_E88.40_ONLY_DA.zip" CURL_SWITCH= CURL_SWITCH="$CURL_SWITCH --connect-timeout 10 -f" read_server_from_config_dat () { local IFS=\> read -d \< ENTITY CONTENT local ret=$? TAG_NAME=${ENTITY%% *} ATTRIBUTES=${ENTITY#* } return $ret } try_download_from_server () { if [[ $TAG_NAME = "server" ]] ; then eval local $ATTRIBUTES HOST=$fqdn if [ -z $HOST ]; then HOST=$addr fi SERVER_URL=$(echo $URL | sed -e "s|https://[^/]*|https://$HOST|") if [ $URL = $SERVER_URL ]; then $ECHO "Skipping download from $SERVER_URL, has already been tried ($URL)" return 1 fi $ECHO -n "Trying download from $SERVER_URL..." $CURL $CURL_SWITCH $SERVER_URL -o $EPS_ZIP >/dev/null 2>&1 RET=$? if [ $RET -ne 0 ]; then $ECHO "failed with curl error $RET" $RM -rf $EPS_ZIP return $RET fi $ECHO "succeeded" return 0 fi return 1 } set +e $PKGUTIL --pkg-info com.checkpoint.pkg.eps.core if [ $? -eq 0 ]; then echo "Endpoint Security for macOS already deployed (core receipt exists)" exit 0 fi set -e if [ -d "/Applications/Check Point/Agents/cpdaApp.app" ]; then echo "Endpoint Security for macOS already deployed (device agent is installed)" exit 0 fi EPS_ZIP=EPS_ONLY_DA.zip TMP_DIR="$(mktemp -d /tmp/endpoint_security_installer.XXXXXX)" cd $TMP_DIR echo $CONFIG_DAT_B64 | $BASE64 --decode -o .config_dat echo $MANIFEST_B64 | $BASE64 --decode -o .InstallationManifest.plist set +e $CURL $CURL_SWITCH $URL -o $EPS_ZIP >/dev/null 2>&1 if [ $? -ne 0 ]; then while read_server_from_config_dat; do try_download_from_server if [ $? -eq 0 ]; then break fi done < .config_dat fi set -e if [ ! -f $EPS_ZIP ]; then echo "Download of Endpoint Security initial client failed." exit 1 fi $UNZIP $EPS_ZIP PKG_DIR="$TMP_DIR/Endpoint Security Installer.app/Contents/Resources/Configurations" cd "$PKG_DIR" PKG_NAME="$(ls "$PKG_DIR" | grep *.pkg)" PKG_PATH="$PKG_DIR/$PKG_NAME" $INSTALLER -pkg "$PKG_PATH" -target / exit 0 ``` --- ## Dock Configuration Source: https://docs.applivery.com/en/device-management/apple/macos/policies/dock-configuration/ Description: Customize the macOS Dock using Applivery Device Management Policies — add persistent Apps, static Apps, and control layout. TL;DR: Customize the macOS Dock on macOS devices with Applivery by adding persistent or static apps. Key topics: macOS Dock configuration, Applivery device management, Application management, Applivery, macOS Dock The Dock is the application launcher bar that appears at the bottom (or sides) of the macOS screen by default. Through Applivery, you can configure and lock down the Dock across your entire managed Mac fleet — controlling which Apps appear, where the Dock is positioned, how it behaves, and whether users can modify it at all. This is particularly useful for standardizing the user environment on shared or corporate-issued Macs, ensuring that key organizational tools are always visible and accessible. ### Requirements - **macOS:** 10.12 or later (most settings). Some keys require newer versions — noted where relevant. - **Supervision:** Not required for Dock configuration payloads. - **Enrollment type:** Applies to device-level enrolment and user-channel profiles. ### Dock configuration **How to configure the Dock** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io), head to any of your **Policies** or [create a new one](https://docs.applivery.com/en/device-management/general-settings/create-policies/). From the left-hand menu, navigate to the **\+ Add configuration** option and then choose **Dock**. ![dock](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/283d5467-2cb4-4688-8e5f-228593913041.png) **Dock Layout: Adding Apps, Folders and Files** The Dock configuration allows you to define which items appear in the Dock and in what order. Items are organized into two main sections — **Apps** (left side of the divider) and **others** (right side of the divider, for folders and files) — and each item type requires a different configuration. **Persistent Apps vs. Static Apps** When adding applications to the Dock, you must choose one of two modes for each App: | Mode | Key | Behavior | | --- | --- | --- | | **Persistent Apps** | `persistent-Apps` | The App appears in the Dock, but users can remove it by dragging it out. | | **Static Apps** | `static-Apps` | The App is permanently pinned to the Dock. Users cannot remove it. | :::tip Use `static-apps` for mandatory organizational tools (e.g., your VPN client, ticketing system, or company portal). Use `persistent-apps` for recommended Apps where some user flexibility is acceptable. ::: Equally, for non-application items (Folders, Files, URLs): | Mode | Key | Behavior | | --- | --- | --- | | **Persistent Others** | `persistent-others` | Folders and files that the user can remove. | | **Static Others** | `static-others` | Folders and files permanently fixed in the Dock. | **Tile Data: Defining each Dock item** Every item added to the Dock — whether an App, Folder, or File — requires a **Tile Data** dictionary that tells macOS how to identify and render it. The required keys vary depending on the tile type. **Application tiles (tile-type: application-tile)** | Key | Type | Description | | --- | --- | --- | | `file-data` | Dictionary | Contains the `_CFURLString` key with the full path to the application. | | `_CFURLString` | String | Absolute path to the `.app` bundle. Example: `/Applications/Safari.app` | | `_CFURLStringType` | Integer | Always `0` for local file paths. | | `tile-type` | String | Must be `application-tile`. | | `label` | String | Optional. Display name shown under the icon. If omitted, the App's default name is used. | **Example: Adding Safari** ```xml tile-data file-data _CFURLString /Applications/Safari.app _CFURLStringType 0 label Safari tile-type application-tile ``` **Folder tiles (tile-type: directory-tile)** Used to add Folders (such as the Downloads folder or a shared network volume) to the right side of the Dock. | Key | Type | Description | | --- | --- | --- | | `file-data` | Dictionary | Contains `_CFURLString` with the full path to the Folder. | | `_CFURLString` | String | Absolute path to the Folder. Example: `~/Downloads` or `/Users/Shared` | | `_CFURLStringType` | Integer | `0` for local paths. | | `tile-type` | String | Must be `directory-tile`. | | `displayas` | Integer | How the folder is shown: `0` = Stack, `1` = Folder. | | `showas` | Integer | How contents are revealed: `0` = Automatic, `1` = Fan, `2` = Grid, `3` = List. | | `arrangement` | Integer | Sort order of Folder contents: `1` = Name, `2` = Date Added, `3` = Date Modified, `4` = Date Created, `5` = Kind. | | `label` | String | Optional display label. | **Example: Adding the Downloads folder as a grid stack** ```xml tile-data file-data _CFURLString /Users/username/Downloads _CFURLStringType 0 label Downloads displayas 0 showas 2 arrangement 2 tile-type directory-tile ``` **URL tiles (tile-type: url-tile)** Adds a web URL directly to the Dock. Clicking it opens the URL in the default browser. | Key | Type | Description | | --- | --- | --- | | `url` | String | The URL to open. Example: `https://intranet.company.com` | | `label` | String | Display name shown under the icon. | | `tile-type` | String | Must be `url-tile`. | **Dock appearance and behavior settings** Beyond the items in the Dock, the configuration supports a full set of appearance and behavior settings. #### Position and size | Key | Type | Values / Description | | --- | --- | --- | | `orientation` | String | Position of the Dock on screen: `bottom` (default), `left`, `right`. | | `tilesize` | Integer | Size of Dock icons in points. Range: `16`–`128`. Default: `64`. | | `magnification` | Boolean | If `true`, icons magnify when hovered. | | `largesize` | Integer | Maximum icon size when magnification is enabled. Range: `16`–`128`. Only effective if `magnification` is `true`. | #### Auto-hide and show | Key | Type | Description | | --- | --- | --- | | `autohide` | Boolean | If `true`, the Dock hides automatically when not in use and reappears on hover. | | `autohide-delay` | Real | Delay in seconds before the Dock hides (default: `0.5`). Example: `0.0` for instant. | | `autohide-time-modifier` | Real | Duration multiplier for the hide/show animation. `0.0` = instant, `1.0` = default speed, `0.5` = twice as fast. | #### Animations and visual effects | Key | Type | Description | | --- | --- | --- | | `launchanim` | Boolean | If `true`, Apps animate (bounce) when opened from the Dock. | | `mineffect` | String | Animation style when windows are minimized into the Dock: `genie` (default) or `scale`. | | `minimize-to-application` | Boolean | If `true`, minimized windows collapse into the App icon rather than into the Dock tray. | | `show-recents` | Boolean | If `false`, the "Recent Applications" section is hidden from the Dock. Requires macOS 10.14+. | #### Window and App Management | Key | Type | Description | | --- | --- | --- | | `expose-group-Apps` | Boolean | If `true`, Mission Control groups windows by application. | | `mru-spaces` | Boolean | If `false`, Spaces are not automatically reordered based on recent use. Useful for keeping a fixed space layout. | | `show-process-indicators` | Boolean | If `true` (default), a dot appears under running application icons. Set to `false` to hide these indicators. | **Locking the Dock to prevent user changes** The Dock configuration includes several lock keys that prevent users from modifying the Dock configuration set by MDM. These are particularly important in standardized or shared-device environments. | Key | Type | Description | | --- | --- | --- | | `contents-immutable` | Boolean | If `true`, users cannot add, remove, or rearrange items in the Dock. The Dock is fully locked. | | `size-immutable` | Boolean | If `true`, users cannot resize the Dock. | | `position-immutable` | Boolean | If `true`, users cannot change the Dock's position on screen. | | `autohide-immutable` | Boolean | If `true`, users cannot toggle the auto-hide setting. | | `magnify-immutable` | Boolean | If `true`, users cannot toggle magnification. | | `magsize-immutable` | Boolean | If `true`, users cannot change the magnification size. | | `mineffect-immutable` | Boolean | If `true`, users cannot change the minimize animation style. | :::tip Setting `contents-immutable` to `true` is the most common approach for locked-down Devices. It prevents users from adding, removing, or rearranging items, but does not restrict the Dock's visual settings unless the corresponding `*-immutable` keys are also enabled. ::: ### Common configuration examples A corporate Mac with a fixed set of mandatory Apps. Users cannot modify the Dock at all. - Set `contents-immutable` to `true`. - Add required Apps under `static-apps`. - Set `show-recents` to `false` to hide the Recent Apps section. - Set `position-immutable` and `size-immutable` to `true` if you also want to lock visual settings. Apps the organization wants visible by default, but allows users to customize from there. - Add Apps under `persistent-apps` (not `static-apps`). - Leave all `*-immutable` keys at `false`. - Set `tilesize` to a comfortable default for your hardware. A shared Device where the Dock must always look the same, regardless of who logs in. - Set `contents-immutable`, `size-immutable`, `position-immutable`, `autohide-immutable` all to `true`. - Use `static-apps` and `static-others` exclusively. - Set `autohide` to `false` to keep the Dock always visible. - Set `show-recents` to `false`. ### Important behaviors and limitations - **Payload updates apply at the next login or Policy sync.** Changes to the Dock payload are applied when the MDM profile is refreshed. In some cases, the user may need to log out and back in for changes to fully take effect. - `static-apps` **vs.** `persistent-apps` **take effect together.** If you define both, `static-apps` items appear first and are locked; `persistent-apps` items follow and are flexible. - **User-added items may persist between MDM updates** if `contents-immutable` is not set. When a new profile is pushed without this lock, previously user-added items may remain in the Dock. - **App paths must be exact.** If an application is not installed at the path specified in `_CFURLString`, the Dock will show a broken icon. Ensure the App is installed on the Device before or alongside the Dock payload. - `~` **(tilde) expansion in paths** may not work reliably in MDM payloads. Use absolute paths (e.g., `/Users/Shared/`) instead of user-relative paths where possible, or use [dynamic variables](https://docs.applivery.com/en/device-management/general-settings/dynamic-variables/). - **The Dock configuration does not install Apps.** It only configures what appears in the Dock. Apps must be separately deployed via App Management before being added to the Dock configuration. --- ## File Management Source: https://docs.applivery.com/en/device-management/apple/macos/policies/file-management/ Description: Manage and secure content files on macOS Devices using Applivery — distribute files via Policies and ensure organizational security. TL;DR: Securely distribute and manage content files on macOS devices using Applivery by adding files to policies, selecting file types, and configuring scope and location. Key topics: macOS file management, Mobile Device Management (MDM), Applivery, macOS As businesses grow, so does the need to manage and secure data on Devices. Managing content files on macOS Devices is vital to maintaining productivity and security within an organization.  File management in macOS allows you to upload files defining their location and attributes, assigning them to the system, all users, or the current user. With this configuration, you can distribute books, set up a wallpaper, or deploy certificates. :::warning To use this feature, ensure that the **Applivery macOS Agent** is enabled. You can learn more about it [here](https://docs.applivery.com/en/device-management/apple/apple-policies/agent/). ::: **Adding a File to a Policy** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), go to any of your **Policies** 1 or [create a new one](https://docs.applivery.com/en/device-management/general-settings/create-policies/). From the left-hand menu, click on the **Resources** 2 section, then click the **\+ Add Resource** button 3. ![add resource](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ade63557-2f89-45f2-b3ee-3fc13d6b5ab4.png) **Select the File type** A modal view will be displayed, allowing you to select the type of file you want to add to the Policy: - **Books**: in `.epub` or `.pdf` format. - **Certificates**: in `.p12`, `.pem` or `.der` format. - **Images**: in `.png` or `.jpg` format. **Upload the File** You can choose to upload the selected file either from the Resources section or from your Device. Next, you can select both the **Scope** and the **Location** where the file will be saved. Once you choose the scope, in the Location field, you can either use the recommended location or define it yourself: - **Primary user**: The file will be saved for the current user and will be only accessible to them. The recommended path will be `~/AppliveryAssets`. - **All users**: The file will be saved in a shared folder accessible to all users. The recommended path will be `/Users/Shared/AppliveryAssets`. - **System**: The file will be stored in a protected path accessible only by root. The recommended path will be `/var/root/AppliveryAssets`. :::info File checks are performed every 10 minutes. If the file is not found, has changed in size, or has different attributes, it will be re-downloaded, overwriting the previous version. ::: --- ## FileVault Configuration Source: https://docs.applivery.com/en/device-management/apple/macos/policies/filevault/ Description: Configure FileVault disk encryption on macOS Devices with Applivery — enforce full-disk encryption and manage recovery keys via MDM. TL;DR: Secure your macOS devices with FileVault using Applivery by configuring encryption policies and managing recovery keys through automatic or manual methods. Key topics: FileVault configuration, Applivery device management, macOS security policies, FileVault, Applivery, macOS, Apple FileVault, available in macOS 10.3 and newer versions, encrypts your entire disk to safeguard your data and prevent unauthorized access on your Mac. Once enabled, you’ll need a **Password** or **Recovery Key** to access your Device, ensuring your data remains secure and inaccessible without proper authentication. FileVault also automatically encrypts all new files, providing continuous protection. Enabling FileVault is a useful configuration to protect your data in case your Mac is lost or damaged. :::info Once configured, deleting the Policy or disassociating Devices **will not turn off FileVault**. ::: With Applivery, you have two options for Recovery Key management (being able to choose how the Recovery Key is encrypted and recovered): - **Auto** (recommended): Applivery will handle the necessary certificates. The Recovery Key will be displayed in the Device settings. - **Manual**: You will need to upload the Public Key. Later, you can download the encrypted Recovery Key and decrypt it on your Device using the Private Key. ### Recovery Key Management - Auto **Navigate to Policies** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), navigate to any of your **Policies** 1 or [create a new one](https://docs.applivery.com/en/device-management/general-settings/create-policies/). From the left-hand menu, navigate to the **\+ Add configuration** option and select **FileVault** 2. ![filevault](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/fa5b0322-8dbc-4abf-9d09-486604c35366.png) **Configure Main Settings** In the **Main** menu, you will need to **Enable** FileVault and select the **Defer** option, which postpones enabling FileVault until the user logs out. Additionally, check the **Use Recovery Key** and **Show Recovery Key** options to display it later. ![enable and defer](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/0e4d0d84-93b5-4fb3-9465-8a1e6b712449.png) ![recovery key](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/5db4eab0-6104-4cd3-a488-5d12d2faf569.png) **Configure Options Settings** In the **Options** menu, select **Don’t Allow FDE Disable** to prevent FileVault from being disabled.  ![dont allow disable](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/3e91cd76-0bcc-4418-8cfb-c18d344a3cbd.png) **Configure Recovery Settings** In the **Recovery** menu, leave the **Auto** option selected. Applivery will handle the necessary certificates, and the Recovery Key will be displayed in the **Device Settings**. ![recovery auto](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/1fdcb600-5b12-4f7b-928f-3ed3ee308c8f.png) **Retrieve Recovery Key** After saving and updating the Policy, the user will need to log out. Upon the next login, the FileVault activation forms will appear. On the [**Applivery Dashboard**](https://dashboard.applivery.io/), go to any of your **Devices**, selecting the one from which you want to obtain the Recovery Key. Go to the **Settings** 3 tab, and select **FileVault** 4 from the left-hand menu. Click the **Reveal** button 5 to retrieve the Recovery Key. ![reveal recovery key](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/8381ecc3-7e16-4790-942d-4270e0ab51af.png) ### Recovery Key Management - Manual **Create a certificate for FileVault Recovery Key encryption** To encrypt the Recovery Key, an **encryption certificate** must be created and uploaded to Applivery. On a macOS computer (10.8+), open **Terminal** and execute the command: ``` openssl req -x509 -nodes -newkey rsa:2048 -keyout private.pem -out public.der -days 365 -outform der ``` This will generate a Public Key in `.der` format. After creating the certificate, go to **Resources** 6 and select **Certificates** 7 from the left-hand menu. Click on **\+ Upload Certificate** 8. A modal view will appear, allowing you to upload the newly created certificate by clicking on the **Select file** 9 button and loading it from your drive. ![upload certificate](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/2a6f55f3-cc09-4e17-8235-f0a73690b481.png) **Configure Policy** You will need to perform the same configurations you did in **Auto** mode for the **Main** and **Options** menus. **Only the settings for the Recovery menu will be modified**. This time, you will select **Manual** for Recovery Key Management. In the **Encrypt Cert Payload UUID** 10 field, you will load the certificate previously uploaded in the Certificates section. Describe the **Location** field to indicate where the Recovery Key is stored, ensuring users know where to find it. For the **Device Key** field, enter a string (help text) for users who may have forgotten their password. Site admins can use this key to locate the escrowed key for the specific Device. This key supersedes the `RecordNumber` key used in the previous escrow mechanism. If the key is absent, the Device serial number is used instead. ![recovery manual](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/da977ae3-fe42-4c06-9b07-ca647ae709d5.png) **What happens at the Device end** After saving and updating the Policy on the terminal, the user will need to log out. Upon the next login, the FileVault activation forms will appear. Once completed, send an **Update status** command, and you will then have the encrypted key available on the Device under the **FDE Personal Recovery Key CMS** field. Once the Policy is applied, users will not be able to modify the FileVault settings under  **System Preferences > Security & Privacy > FileVault**. The settings as configured in the Policy will be enforced. :::warning Applying another FileVault Policy to an already encrypted Device has no effect. ::: **Retrieving the Recovery Key** Finally, navigate to any of your **Devices**. Go to the **Settings** section, select **FileVault** from the left-hand menu, and click on the **Download encrypted file** button. A `.dat` file will be downloaded, and you will need to execute the following command to decrypt the key: ``` openssl cms -decrypt -in recovery.dat -inform DER -inkey filevault_privateKey.pem ``` :::warning The FileVault Recovery Key cannot be retrieved if the Device was encrypted prior to enrollment or before a FileVault Policy was applied to it. ::: ### Troubleshooting #### Weird or unreadable characters when displaying the FileVault Recovery Key If the FileVault Recovery Key is displayed with strange or unreadable characters, it usually means the Device was already encrypted before being enrolled in Applivery. In this scenario, Applivery is retrieving the previously encrypted Recovery Key, not a newly generated one. To resolve this issue, follow these steps: 1. Have the user manually disable FileVault on the Device by going to  **System Settings** > **Privacy & Security** > **FileVault** > **Turn Off**. **This action must be performed by an administrator user on the Mac**. 2. Once FileVault has been turned off, ask the user to **log in again** to the Device. After the next login, FileVault will generate a new Recovery Key, which will be properly managed and displayed by Applivery without formatting issues. This process ensures that the Recovery Key is regenerated under Applivery management and can be correctly viewed and stored for future recovery scenarios. --- ## Google Chrome Homepage Configuration Source: https://docs.applivery.com/en/device-management/apple/macos/policies/google-chrome-homepage-configuration/ Description: Configure the Google Chrome homepage URL on macOS Devices using a Plist file deployed via Applivery Device Management Policies. TL;DR: Configure Chrome homepage on macOS using Plist files and Applivery policies. Key topics: Device Management, Browser Configuration, macOS Policies, Google Chrome, Applivery, macOS Configuring the homepage allows IT admins to control the content displayed when users launch the browser. Use the following Plist to set a homepage URL for the Google Chrome browser. Copy the contents from below and import them into the relevant macOS Policy. ```html title="Chrome Homepage Plist" PayloadContent HomepageLocation https://www.applivery.com NewTabPageLocation https://www.applivery.com/docs PayloadDisplayName Google Chrome PayloadIdentifier com.google.Chrome.F8C05D93-31F5-416E-AF46-2E54F2578F9A PayloadType com.google.Chrome PayloadUUID B98A135C-3F21-40E9-9D0C-CD9E4A5A46A6 PayloadVersion 1 ``` Replace the home page URL with the URL that you would like to use in the above Payload. For example: ```xml HomepageLocation https://www.applivery.com NewTabPageLocation https://www.applivery.com/docs ``` Once in the [**Applivery Dashboard**](https://dashboard.applivery.io), go to any of your **Policies** 1 or [create a new one](https://docs.applivery.com/en/device-management/general-settings/create-policies/). Click the **\+ Add configuration** button on the left-hand menu, then click the **\+ Import** 2 button. ![import](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/f3b41af3-190e-4361-9dfb-c0b1a568514a.png) You can either copy the Plist above or use the **Upload XML** button to upload a new one. ![plist](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/417c6f5d-ffc2-46b2-9108-07b0ffa2194a.png) :::info Restart Google Chrome to verify that the configuration has been applied correctly. ::: --- ## Install Chrome Extensions Source: https://docs.applivery.com/en/device-management/apple/macos/policies/install-chrome-extensions/ Description: Force-install Google Chrome extensions on macOS Devices by importing a Plist with ExtensionInstallForcelist or ExtensionSettings into an Applivery Policy. TL;DR: Import a Plist with the ExtensionInstallForcelist key (com.google.Chrome payload) into a macOS Policy. Applivery scripts help you verify the result or serve as an alternative when you can't use a Policy. Key topics: Chrome extension ID, Plist with ExtensionInstallForcelist, Pinning extensions with ExtensionSettings, Verification and alternative install scripts, Troubleshooting, Applivery, Google Chrome, Chrome Web Store, macOS, Plist The recommended way to install Google Chrome extensions on macOS is to import a Plist with the `ExtensionInstallForcelist` key (`com.google.Chrome` payload) into a macOS Policy, just like the [Chrome homepage](https://docs.applivery.com/en/device-management/apple/macos/policies/google-chrome-homepage-configuration/). Applivery scripts help you verify the result or serve as an alternative when you can't use a Policy. ### Before you start - macOS Devices managed by Applivery, with Google Chrome installed. - The **extension ID**. - Access to the [Applivery Dashboard](https://dashboard.applivery.io/) with permission to edit Policies and, if you use scripts, the **Resources** section. ### How to get an extension's ID The ID is a string of 32 lowercase letters (from `a` to `p`) that uniquely identifies the extension. You can get it in three ways: 1. **From Chrome Web Store.** Open the extension's page and copy the last part of the URL: `https://chromewebstore.google.com/detail/extension-name/` 2. **From** `chrome://extensions`**.** Turn on **Developer mode** (top-right corner). Each installed extension shows its **ID** below the description. 3. **From Terminal on a Mac with the extension installed.** The folder names in this directory are the IDs: ```bash ls ~/Library/Application\ Support/Google/Chrome/Default/Extensions/ ``` If you use several Chrome profiles, replace `Default` with the profile name (for example, `Profile 1`). :::info For extensions hosted outside Chrome Web Store, you get the ID the same way, but in the Plist you must use your own server's update URL instead of `https://clients2.google.com/service/update2/crx`. ::: ### Recommended method: Policy with a Plist #### Prepare the Plist The following payload force-installs an extension. Replace `EXTENSION_ID` with your extension's ID: ``` PayloadContent ExtensionInstallForcelist EXTENSION_ID;https://clients2.google.com/service/update2/crx PayloadDisplayName Google Chrome - Extensions PayloadIdentifier com.google.Chrome.extensions.REPLACE-UUID PayloadType com.google.Chrome PayloadUUID REPLACE-UUID PayloadVersion 1 ``` Each list entry has the format `EXTENSION_ID;UPDATE_URL`. To install several extensions, add one `` per extension inside the same ``. ##### What to put in the REPLACE-UUID placeholders Replace each `REPLACE-UUID` with a UUID, a unique identifier with this format: `754C545B-75B5-4E50-927D-3BC06EBD47E0`. There are two places: - `PayloadUUID`: a full UUID. - `PayloadIdentifier`: `com.google.Chrome.extensions.` followed by a UUID. It can be the same as the `PayloadUUID` one or a different one. To generate one from Terminal on a Mac (each run returns a new one): ```bash uuidgen ``` For example, if `uuidgen` returns `A1B2C3D4-E5F6-4A7B-8C9D-0E1F2A3B4C5D`: ```xml PayloadIdentifier com.google.Chrome.extensions.A1B2C3D4-E5F6-4A7B-8C9D-0E1F2A3B4C5D PayloadUUID A1B2C3D4-E5F6-4A7B-8C9D-0E1F2A3B4C5D ``` Any UUID v4 generator works too. ##### When to generate a new UUID

Situation

UUID

Adding more extensions to the same Plist

They don't change: add another <string> to the <array>

Editing a Plist you've already imported

Keep the same UUIDs

Creating a different Plist (another Policy or another payload)

Generate new UUIDs, so two configurations don't share an identifier

You don't need a new Plist or UUID for every extension. :::warning Put **all** force-installed extensions in a single Plist and a single Policy. If you split the `ExtensionInstallForcelist` key across several configurations that apply to the same Device, Chrome isn't guaranteed to merge them, and only one of them may stay active. ::: #### Import it into an Applivery Policy **Open the Policy** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), go to any of your **Policies** 1 or [create a new one](https://docs.applivery.com/en/device-management/general-settings/create-policies/). **Import the Plist** Click the **\+ Add configuration** button on the left-hand menu, then click **\+ Import** 2. ![import](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/f3b41af3-190e-4361-9dfb-c0b1a568514a.png) Paste the Plist or use the **Upload XML** button to upload the file. ![plist](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/417c6f5d-ffc2-46b2-9108-07b0ffa2194a.png) **Save** Save your changes. #### Verify the result Once the Policy has synced to the Device, open Chrome and check: 1. `chrome://policy` → click **Reload policies** and confirm that `ExtensionInstallForcelist` appears with the **OK** status. 2. `chrome://extensions` → the extension should appear installed and marked as managed by your organization. :::info If Chrome was open when the Policy was applied, restart it to verify that the configuration has been applied. ::: ### Pin the extension to the toolbar A force-installed extension is available in Chrome's extensions menu (the puzzle icon), but it isn't pinned to the toolbar. To have it pinned from the start, use the `ExtensionSettings` key with the `toolbar_pin` option. `ExtensionSettings` groups all the settings for each extension in a dictionary, identified by its ID. It lets you force-install the extension and pin it to the toolbar in the same block, so it **replaces** `ExtensionInstallForcelist` for those extensions: ``` PayloadContent ExtensionSettings aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa installation_mode force_installed update_url https://clients2.google.com/service/update2/crx toolbar_pin force_pinned PayloadDisplayName Google Chrome - Extensions PayloadIdentifier com.google.Chrome.extensions.REPLACE-UUID PayloadType com.google.Chrome PayloadUUID REPLACE-UUID PayloadVersion 1 ```

Key

Value

Effect

installation_mode

force_installed

Force-installs the extension

update_url

Update URL

Same as in ExtensionInstallForcelist (the Chrome Web Store one, except for extensions hosted outside the store)

toolbar_pin

force_pinned

Pins the extension to the toolbar

To configure several extensions, add one key per ID inside the `ExtensionSettings` dictionary, each with its own ``. Import the Plist into the Policy just like with `ExtensionInstallForcelist`. :::warning Don't declare the same extension in both `ExtensionInstallForcelist` and `ExtensionSettings`. Pick one of the two keys for each extension. ::: :::info If you only want to install the extension and let each user decide whether to pin it, use `ExtensionInstallForcelist` and leave out `toolbar_pin`. ::: The extension ends up installed and pinned to the Google Chrome toolbar. ### Using scripts Applivery scripts (Bash on macOS) aren't needed to install the extension with the method above, but they're useful in two cases. You'll find more details in [Scripts](https://docs.applivery.com/en/device-management/apple/macos/scripts/). #### Verification script Checks that the Plist with the extension has reached the Mac. Pass the extension ID as an argument (in double quotes). ```bash #!/bin/bash ## Usage: the first argument is the Chrome extension ID EXT_ID="$1" PLIST="/Library/Managed Preferences/com.google.Chrome.plist" if [ -z "$EXT_ID" ]; then echo "Missing the extension ID as an argument." exit 2 fi if [ ! -f "$PLIST" ]; then echo "$PLIST does not exist: the Chrome configuration is not applied." exit 1 fi if /usr/libexec/PlistBuddy -c "Print :ExtensionInstallForcelist" "$PLIST" 2>/dev/null | grep -q "$EXT_ID"; then echo "OK: extension $EXT_ID is in ExtensionInstallForcelist." exit 0 else echo "Extension $EXT_ID is NOT in ExtensionInstallForcelist." exit 1 fi ``` #### Alternative script: install without a Policy (External Extensions) If you can't use a Plist, Chrome supports registering extensions externally through one JSON file per extension in a system path. This script creates it: ```bash #!/bin/bash ## Usage: the first argument is the Chrome extension ID EXT_ID="$1" DIR="/Library/Application Support/Google/Chrome/External Extensions" if ! [[ "$EXT_ID" =~ ^[a-p]{32}$ ]]; then echo "Invalid extension ID: $EXT_ID" exit 2 fi mkdir -p "$DIR" cat > "$DIR/$EXT_ID.json" <

Symptom

Possible cause

What to do

chrome://policy doesn't show ExtensionInstallForcelist

The Policy hasn't synced or Chrome hasn't been restarted

Check that the Device has the Policy assigned, force a sync and restart Chrome

The key shows an error

Misspelled ID or wrong entry format

Check that it's ID;URL and that the ID has 32 characters (a–p)

Only one of several extensions installs

Keys split across several configurations

Put all extensions in a single Plist

The verification script says the Plist doesn't exist

The configuration hasn't reached the Mac

Check the Policy assignment and the script's execution history

The extension appears but is disabled

External Extensions install waiting for user confirmation

Switch to the Policy method (Plist)

--- ## Local Account Automation Source: https://docs.applivery.com/en/device-management/apple/macos/policies/local-account-automation/ Description: Automate macOS local account creation during Apple DEP enrollment using Applivery. Streamline device provisioning with SSO integration. TL;DR: Automate macOS local account creation during DEP enrollment using Applivery's smart enrollment feature and SSO integration for streamlined device provisioning. Key topics: macOS Automation, Apple DEP Enrollment, SSO Integration, Apple DEP, Apple Business, Applivery, Single Sign-On :::info This feature is only available for macOS. ::: When enrolling Devices through the [Apple Device Enrollment Program (DEP)](https://docs.applivery.com/en/device-management/apple/enrollment/dep/), as part of the Apple Business integration, you can automate the creation of local user accounts during provisioning. Below, you can see how you can automate local account creation under the following use cases: - Pre-defined account configuration by the IT administrator. - Pre-filled account creation based on Single Sign-On information. - Automatic account creation based on Single Sign-On information. ### Configuring local accounts in Smart Enrollments The first step is to [create a new Smart Enrollment](https://docs.applivery.com/en/device-management/apple/enrollment/smart-enrollment/) and configure the **Account configuration**. ![account configuration](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/7a824a70-c0d1-4eb3-8cd7-25a9f0f862e8.png) During the automatic local account creation, you will be able to configure the **Admin account details** (including password) and **Primary account details**. The Primary Account will be created as an Admin Account by default unless it is _set as a standard account_ in the form. It can be locked so that the user cannot modify the data during Device configuration. :::warning By Apple’s design, the Primary Account password cannot be configured remotely. It must be set by the user during Device setup. ::: ### Using SSO user data in forms When integrating any Single Sign-On provider in Applivery, we will be able to retrieve from the Identity Provider directory some of the user data fields as variables so that you can use them to automatically fill out some fields, for instance, for automatic local account creation in Apple Device Management for MacOS. Below you can see the entire list of fields that will be accessible: - `{{sso.firstname}}`: User’s first name. - `{{sso.lastname}}`: User’s last name. - `{{sso.username}}`: User’s username. - `{{sso.email}}`: User’s full email address. - `{{sso.email.username}}`: User’s email address username. Note that you can combine the tags above to create complex structures such as the following one: `{{sso.firstname}}.{{sso.lastname}}` will be automatically translated to `john.doe` if `{{sso.firstname}}` contains the value `john` and `{{sso.lastname}}` contains the value `doe`. --- ## Remote Shutdown Policy Source: https://docs.applivery.com/en/device-management/apple/macos/policies/remote-shutdown-policy/ Description: Configure a macOS Remote Shutdown Policy in Applivery to ensure Devices shut down at defined times for improved security and energy efficiency. TL;DR: Configure a macOS shutdown policy in Applivery to schedule device shutdowns for improved security and energy efficiency. Key topics: Device Management, Policy Configuration, macOS, Applivery, Energy Saver Ensuring macOS Devices shut down properly at defined times or days is critical in environments where security, energy efficiency, and operational discipline are priorities. Whether it’s to prevent unauthorized access after hours, preserve battery health, or enforce company-wide power Policies, a controlled shutdown process is essential. With Applivery, you can remotely configure and deploy a Policy that initiates Device shutdown automatically. ### Configure a shutdown Policy **Navigate to Policies** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io), head to any of your **Policies** or [create a new one](https://docs.applivery.com/en/device-management/general-settings/create-policies/). From the left-hand menu, navigate to the **\+ Add configuration** section and then choose **Energy Saver**. ![energy saver](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/b9e56d22-57a7-456b-94af-8101726a5754.png) **Configure Desktop Power Schedule** Locate the **Desktop Power Schedule** and make the following configuration: - **Event Type**: In this case, select Shutdown. Other available options include Wake, Power On, Wake Power On, Sleep,  and Restart. - **Time**: The scheduled time, expressed in minutes since midnight. For example: `690 = 11:30 AM (11 x 60 + 30)`. - **Weekdays**: Defines the days when the shutdown applies, using a bitmask: - 1 = Monday. - 2 = Tuesday. - 4 = Wednesday. - 8 = Thursday. - 16 = Friday. - 32 = Saturday. - 64 = Sunday. You can combine values to select multiple days, for example, `1 + 2 + 4 + 8 + 16 = 31 → Monday to Friday` --- ## Reset Password Source: https://docs.applivery.com/en/device-management/apple/macos/policies/reset-password/ Description: Reset or change a Mac password using Applivery — via Apple ID, FileVault recovery key, or macOS Recovery on managed Devices. TL;DR: Learn how to reset or change your Mac password using methods like Apple ID, FileVault recovery, or macOS Recovery. Key topics: Changing macOS password, Resetting macOS password, FileVault recovery, macOS Recovery, Apple ID password reset, macOS, Apple ID, FileVault, Applivery, Apple Managing a fleet of macOS Devices often means dealing with password-related issues—whether it’s forgotten credentials, onboarding new users, or enforcing security Policies. Whether you’re supporting a single user or a large enterprise environment, these methods will help ensure secure and seamless access to macOS Devices under your management. There are two primary methods to update a password on a Mac: **changing** the password and **resetting** it. Each method has different implications depending on whether the original password is known: - **Change password**: If you still know the current password, this is always the preferred method. Changing the password can be done directly within the **System Settings** of the user account. This approach ensures that the **login keychain,** which stores saved passwords and secure items, remains intact and accessible. Since you’re updating the password while logged in, there’s no disruption to the user’s keychain or data. - **Reset password**: Resetting the password is a more drastic measure and should only be used when the original password is lost and cannot be recovered. When you reset a password, macOS is unable to unlock the original **login keychain**, which was encrypted with the previous password. As a result, a **new login chain** is created, and the user may lose access to saved passwords and other secure data unless they have a backup. :::info Your login password is the password you enter to unlock your Mac when you turn it on or wake it from sleep. It is not your Apple Account password, which gives you access to the iTunes Store, App Store, Apple Books, iCloud, and other Apple services. ::: ### Use a script to change the login password :::tip The **Applivery Agent App for macOS** must be enabled on the Device. You can learn more about the macOS Agent [here](https://docs.applivery.com/en/device-management/apple/apple-policies/agent/). ::: :::info To get started, learn how to create scripts by following [this link](https://docs.applivery.com/en/device-management/apple/macos/scripts/). ::: :::warning **Limitations** - Passwords cannot be reset for users who are blocked at the login window. - This procedure does not apply to accounts managed or created through [DEP](https://docs.applivery.com/en/device-management/apple/enrollment/dep/). ::: **Create your script** Copy and paste the following script into the editor, then adjust the necessary parameters: - **USER\_LOCAL**: Name of the user whose password you want to reset. - **NEW\_PASSWORD**: New password to assign to the user. - **USER\_ADMIN** and **ADMIN\_PASSWORD**: Credentials of a user with local administrative permissions. ``` #!/bin/bash USER_LOCAL="user" NEW_PASSWORD="NewPassword" USER_ADMIN="admin" ADMIN_PASSWORD="AdminPassword" sysadminctl -resetPasswordFor "$USER_LOCAL" -newPassword "$NEW_PASSWORD" -adminUser "$USER_ADMIN" -adminPassword "$ADMIN_PASSWORD" ``` **Assign script to a Policy** Next, go to any of your **Policies** and select the **Scripts** section from the left-hand menu. Click the **\+ Add Script** button. Next, choose the script, define the execution method, and add any required arguments. Depending on the selected method, the script can run automatically in **Loop** or **Once** mode, or be **manually triggered** from the **Actions** section of the Applivery Agent when set to **On-demand**. ![actions agent](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/2c295465-c383-47a2-ba75-540a06ba71f0.png) ### Change the login password To change your password on a Mac, start by clicking the **Apple menu**  and selecting **System Settings**. From there, scroll down the sidebar and click on **Users & Groups**. Once in the Users & Groups section, locate your username and click the **Info** (i) 1 button next to it. Then, select **Change** 2 to begin the password update process. ![change-user-password-1](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/7af4561c-94f0-4f39-b3aa-205422d3c324.png "change-user-password-1 | Applivery") You’ll be prompted to enter your current password in the **Old Password** field. Next, type your desired new password in the **New Password** field, and re-enter it in the **Verify** field to confirm. You’ll also be asked to provide a **password hint**—this will appear after three incorrect login attempts or if you click the question mark icon in the login window. Once everything is filled out, click **Change Password** to complete the update. ![change-user-password-2](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ff2c7c2e-0d5a-45c4-9b26-c9e44946271f.png "change-user-password-2 | Applivery") ### Reset Mac password with another Admin account If there’s an admin account on the Mac, resetting the password for the locked account is straightforward. This method is especially useful in shared-device environments where multiple users have administrative access. To reset the password, log in using the other admin account. Then, go to the **Apple menu** , open **System Settings,** and navigate to the **Users & Groups** section. In the bottom-left corner of the window, click the lock icon and enter your administrator password to make changes. Next, select the account that needs its password reset from the list on the left-hand side. In the right-hand pane, click **Reset Password**. A new window will appear where you can enter a new password, confirm it, and optionally add a password hint to help remember it later. Once you’ve filled out the necessary fields, click **Change Password** to complete the process. ### Reset Mac password using an Apple ID First, ensure that the Apple Account password reset option is enabled for the user. To do this, log in with an administrator account and open **System Settings**. Navigate to **Users & Groups**, then click the Info (i) button next to the desired user account. In the options that appear, enable the setting labeled **Allow user to reset password using Apple Account**. This will allow the user to recover their password using their Apple ID if needed. ![allow-user-to-reset-password](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/cea81c14-f7ac-4e3c-a23c-8a577be1fe82.png "allow-user-to-reset-password | Applivery") Start by powering on your Mac if it’s currently turned off. If your Mac is already on and you’re logged in, go to the **Apple menu**  and choose **Restart**. At the login screen, click your user account icon. The next steps will depend on your macOS version: - **On macOS Catalina and later**, a password field will appear with a question mark (?) icon on the far right. Click the question mark. A message will appear starting with: _“If you forgot your password, you can…”_ - **On macOS Mojave and earlier**, you’ll need to enter an incorrect password three times. After the third attempt, a similar prompt will appear. The message will continue: _“…reset it using your Apple ID.”_ Click the arrow next to **Restart** to begin the process. The Mac will reboot and open directly into Recovery Mode, displaying a pop-up window prompting the user to log in with their connected Apple ID. Enter the Apple ID credentials associated with the account. Once the credentials are accepted, Apple will send a multi-factor authentication (MFA) code to the user. Enter the code when prompted. After successful verification, a pop-up window titled **Reset Password** will appear, allowing you to select the user account you wish to reset. Enter a new password in the **New Password** and **Verify New Password** fields, then click **Next** to proceed. Finally, click **Restart** to complete the process. Once the Mac restarts, you can log in to the user account using the newly set password. ### Reset Mac password with FileVault Recovery Key FileVault is a disk encryption feature built into macOS that helps protect the data on your Mac by encrypting the entire startup disk. Once enabled, it ensures that only users with the correct login credentials or recovery key can access the Device’s contents, offering an added layer of security, especially important for lost or stolen Devices. Check out our [documentation](https://docs.applivery.com/en/device-management/apple/macos/policies/filevault/) for a step-by-step guide on enabling FileVault on macOS. ![macos-sequoia-login-window-password-entry](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/34925dfd-a856-45be-8ae4-3d32315e0dd5.png "macos-sequoia-login-window-password-entry | Applivery") Start by powering on your Mac if it’s currently turned off. If your Mac is already on and you’re logged in, go to the **Apple menu**  and choose **Restart**. The prompt will say: _“…reset it using your Recovery Key.”_ Click the arrow and enter the Recovery Key (without hyphens—macOS will insert them automatically). If the key is correct, your drive will be unlocked, and you can reset your password. You can find the Recovery Key in the [**Applivery Dashboard**](https://dashboard.applivery.io) by selecting the Device and navigating to **Settings > FileVault**. Click **Reveal** to display the key. ![recovery key](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/45c204ae-2c66-4346-b11a-0d0a84058e0a.png) If none of these options are available or successful, your next step should be to try using **macOS Recovery**. ### Reset Mac password through macOS Recovery If none of the previous methods work to reset your user’s password, you can try a more advanced option: using **macOS Recovery**. To enter macOS Recovery on a Mac with an Apple silicon processor, first make sure the Device is completely powered off. The screen should be black, and neither the Touch Bar nor the keyboard should be lit. Then, press and hold the power button. Keep holding it even after the Apple logo appears, until the Mac loads the startup options. Once you see the available screen options, release the power button. Next, click the **Options** icon and then click **Continue**. Wait for the progress bar to complete. While starting up from Recovery, you’ll be prompted to select a user account. If you don’t know the password for any listed user, click **Forgot all passwords?** to proceed with alternative recovery options. ![](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/8f2da57f-a571-43b3-9ae8-3c127bbd0458.png "forgot-all-passwords | Applivery") Follow the on-screen instructions, which will vary depending on how your Mac is configured. These prompts are designed to guide you through the recovery process based on your specific setup. Once you’ve provided the necessary information, you’ll be prompted to create a new password for your account. After setting the new password, click **Exit to Recovery**, restart your Mac, and log in using your updated credentials. If you’re unable to reset the password using these steps, you can continue troubleshooting while still in Recovery Mode. You’ll know you’re in Recovery when you see options like **Restore from Time Machine**, **Reinstall macOS**, and others. Follow the next steps to proceed from there. ![recovery-menu-options-restore-reinstall-safari-disk-utility](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/9c41d46d-e4c7-4546-9e21-db021d2a4466.png "recovery-menu-options-restore-reinstall-safari-disk-utility | Applivery") From the **Utilities** menu in the menu bar at the top of the screen, select **Terminal**. Alternatively, you can press **Shift + Command (⌘) + T** to open Terminal quickly. In the Terminal window that appears, type `resetpassword` and press **Return**. A new window will open, presenting you with reset options such as _“I forgot my password”_ or _“My password doesn’t work when logging in.”_ Select the appropriate option, then click **Next** and follow the on-screen instructions. Once you’ve provided the required information, you’ll be prompted to create a new password for your account, and optionally for other user accounts as well. After completing this step, restart your Mac and log in using your new password. ![](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/19313c8c-5a00-4c87-915c-092c0a7187cb.gif "resetpassword | Applivery") --- ## Safari Homepage Configuration Source: https://docs.applivery.com/en/device-management/apple/macos/policies/safari-homepage-configuration/ Description: Configure the Safari browser homepage on macOS Devices using a Plist file deployed via Applivery Device Management Policies. TL;DR: Configure Safari homepage on macOS using a Plist file imported into Applivery's device management policies. Key topics: Device Management, Browser Configuration, macOS Policies, Safari, Plist, Applivery Configuring the homepage allows IT admins to control the content displayed when users launch the browser. Use the following Plist to set a homepage URL for the Safari browser. Copy the contents from below and import them into the relevant macOS policy. ```html title="Safari Homepage Plist" PayloadContent HomePage https://www.applivery.com NewTabBehavior 1 NewWindowBehavior 0 PayloadDisplayName Safari PayloadIdentifier com.apple.Safari.5CF32BFB-0236-4247-BA28-B020EBB3DBFF PayloadType com.apple.Safari PayloadUUID 5CF32BFB-0236-4247-BA28-B020EBB3DBFF PayloadVersion 1 ``` Replace the home page URL with the URL that you would like to use in the above Payload. For example: ```xml HomePage https://www.applivery.io ``` Once in the [**Applivery Dashboard**](https://dashboard.applivery.io), go to any of your **Policies** 1 or [create a new one](https://docs.applivery.com/en/device-management/general-settings/create-policies/). Click the **\+ Add configuration** button on the left-hand menu, then click the **\+ Import** 2 button. ![import](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/7c94178b-e538-4189-88b0-68ae00016aee.png) You can either copy the Plist above or use the **Upload XML** button to upload a new one. ![payload](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/62849c4b-add0-4217-8524-4dee3fd04d52.png) :::info Restart Safari to verify that the configuration has been applied correctly. Ensure that additional settings, such as `NewTabBehavior` and `NewWindowBehavior`, are also properly configured. ::: --- ## Software License Agreement Source: https://docs.applivery.com/en/device-management/apple/macos/policies/software-license-agreement/ Description: Configure Software License Agreements (EULAs) for macOS Devices in Applivery — enforce acceptance before App access using Policies. TL;DR: Learn how to upload and configure software license agreements in Applivery to ensure users accept the terms before using the software. Key topics: Software Licensing, Policy Configuration, Device Management, Applivery, EULA, Software License Agreement Software license agreements vary in type, depending on the nature of the software and the manner in which it is licensed for use by third parties. As software is protected by copyright law, it must be licensed by the owner to authorize third parties to use it. Software may be distributed either directly by the developer or owner or indirectly through third-party distributors. An **End User License Agreement** (**EULA**) is a form of software license that grants an end user the right to use the software and defines the terms and conditions for its usage. EULAs are typically agreements between the software owner or developer (the licensor) and the individual or entity using the software (the licensee). ### Configuration **Upload the File** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io), head to the **Resources** 1 section. From the left-hand menu, select the **Books** 2 tab and click the **\+ Upload Book** 3 button. A modal view will appear, allowing you to upload files in `.pdf`, `.epub`, `.rtf`, `.rtfd` and `.txt` formats. ![books](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/87de1bc7-1273-4f42-ad04-8bb5d8615994.png) **Configure your Policy** After uploading the file, navigate to any of your **Policies** 4 or [create a new one](https://docs.applivery.com/en/device-management/general-settings/create-policies/). Select the **Resources** 5 section from the left-hand menu, and click the **\+ Add Resource** button. ![add book](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/2b42376e-3dd1-4551-bab3-955644adf52a.png) In the modal view, switch to the **Book** tab, where you can either select the file you uploaded earlier or upload a new one. Next, set the scope to **System**. The path to define must be `/Library/Security/{assetName}.rtfd`. ![policy book](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/6eaa9674-8565-49c9-9204-c21a896e3feb.png) **Log in on the Device** When the user attempts to log in on the Device, a new window will open showing the document. The login process will be blocked until the user accepts the terms. Only after agreeing to the terms will they be able to proceed with the login. --- ## Update User Passwords Source: https://docs.applivery.com/en/device-management/apple/macos/policies/update-user-passwords/ Description: Remotely update macOS User passwords using Applivery MDM Scripts for consistent configuration and improved Device security. TL;DR: Use Applivery to remotely update macOS user passwords via scripts assigned to policies. Key topics: macOS Management, Mobile Device Management, Security, Applivery, macOS, Script, Policy Effective password management is essential for maintaining security and operational efficiency in corporate macOS environments. Using Applivery, IT teams can remotely update user passwords across all managed Mac Devices, ensuring consistent configuration, improved compliance, and reduced manual workload. :::warning The **Applivery Agent App for macOS** must be enabled on the Device. You can learn more about the macOS Agent [here](https://docs.applivery.com/en/device-management/apple/apple-policies/agent/). ::: **Create your script** To begin, learn how to create scripts by following [this link](https://docs.applivery.com/en/device-management/apple/macos/scripts/). Assign a descriptive name to the script and copy and paste the following script into the editor, then adjust the necessary parameters: - **USERNAME** (`user`): Enter the macOS account username whose password you want to update. - **NEWPASSWORD** (`new_password`): Set the new password for the specified user. ``` #!/bin/bash ## Define the username and the new password USERNAME="username" # Replace 'username' with the actual username NEWPASSWORD="new_password" # Replace 'new_password' with the desired password ## Change the user's password using dscl dscl . -passwd /Users/"$USERNAME" "$NEWPASSWORD" ## Check if the change was successful if [ $? -eq 0 ]; then echo "The password for user $USERNAME has been successfully changed." else echo "There was an error trying to change the password for user $USERNAME." fi ``` **Assign the script to a Policy** Next, go to any of your **Policies** 1 or [create a new one](https://docs.applivery.com/en/device-management/general-settings/create-policies/). Select the **Scripts** 2 section from the left-hand menu and click the **\+ Add Script** 3 button. ![policy script](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/d2d8cf0a-9084-49c6-84f6-555523c63c9a.png) Next, select the script, choose the execution method, and add any required arguments. Depending on the selected execution method, the script will run automatically in **Loop,** or **Once** mode, or it can be **manually triggered** from the **Actions** section within the Applivery Agent when configured as **On-demand**. ![add script to policy](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/daf8b8d1-d906-4e7b-b81e-956a2767b663.png) Regularly updating user passwords is a critical cybersecurity practice. Automating this task through Applivery ensures fast, secure, and consistent credential updates, reducing risks associated with outdated passwords and keeping all macOS Devices aligned with corporate security standards. --- ## Wallpaper Configuration Source: https://docs.applivery.com/en/device-management/apple/macos/policies/wallpaper-configuration/ Description: Configure macOS wallpaper on managed Devices using Applivery MDM Policies to enforce corporate branding and lock wallpaper settings. TL;DR: Configure macOS wallpaper via MDM to enforce corporate branding on managed devices, ensuring a consistent look and feel across the organization. Key topics: macOS wallpaper configuration, MDM policy management, Corporate branding, Device management, Applivery, macOS, MDM, JPG, PNG Customizing the desktop wallpaper is often seen as a way to reinforce corporate branding on Devices managed by the organization. macOS wallpaper settings allow businesses to ensure that every company-owned Device displays the enterprise’s logo or trademark. Administrators can configure the wallpaper with the organization’s logo or any image they choose and apply it to an entire fleet of Devices. This customization also allows them to set wallpapers for all users on a Device and decide if they should be updated periodically. ### Policy configuration **Upload the image** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io), head to the **Resources** section 1. Then, go to the **Images** 2 tab and click the **\+ Upload Image** 3 button. A modal view will appear, allowing you to upload images in `.jpg` and `.png` formats. ![upload image](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/47f23af5-4689-4678-a74e-604f746a7d78.png) **Configure your Policy** After uploading the image, navigate to any of your **Policies** 4 or [create a new one](https://docs.applivery.com/en/device-management/general-settings/create-policies/). Head to the **Resources** 5 section from the left-hand menu, and click the **\+ Add Resource** button. In the modal, go to the **Image 6** tab. Here, you can either select an image you uploaded earlier or upload a new one. Then, choose the scope: **Primary user**, **All users**, or **System**. Click the **Use recommended location** 7 button for a suggested configuration. ![add image to policy](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ef11ca2b-7bca-4c33-b8da-ed3dc1b33ab4.png) :::info We recommend applying the configuration to **All users** and using the default path to ensure the wallpaper is consistently applied across the entire system. ::: Once the image is uploaded, click the + **Add configuration** button in the left-hand menu and select **Desktop** from the available configuration options. You only need to add the path you set when uploading the image (whether you used the recommended path or created one manually). ![desktop](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/4492929d-e164-4490-9e90-75eee58aa5b9.png) Additionally, you can enable the **Locked** setting to prevent users from changing the wallpaper. Once configured, you will only need to **Save changes.** ![desktop configuration](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/acb81c96-8182-46a1-82c5-a67c71f23ac9.png) ### What happens on the Device? After the Policy is applied, the wallpaper on the macOS Device will update based on the configurations you set. All users on the Device will see the new wallpaper, and if the option is locked, they won’t be able to change it. This ensures that all managed Devices maintain a consistent appearance in line with your corporate identity. --- ## Remote Support Source: https://docs.applivery.com/en/device-management/apple/macos/remote-support/ Description: Remote Support for managed macOS Devices in Applivery — connect to a Mac through TeamViewer without leaving the Dashboard. TL;DR: Enable TeamViewer Remote in a macOS Policy and connect to any Mac in that Policy from its Action menu — no TeamViewer setup on the Device itself. Key topics: macOS Remote Support, TeamViewer integration, Remote sessions, Applivery, macOS, TeamViewer Remote Support lets you connect to a managed Mac straight from the Applivery Dashboard — to see what the person in front of it sees, walk them through something, or fix it yourself while nobody is there. On macOS, Remote Support runs on **TeamViewer**. You enable it once in a Policy, Applivery silently installs the TeamViewer Host app and the profiles it needs on every Mac that Policy applies to, and from then on you start sessions from the Device's **Action** menu. There is no TeamViewer setup on the Device itself, and nothing for the person using it to install. :::warning This is a premium feature that may not be available on your current plan. Check availability on the [Applivery pricing page](https://www.applivery.com/device-management-pricing/). ::: --- ## TeamViewer Remote Support Source: https://docs.applivery.com/en/device-management/apple/macos/remote-support/teamviewer-remote-support/ Description: Enable TeamViewer Remote Support for macOS Devices in Applivery — silent install, macOS permissions, session types, licensing, and troubleshooting. TL;DR: Enable TeamViewer Remote in a macOS Policy, let Applivery install TeamViewer Host and its profiles, make sure Screen & Audio Recording is granted, then start sessions from the Device's Action menu. Key topics: Enabling TeamViewer Remote in a macOS Policy, Silent installation of TeamViewer Host, macOS profiles and permissions (Remote Desktop, Accessibility, Screen & Audio Recording), Session types and licensing, Troubleshooting remote sessions, Applivery, TeamViewer, macOS :::warning This is a premium feature that may not be available on your current plan. Check availability on the [Applivery pricing page](https://www.applivery.com/device-management-pricing/). ::: Enabling **TeamViewer Remote** in a macOS Policy makes Applivery silently install the TeamViewer Host app on every Mac that Policy applies to, apply the profiles it needs, and register those Devices with TeamViewer. From then on, you start a remote session from the Device's **Action** menu — no TeamViewer setup on the Device itself, and nothing for the person using it to install beforehand. :::info Looking for Windows? Check out [TeamViewer Remote Support for Windows](https://docs.applivery.com/en/device-management/windows/remote-support/teamviewer-remote-support/). ::: ### Before you start On macOS, TeamViewer Host needs a few system permissions before it can show and control the screen. Applivery takes care of most of them for you, but one has to be granted on the Mac itself:

Layer

What it does

Who takes care of it

TeamViewer configuration profile

Configures TeamViewer Host and registers the Device for remote sessions

Applivery — applied when the Policy is set to Enabled, removed when it is set to Disabled

Apple permissions profile

Grants TeamViewer Host the Remote Desktop and Accessibility permissions it needs to control the Mac

Applivery — applied when the Policy is set to Enabled

Screen & Audio Recording

macOS privacy permission that lets TeamViewer Host share the screen during a session

The person using the Mac — no admin rights required

#### Screen & Audio Recording This permission is separate from the Apple permissions profile and has to be approved on the Mac, but the person using it can do it without admin rights. Until it's granted, sessions may fail to start. If they dismissed the prompt, or it never showed up, ask them to: 1. Open **System Settings** → **Privacy & Security** → **Screen & Audio Recording**. 2. Turn on the toggle next to **TeamViewer Host**. ### Enabling TeamViewer Remote **Open the Policy** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), go to **Policies** 1 and open the macOS Policy you want to enable Remote Support on. **Go to the TeamViewer Remote section** In the left-hand menu, select the **TeamViewer Remote** section and find the **TeamViewer Remote** configuration 2. **Set it to Enabled** Choose **Enabled** and save your changes. Every Device that Policy applies to will now get TeamViewer Host and its profiles installed automatically. ![macos remote support](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/f5582302-f09a-4bda-b362-cf8786d228e8.png) #### The three configuration states TeamViewer Remote uses the **Not configured / Enabled / Disabled** pattern. This matters because a Device can have [more than one Policy applied to it](https://docs.applivery.com/en/device-management/general-settings/policy-composition/): what actually reaches the Device is the composed result of every Policy in its set, not the value of any single one. So each state is really what _this_ Policy contributes to that composition:

State

What this Policy contributes

Enabled

Turns TeamViewer Remote on. TeamViewer Host is installed, the TeamViewer configuration profile and the Apple permissions profile are applied, the Device is registered with TeamViewer, and it takes a license from your pool

Disabled

Turns TeamViewer Remote off. Any Device that ends up without it active is deregistered from TeamViewer, the TeamViewer configuration profile is removed, and its license is released back to the pool

Not configured

Contributes nothing. This Policy stays out of the decision, and the result comes from the other Policies in the set

#### Which Policy wins Policies are evaluated **sequentially**, in the order set by their Priority in the composition. The first Policy that actually sets a value decides the outcome — `Not configured` is skipped over, and no later Policy overrides a value that has already been set. Neither `Enabled` nor `Disabled` beats the other, in other words: **order is what decides**. Here it is on a Device with two Policies, where Policy 1 is evaluated first:

Policy 1

Policy 2

Composed result

Not configured

Enabled

Enabled — Policy 1 sets nothing, so Policy 2 decides

Disabled

Enabled

Not active — Policy 1 got there first, and Policy 2 doesn't override it

Enabled

Disabled

Enabled — the same rule the other way round: Policy 1 got there first

Use **Not configured** when a Policy has no business deciding about Remote Support — one that only deploys apps, for example. Use **Disabled** when you want a Policy to actively keep Remote Support off, and check that it is evaluated **before** any Policy that enables it, or it won't have any effect. #### Automatic installation Applivery deploys TeamViewer Host silently as a `.pkg` — the person using the Mac doesn't have to install anything. Along with the app, Applivery applies the TeamViewer configuration profile and the Apple permissions profile (Remote Desktop and Accessibility) described in [Before you start](#before-you-start). The Device shows up as **Ready** once TeamViewer Host is installed and configured. Remember that **Screen & Audio Recording** still has to be granted on the Mac for sessions to share the screen. #### How licenses are counted Each Device with TeamViewer Remote active in its composed configuration uses one TeamViewer license from your plan, **whether or not anyone ever actually connects to it**. What counts is the number of Devices with the feature active, not the number of sessions you open. The moment a Device stops having TeamViewer Remote active through its Policies, it is **unregistered from TeamViewer and its license is released** automatically. How the composition changed doesn't matter: setting a Policy to **Disabled**, removing the Policy that was enabling it, or moving the Device elsewhere all have the same effect. ### Starting a remote session **Open the Device** Navigate to any of your macOS **Devices** and click the **Action** button 1. Then select **TeamViewer Remote** 2. ![teamviewer device](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/a6fadbdf-d770-45aa-8c39-7d5d773dd9c7.png) **Pick how you want to connect** The **TeamViewer Remote Support** modal opens. Choose the **Control Type** and the **Open With** option for this session 3. ![teamviewer modal](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/675d0335-dc73-4e80-b4ce-a356193f9497.png) **Start the session** Click **Start remote session**. If you chose **TeamViewer client**, the session is handed off to the TeamViewer desktop app on your machine, which connects to the Device. You don't fix a session type when enabling the Policy — every option is available every time, and you pick per session:

Setting

Options

Control Type

Unattended — connects without anyone accepting on the Device, for machines with nobody in front of them. Attended — someone at the Device has to accept the incoming session. View only — someone at the Device also has to accept, and you see the screen without any keyboard or mouse input being sent

Open With

New browser tab — runs on TeamViewer's web client, nothing to install on your machine. TeamViewer client — hands the session to the TeamViewer desktop app, with its full set of features

You can change your selection as many times as you like before clicking **Start remote session** — the value showing when you click is the one that gets used. #### What you can do during a session Once connected, the features available depend on the **Control Type** and **Open With** option you chose, and on what the TeamViewer client supports for that session. On the managed Mac itself, TeamViewer Host shows up installed alongside the Applivery Agent (if the Device has it) — put there by the automatic installation described above. ### Troubleshooting The **TeamViewer Remote Support** modal shows a status badge next to the Device, so you can tell at a glance whether a session can start. Hover the ⓘ icon next to the badge for a short explanation. #### Ready TeamViewer Host is installed and configured on the Device. You can start a session. #### Not enabled in policy The Device's composed Policies don't have TeamViewer Remote set to **Enabled**. Go back to [Enabling TeamViewer Remote](#enabling-teamviewer-remote) and confirm you're editing the Policy that Device is actually assigned to. ![not enabled](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/36b99cc1-2f9c-4d14-8888-d413e11339e9.png) #### App not installed The Policy is enabled, but TeamViewer Host hasn't finished installing on that Device yet — or couldn't. Since the install is silent, wait and retry first. If it persists, check that the TeamViewer configuration profile and the Apple permissions profile have been applied to the Device (see [Before you start](#before-you-start)). Starting a session against a Device in this state fails, whichever Control Type or Open With option you pick. #### The session fails to start on a Ready Device TeamViewer Host is installed, but the session doesn't start properly or the person at the Mac sees a recording prompt. This usually means **Screen & Audio Recording** hasn't been granted yet. Ask them to turn it on for **TeamViewer Host** in **System Settings** → **Privacy & Security** → **Screen & Audio Recording** — they don't need admin rights to do it. If remote control still doesn't work, check that the Apple permissions profile (Remote Desktop and Accessibility) is present on the Device. If the Policy is enabled but the profile is missing, wait for it to finish applying and try again. #### The Device goes offline mid-session If the Device disconnects right after you click **Start remote session**, the remote session window closes on its own. Wait for the Device to come back online and start a new session. #### Nothing seems to happen when I click Start remote session Give it a moment before clicking again — double-clicking **Start remote session** won't open two sessions, so a second click doesn't speed anything up. --- ## Scripts Source: https://docs.applivery.com/en/device-management/apple/macos/scripts/ Description: Automate tasks on macOS managed Devices using Scripts in Applivery — create, assign, and manage Scripts for efficient Device Management. TL;DR: Automate repetitive tasks on managed devices using scripts in Applivery for efficient device management. Key topics: device management, automation, scripting, Applivery, MDM, IT administrators A computer Script is essentially a sequence of instructions (commands) that the computer executes, making it an excellent tool for automating repetitive tasks. Scripts are highly scalable and versatile. Because Scripts can be deployed to user Devices through Device Management solutions (such as Applivery), they are invaluable for IT teams. They enable you to perform complex tasks quickly, accurately, and effortlessly: - **Quickly**: By using Scripts alongside Mobile Device Management, you can automate tedious processes. For example, you can access a computer program on 100 company Devices with zero clicks instead of doing it manually 100 times. - **Accurately**: A well-written Script will consistently execute the same defined action every time, reducing the risk of errors that might occur if a human administrator were to perform the task manually, which can lead to inconsistencies and confusion. - **Easily**: You can achieve complex and detailed tasks by breaking them down into smaller, manageable Scripts, making the overall process much simpler. **Create your first Script** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), go to the **Resources** 1 section, then navigate to the **Scripts** 2 section from the left-hand menu and click **\+ Create Script** 3. ![add script](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/7e25d712-6411-469b-8b27-cd63db3d3152.png) A code editor will appear on the screen. Within the editor, you can either create a new Script or upload an existing one from your Device, allowing you to easily tailor Scripts to your needs. To create a new Script, use the editor interface and start typing. First, select the desired language—**Bash** 4 in this case. To upload an existing Script, click **Load from file** 5, select your Script, and it will be ready to use. Finally, provide a **Name** 6 (and optionally a description), then click **Create** 7. ![create macos scripts](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/44bcbef3-e542-4ccb-9fef-2eef0b5d8c4f.png) :::info If you need help creating a Script, you can also use our **AI Assistant**. Just click the corresponding button, and a dialog box will appear where you can describe the Script you need. Our assistant will then generate it for you. ::: :::warning AI Assistant is a premium feature that might not be available in your current plan. Check the availability on our [pricing page.](https://www.applivery.com/device-management-pricing/) ::: **Assign Scripts to your Devices** Now, navigate to any of your **Devices**, select the **Scripts** 8 tab, and click on the **\+ Assign Script** 9 button. ![script device assignment](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/36316de5-af93-4600-ac22-6b1fcb76c6b4.png) A modal view will appear, allowing you to choose a Script from the Script section or upload it from your Device. You will also have the option to select the execution method and add the Script’s arguments: - **Once**: The Script will run once per Device. You will also have the option to repeat the execution, even if it has already been executed. - **Loop**: The Script will run cyclically at the chosen time interval. - **On-demand**: The Script will never be run automatically and will only be offered as an optional item from Self-Service. Below, you can find the complete list of mustache tag interpolations for the Script arguments. Please note that each argument needs to be separated by **double quotation** marks (**“”**): - “`{{device.id}}`“. - “`{{device.displayName}}`“. - “`{{device.serialNumber}}`“. - “`{{device.osVersion}}`“. - “`{{device.chip}}`“. - “`{{device.isAppleSilicon}}`“. - “`{{device.hostName}}`“. - “`{{user.id}}`“. - “`{{user.email}}`“. - “`{{user.name}}`“. ![script form](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/7dab607d-f8e2-45f2-8d51-66fd4af7777b.png) By clicking the **Execution history button** 10, you can view the execution history of all your Scripts. You can also access the execution history of a specific Script by clicking on the Script itself or the three vertical dots at the end of the Script. Clicking these dots will also display additional actions: - **Edit**: Edit the Script. - **Unassign**: Unassign the Script from the Device. - **View**: View the original Script in the asset section. :::warning For Scripts with the **Once** execution method, you will also see the **Repeat execution** option. In addition to allowing a Script to be retried after a failure, this option also determines whether a Script with the same ID can be executed again on a Device where it has already run, even if that execution took place in the past. This ensures that the Script will be sent again, regardless of its prior execution history on that Device. ::: ![execution history](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/902159c0-f7f6-4fcb-94d5-790ddd4ba32a.png) **Assign Scripts to your Policies** Scripts don't have to be assigned Device by Device. Assigning one to a Policy covers every Device that Policy applies to, which is the practical route for anything meant to run across a fleet rather than on a single machine. From any of your **Policies** 11, go to the **Scripts** 12 section in the left-side menu and click **\+ Add Script** 13. The same modal described in the previous step appears, with the same execution methods and arguments. ![assign to policy](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/3b3ad093-d7ad-4b3d-be61-c35430a8637a.png) Once you save the changes, the Scripts assigned to that Policy are deployed to every Device carrying it on their next sync. ### Do It Yourself! To help administrators accelerate common configurations and operational tasks, Applivery provides a [Public Script Repository](https://github.com/applivery/applivery-mdm-scripts) containing ready-to-use macOS Scripts. This repository includes useful Scripts for quick actions and standard configurations, allowing IT teams to deploy common solutions without having to build Scripts from scratch. The goal of this initiative is **not only to provide reusable resources, but also to encourage collaboration**. The community can actively contribute by submitting Scripts that address real-world use cases, helping expand and improve the shared library over time. By leveraging the **Public Script Repository**, organizations can reduce implementation time, standardize operational procedures, and benefit from collective expertise. --- ## Delete Local User Account Source: https://docs.applivery.com/en/device-management/apple/macos/scripts/delete-local-user/ Description: A macOS bash script that fully removes a local user account by deleting the Directory Services record, home directory, and group entry. Ideal for offboarding. TL;DR: Automate repetitive tasks on managed devices using scripts in Applivery for efficient device management. Key topics: device management, automation, scripting, Applivery, MDM, IT administrators Properly deleting a user account on macOS involves more than clicking "Delete User" in System Settings. That approach can leave behind home directory data, Directory Services records, and orphaned group entries that accumulate over time. This Script goes further: it removes the user record from Directory Services, wipes the home directory from disk (`/Users/username`), and cleans up the associated group entry — a complete, irreversible removal that leaves no residual data on the machine. It's designed for offboarding flows where a clean slate matters. :::warning The Applivery Agent for macOS must be installed and active on the Device. Learn more about the [macOS Agent](https://docs.applivery.com/en/device-management/apple/apple-policies/agent/#agent-app-for-macos-devices). ::: ### Requirements | Requirement | Detail | | --- | --- | | Platform | macOS | | Execution privileges | Root (default in Applivery) | | Username | The short name of the account to delete, passed as an argument | :::warning This action is irreversible. Once the home directory is deleted, the user's data cannot be recovered unless a backup exists. Always verify the username before deploying. ::: * * * ### Setup **Create the Script** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), follow the steps described [here](https://docs.applivery.com/en/device-management/apple/macos/scripts/index) to create a Script. Paste the following Script into the editor, select **Bash** as the language, give it a descriptive name (e.g., `Delete Local User Account`), and click **Create**. ```bash #!/bin/bash ## --- ## Title: Delete Local User & Home Directory ## Description: Completely removes a local user account, its home directory, and its group record. ## Author: Applivery ## Version: 1.0.0 ## --- ## ========================================== ## CONFIGURATION ## ========================================== ## The username can be passed as an argument ($1) or hardcoded below USER_NAME=$1 ## ========================================== ## 1. INITIAL CHECKS ## ========================================== if [[ $EUID -ne 0 ]]; then echo "Error: This script must be run as root." exit 1 fi if [ -z "$USER_NAME" ]; then echo "Error: No username provided. Usage: $0 " exit 1 fi CURRENT_USER=$(stat -f "%Su" /dev/console) if [ "$USER_NAME" == "$CURRENT_USER" ]; then echo "Error: Cannot delete the currently logged-in user ($USER_NAME)." exit 1 fi id "$USER_NAME" &>/dev/null if [ $? -ne 0 ]; then echo "Error: User '$USER_NAME' does not exist." exit 1 fi ## ========================================== ## 2. DELETION PROCESS ## ========================================== echo "Starting deletion process for user: $USER_NAME..." dscl . -delete "/Users/$USER_NAME" if [ $? -eq 0 ]; then echo "[SUCCESS] User record removed from Directory Services." else echo "[FAILURE] Failed to remove user record." exit 1 fi if [ -d "/Users/$USER_NAME" ]; then rm -rf "/Users/$USER_NAME" echo "[SUCCESS] Home directory /Users/$USER_NAME has been deleted." else echo "[INFO] No home directory found at /Users/$USER_NAME." fi dscl . -delete "/Groups/$USER_NAME" &>/dev/null echo "Process complete. User '$USER_NAME' has been fully removed." exit 0 ``` **Assign the Script to a Device** Now, navigate to any of your **Devices**, select the **Scripts** tab, click on the **\+ Assign Script** button, and select the one you just created. :::info You can also assign Scripts to Policies. To do this, navigate to the **Policies** section, select the desired Policy, and click on the **Scripts** tab. The process will be the same as when assigning it directly to an individual Device. ::: **Choose the execution method** Select the execution method that matches your use case: | Method | Behaviour | Recommended? | | --- | --- | --- | | **Once** | Runs one time per Device when the Policy is assigned. | ✅ Recommended — account deletion is a one-time offboarding action. | | **Loop** | Runs repeatedly at the configured interval (15m, 1h, 6h, 1d, 7d). | ❌ Not recommended — deletion is irreversible and should not be repeated. | | **On demand** | Only runs when manually triggered from the Applivery Self-Service App or the dashboard. | ✅ Also suitable for ad-hoc offboarding initiated by IT. | **Enter the username as an argument** The Script requires the short name of the account to delete. Enter it in the **Arguments** field (e.g., `jsmith`). The field also supports [variable interpolations](https://docs.applivery.com/en/device-management/general-settings/dynamic-variables/), such as `{{device.displayName}}`. Click **Add** to save the assignment. :::tip As an alternative to using the Arguments field, you can hardcode the username directly in the Script by replacing `USER_NAME=$1` with `USER_NAME="the_username"`. This is useful when you need to delete the same account across an entire fleet of Devices. ::: * * * ### Available on GitHub This Script is part of the [Applivery Public Script Repository](https://github.com/applivery/applivery-mdm-scripts/tree/main/Apple/Delete%20Admin%20User) — a collection of ready-to-use macOS Scripts for common IT management tasks. You can use it as-is or adapt it to your specific offboarding workflow. --- ## Force Reboot Policy (Uptime Enforcement) Source: https://docs.applivery.com/en/device-management/apple/macos/scripts/force-reboot/ Description: macOS script that monitors uptime and escalates swiftDialog alerts to enforce reboots, with a forced 10-minute countdown after 13+ days without a restart. TL;DR: Automate repetitive tasks on managed devices using scripts in Applivery for efficient device management. Key topics: device management, automation, scripting, Applivery, MDM, IT administrators Security patches only take effect after a reboot. In practice, users postpone restarts indefinitely — and the longer a Device runs without rebooting, the more security updates accumulate in a pending state. Machines that have been on for weeks also tend to show degraded performance and memory pressure that a simple restart would resolve. The problem with forcing a reboot with an abrupt shutdown is that it causes interruptions and frustration. This Script takes a more gradual approach: it monitors uptime and escalates progressively, starting with a discreet notification and only forcing a countdown when the Device has been running for 13 or more days. Users get enough warning to save their work; IT gets the assurance that reboots actually happen. Alerts are displayed using swiftDialog (installed automatically if not present) with your company's branding, so users recognize them as legitimate IT communications. :::warning The Applivery Agent for macOS must be installed and active on the Device. Learn more about the [macOS Agent](https://docs.applivery.com/en/device-management/apple/apple-policies/agent/#agent-app-for-macos-devices). ::: ### Requirements | Requirement | Detail | |---|---| | Platform | macOS 11.0 (Big Sur) or later | | Execution privileges | Root (default in Applivery) | | Corporate branding | `/var/root/CompanyAssets/logo.png` (optional, for branded dialogs) | | swiftDialog | Installed automatically if not already present | --- ### Escalation levels The Script calculates the current system uptime in days and applies a four-level escalation policy: | Uptime | Action | |---|---| | 0–4 days | No action | | 5–8 days | macOS toast notification with an audible alert | | 9–12 days | Dialog window with **Restart now** and **Postpone** (24h) options. Closes automatically after 14 minutes | | 13+ days | Full-screen warning followed by a 10-minute countdown. The Mac restarts when the timer reaches zero, or the user clicks **Restart now** | --- ### Setup **Deploy your company logo (optional)** Before deploying this Script, make sure your company logo is available at `/var/root/CompanyAssets/logo.png` on each managed Device. The Script resizes and copies the logo to the swiftDialog resources folder automatically. Using the corporate logo ensures users recognize the alerts as IT communications and don't dismiss them as noise. You can distribute the file using [Applivery File Management](https://docs.applivery.com/en/device-management/apple/macos/policies/file-management/). **Create the Script** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), follow the steps described [here](https://docs.applivery.com/en/device-management/apple/macos/scripts/index) to create a Script. Paste the following Script into the editor, select **Bash** as the language, give it a descriptive name (e.g., `Force Reboot Policy`), and click **Create**. ```bash #!/bin/bash ## --- ## Title: Force Reboot Policy (Uptime Enforcement) ## Description: Monitors macOS uptime and triggers escalating alerts via swiftDialog to force a restart. ## Author: Applivery ## Version: 1.2.0 ## --- ## ========================================== ## 1. CLEANUP OLD INSTALLATIONS ## ========================================== DIALOG_OLD="/Applications/Dialog.app" if [ -d "$DIALOG_OLD" ]; then echo "→ Old Dialog.app found" pgrep -if "Dialog.app" && { echo " → Quitting Dialog..." pkill -if "Dialog.app" 2>/dev/null sleep 1 } if sudo rm -rf "$DIALOG_OLD" 2>/dev/null; then echo " → Removed successfully" else echo " → Failed to remove legacy app." fi else echo "→ No old Dialog.app present" fi ## ========================================== ## 2. PRE-FLIGHT & BRANDING SETUP ## ========================================== PATH=/usr/bin:/bin:/usr/sbin:/sbin DIALOG_CLI="/usr/local/bin/dialog" DIALOG_APP="/Library/Application Support/Dialog/Dialog.app" DIALOG_ICON_DIR="/Library/Application Support/Dialog" DIALOG_ICON="$DIALOG_ICON_DIR/Dialog.png" BRAND_ICON="/var/root/CompanyAssets/logo.png" needs_install=0 needs_reinstall=0 CURRENT_USER=$(stat -f %Su /dev/console) USER_ID=$(id -u "$CURRENT_USER" 2>/dev/null || true) get_swiftdialog_pkg_url() { local url url="$(/usr/bin/curl -fsSL -H "Accept: application/vnd.github+json" -H "User-Agent: Force_Reboot" \ "https://api.github.com/repos/swiftDialog/swiftDialog/releases/latest" | \ /usr/bin/sed -nE 's/.*"browser_download_url":"([^"]*\.pkg)".*/\1/p' | \ /usr/bin/head -n 1)" [ -n "$url" ] && echo "$url" && return 0 return 1 } run_as_user() { if [ -z "$CURRENT_USER" ] || [ "$CURRENT_USER" = "loginwindow" ] || [ -z "$USER_ID" ]; then return 1 fi launchctl asuser "$USER_ID" /usr/bin/sudo -u "$CURRENT_USER" -- "$@" } if [ ! -x "$DIALOG_CLI" ] || [ ! -d "$DIALOG_APP" ]; then needs_install=1 fi mkdir -p "$DIALOG_ICON_DIR" chmod 755 "$DIALOG_ICON_DIR" if [ -f "$BRAND_ICON" ]; then tmp_brand="$(/usr/bin/mktemp /tmp/dialog_brand.XXXXXX.png)" if ! sips -z 512 512 "$BRAND_ICON" --out "$tmp_brand" >/dev/null 2>&1; then /bin/cp "$BRAND_ICON" "$tmp_brand" fi if [ -f "$tmp_brand" ]; then if [ ! -f "$DIALOG_ICON" ] || ! cmp -s "$tmp_brand" "$DIALOG_ICON"; then cp "$tmp_brand" "$DIALOG_ICON" chmod 644 "$DIALOG_ICON" chown root:wheel "$DIALOG_ICON" >/dev/null 2>&1 needs_reinstall=1 fi fi rm -f "$tmp_brand" fi ## ========================================== ## 3. SWIFTDIALOG INSTALLATION ## ========================================== if [ "$needs_install" -eq 1 ] || [ "$needs_reinstall" -eq 1 ]; then pkg_url="$(get_swiftdialog_pkg_url 2>/dev/null || true)" if [ -n "$pkg_url" ]; then pkg_path="/tmp/swiftDialog_$(date +%s).pkg" /usr/bin/curl -fL --retry 3 --retry-delay 1 "$pkg_url" -o "$pkg_path" installer -pkg "$pkg_path" -target / rm -f "$pkg_path" else echo "ERROR: Could not retrieve swiftDialog URL." >&2 exit 1 fi fi killall Dialog 2>/dev/null ## ========================================== ## 4. UPTIME CALCULATION ## ========================================== current_unix_time="$(date '+%s')" boot_time_unix="$(sysctl -n kern.boottime | awk -F 'sec = |, usec' '{ print $2; exit }')" uptime_seconds="$(( current_unix_time - boot_time_unix ))" uptime_days="$(( uptime_seconds / 86400 ))" ## TEST_UPTIME_DAYS="7" # Uncomment for testing if [ -n "$TEST_UPTIME_DAYS" ]; then uptime_days="$TEST_UPTIME_DAYS" fi ## ========================================== ## 5. ESCALATION LOGIC ## ========================================== if [ "$uptime_days" -le 4 ]; then echo "Uptime: $uptime_days days. No action needed." exit 0 elif [ "$uptime_days" -ge 5 ] && [ "$uptime_days" -le 8 ]; then echo "Uptime: $uptime_days days. Showing Notification." run_as_user "$DIALOG_CLI" --notification \ --title "$uptime_days days without a reboot!" \ --message "Your Mac needs to restart to regain performance and apply security updates." afplay "/System/Library/Sounds/Sosumi.aiff" exit 0 elif [ "$uptime_days" -ge 9 ] && [ "$uptime_days" -le 12 ]; then echo "Uptime: $uptime_days days. Showing Dialog with Postpone." afplay "/System/Library/Sounds/Sosumi.aiff" & run_as_user "$DIALOG_CLI" \ --title "Restart Required" \ --message "*${uptime_days} days without a reboot!* \n\nPlease save your work and restart. If postponed, you will be reminded in 24 hours." \ --icon "$DIALOG_ICON" \ --button1text "Restart now" \ --button2text "Postpone" \ --timer 840 --width 650 --height 280 --position bottomright --ontop dialog_results=$? elif [ "$uptime_days" -ge 13 ]; then echo "Uptime: $uptime_days days. Final warning." afplay "/System/Library/Sounds/Sosumi.aiff" & sleep 0.2 && afplay "/System/Library/Sounds/Sosumi.aiff" & run_as_user "$DIALOG_CLI" \ --title "Restart Required" \ --message "*${uptime_days} days without a reboot!* \n\n*After pressing I Understand, you will have 10 minutes to save your work.*" \ --icon "$DIALOG_ICON" --button1text "I Understand" --width 650 --height 230 --blurscreen --ontop run_as_user "$DIALOG_CLI" \ --title none --message "Computer will restart when the timer reaches zero." \ --button1text "Restart now" --timer 600 --width 320 --height 110 --position bottomright --icon none --ontop dialog_results=$? fi ## ========================================== ## 6. REBOOT EXECUTION ## ========================================== if [ "$dialog_results" = "0" ] || [ "$dialog_results" = "4" ]; then echo "Rebooting now..." shutdown -r now sleep 2 reboot elif [ "$dialog_results" = "2" ]; then echo "User postponed the restart." fi exit 0 ``` **Assign the Script to a Device** Now, navigate to any of your **Devices**, select the **Scripts** tab, click on the **\+ Assign Script** button, and select the one you just created. :::info You can also assign Scripts to Policies. To do this, navigate to the **Policies** section, select the desired Policy, and click on the **Scripts** tab. The process will be the same as when assigning it directly to an individual Device. ::: **Choose the execution method** | Method | Behaviour | Recommended? | |---|---|---| | **Once** | Runs one time per Device. | ❌ Not suitable — this Script needs to run continuously to monitor uptime. | | **Loop** | Runs repeatedly at the configured interval (15m, 1h, 6h, 1d, 7d). | ✅ Recommended — select the daily interval (`1d`) to check uptime every 24 hours and escalate alerts progressively. | | **On demand** | Only runs when manually triggered. | ❌ Not suitable for automated uptime enforcement. | This Script does not require any arguments. System uptime is calculated automatically at runtime. Click **Add** to save the assignment. --- ### What users will see **Level 2 — Notification (days 5–8):** A non-intrusive macOS notification appears in the upper-right corner with an audible alert. The user can dismiss it and continue working. **Level 3 — Dialog with postpone option (days 9–12):** A dialog window appears in the bottom-right corner. The user can click **Restart now** or **Postpone**. The dialog closes automatically after 14 minutes. **Level 4 — Forced countdown (day 13+):** A full-screen blurred warning appears first. After the user acknowledges it, a 10-minute countdown begins in the bottom-right corner. When it reaches zero — or the user clicks **Restart now** — the Mac restarts. --- ### Testing the Script To test a specific escalation level without waiting for the real uptime, uncomment the `TEST_UPTIME_DAYS` line in the Script and set it to the desired number of days: ```bash TEST_UPTIME_DAYS="7" # Uncomment for testing ``` Remember to comment it out again before deploying to production. --- ### Available on GitHub This Script is part of the [Applivery Public Script Repository](https://github.com/applivery/applivery-mdm-scripts/tree/main/Apple/Force%20Reboot%20Policy). A Device without a reboot is a patch without effect — this progressive escalation Policy keeps your fleet up to date without disrupting anyone. --- ## Restrict Admin Rights (Least Privilege) Source: https://docs.applivery.com/en/device-management/apple/macos/scripts/restrict-admin-rights/ Description: macOS script that demotes all local admin accounts to Standard User except one protected IT account, enforcing least-privilege across your entire fleet. TL;DR: Automate repetitive tasks on managed devices using scripts in Applivery for efficient device management. Key topics: device management, automation, scripting, Applivery, MDM, IT administrators In most corporate environments, administrator privileges are granted during initial Device setup and never revoked. Over time — new hires, re-enrollments, and software installations — users accumulate privileges they no longer need. Those privileges become an attack surface: unauthorized software installs, bypassed endpoint security controls, accidental changes to system configuration. This Script enforces a least-privilege baseline across your entire macOS fleet. It automatically demotes all local user accounts to Standard User — except one designated IT management account that retains its administrator privileges. The Script is safe to run silently on all Devices and is designed to be idempotent: running it multiple times always produces the same result. :::warning The Applivery Agent for macOS must be installed and active on the Device. Learn more about the [macOS Agent](https://docs.applivery.com/en/device-management/apple/apple-policies/agent/#agent-app-for-macos-devices). ::: ### Requirements | Requirement | Detail | |---|---| | Platform | macOS | | Execution privileges | Root (default in Applivery) | | Protected account | A local admin account must already exist on the Device before running this Script | :::warning Before deploying this Script, make sure the protected management account (`EXCLUDE_USER`) exists on the Device and already has administrator privileges. If it doesn't exist or isn't an admin, the Script will abort as a safety measure to prevent locking out access to the system. ::: --- ### Setup **Create the Script** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), follow the steps described [here](https://docs.applivery.com/en/device-management/apple/macos/scripts/index) to create a Script. Paste the following Script into the editor. Before saving, set the `EXCLUDE_USER` variable to the short name of your IT management account. | Variable | Description | Default value | |---|---|---| | `EXCLUDE_USER` | The username that must retain administrator rights | `admin` | Select **Bash** as the language, give it a descriptive name (e.g., `Restrict Admin Rights`), and click **Create**. ```bash #!/bin/bash ## --- ## Title: Demote all local admins to standard (except EXCLUDE_USER) ## Description: Ensures only a specific local account has administrator privileges. ## Author: Applivery ## Version: 1.0.0 ## --- ## ======== CONFIGURATION ======== EXCLUDE_USER="admin" ADMIN_GROUP="admin" ## ======== FUNCTIONS ======== is_admin() { local user="$1" dseditgroup -o checkmember -m "$user" "$ADMIN_GROUP" &>/dev/null return $? } ## ======== INITIAL CHECKS ======== if [[ $EUID -ne 0 ]]; then echo "Error: This script must be run with sudo" exit 1 fi if ! id "$EXCLUDE_USER" &>/dev/null; then echo "Error: User '$EXCLUDE_USER' does not exist on this system." exit 1 fi if ! is_admin "$EXCLUDE_USER"; then echo "WARNING: '$EXCLUDE_USER' is NOT an administrator. Aborting for safety." exit 1 fi ## ======== GET HUMAN USERS ======== users=$(dscl . list /Users | grep -v '^_' | while read -r user; do uid=$(dscl . read "/Users/$user" UniqueID | awk '{print $2}') if [[ "$uid" =~ ^[0-9]+$ && "$uid" -ge 501 ]]; then echo "$user" fi done) ## ======== PROCESS EACH USER ======== echo "Processing local users..." echo "──────────────────────────────────────────────" count_changed=0 count_skipped=0 while IFS= read -r username; do [[ -z "$username" ]] && continue if [[ "$username" == "$EXCLUDE_USER" ]]; then echo "[SKIP] $username (intentionally excluded)" ((count_skipped++)) continue fi if ! is_admin "$username"; then echo "[OK] $username → already standard (non-admin)" continue fi echo -n "[PROC] $username → removing admin rights... " if dseditgroup -o edit -d "$username" -t user "$ADMIN_GROUP" 2>/dev/null; then echo "SUCCESS" ((count_changed++)) else echo "FAILED" echo " → Could not remove admin rights (directory service issue?)" fi done <<< "$users" echo "──────────────────────────────────────────────" echo "Summary:" echo " Users processed : $(echo "$users" | wc -l | xargs)" echo " Demoted to standard : $count_changed" echo " Skipped (excluded) : $count_skipped" echo "" echo "Protected user (should remain admin): $EXCLUDE_USER" if is_admin "$EXCLUDE_USER"; then echo "✓ User '$EXCLUDE_USER' still has administrator privileges." else echo "⚠ ATTENTION: '$EXCLUDE_USER' is NO LONGER an administrator." echo " Restore admin rights manually:" echo " sudo dseditgroup -o edit -a \"$EXCLUDE_USER\" -t user admin" fi exit 0 ``` **Assign the Script to a Device** Now, navigate to any of your **Devices**, select the **Scripts** tab, click on the **\+ Assign Script** button, and select the one you just created. :::info You can also assign Scripts to Policies. To do this, navigate to the **Policies** section, select the desired Policy, and click on the **Scripts** tab. The process will be the same as when assigning it directly to an individual Device. ::: **Choose the execution method** | Method | Behaviour | Recommended? | |---|---|---| | **Once** | Runs one time per Device. | ✅ Suitable for a one-time remediation across an existing fleet. | | **Loop** | Runs repeatedly at the configured interval (15m, 1h, 6h, 1d, 7d). | ✅ Recommended for continuous enforcement — detects new admin accounts as they appear. | | **On demand** | Only runs when manually triggered. | ✅ Useful for ad-hoc audits initiated by IT. | The recommended setup is **Loop** with a daily or weekly interval to continuously detect and demote any new admin accounts. Use **Once** for a one-time remediation on an existing fleet. This Script does not require any arguments. The protected account is configured directly in the `EXCLUDE_USER` variable inside the Script. Click **Add** to save the assignment. --- ### Recommended deployment order When enrolling a new Device, the recommended sequence is: 1. The Device enrolls in Applivery. 2. The [Create Hidden Admin User](https://github.com/applivery/applivery-mdm-scripts) Script runs to create the IT management account. 3. This Script runs to demote all other local users to Standard. This guarantees that IT always retains management access while end users cannot make unauthorized system changes. :::tip Run this Script in combination with the Create Hidden Admin User Script to ensure the management account always exists before applying the restriction. ::: --- ### Available on GitHub This Script is part of the [Applivery Public Script Repository](https://github.com/applivery/applivery-mdm-scripts/tree/main/Apple/Restrict%20Admin%20Rights). Least privilege is the first line of defense — this Script applies that Policy across your entire fleet in seconds. --- ## Sync Device Name Source: https://docs.applivery.com/en/device-management/apple/macos/scripts/sync-device-name/ Description: macOS script that reads the local ComputerName and updates the device display name in the Applivery Dashboard via API, keeping all device names in sync. TL;DR: Automate repetitive tasks on managed devices using scripts in Applivery for efficient device management. Key topics: device management, automation, scripting, Applivery, MDM, IT administrators Every Mac has a local computer name — the one the user set during initial setup, or changed later to something personal like "John Doe's MacBook". In the Applivery Dashboard, however, Devices typically show the generic name assigned at enrollment time. At scale, this makes identifying specific machines by name nearly impossible: you end up with a list of `MacBook-Pro-7` entries and no easy way to know who each one belongs to. This Script closes that gap. It reads the local `ComputerName` from each Mac and updates it in the Applivery Dashboard via the API, keeping both in sync. Run it periodically, and you can always identify any Device at a glance. :::warning The Applivery Agent for macOS must be installed and active on the Device. Learn more about the [macOS Agent](https://docs.applivery.com/en/device-management/apple/apple-policies/agent/#agent-app-for-macos-devices). ::: ### Requirements | Requirement | Detail | | --- | --- | | Platform | macOS | | Execution privileges | Root (default in Applivery) | | Internet access | The Device must be able to reach `api.applivery.io` | | Bearer Token | A valid token from a Service Account with Editor role or above | | Organization ID | The slug/ID of your Applivery organization | * * * ### Before you start — Get your Bearer Token and Organization ID **Organization ID** — Your Organization ID is the slug visible in the Applivery Dashboard URL (e.g., `my-company`). **Bearer Token (via Service Account)** — Applivery uses [Service Accounts](https://docs.applivery.com/en/platform/api/service-accounts/) to represent non-human users that can access the Applivery Administration API. Each Service Account has an associated Bearer token used as the `Authorization` header in API calls. * * * ### Setup **Create the Script** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), follow the steps described [here](https://docs.applivery.com/en/device-management/apple/macos/scripts/index) to create a Script. Paste the following Script into the editor, replacing the placeholder values shown in the table below. | Variable | Description | Example | | --- | --- | --- | | `ID_ORG` | Your Applivery organization slug/ID | `my-company` | | `API_TOKEN` | Bearer token from a Service Account with Editor role or above | `wfkj2Gi...` | Select **Bash** as the language, give it a descriptive name (e.g., `Sync Device Name`), and click **Create**. ```bash #!/bin/bash ## --- ## Title: Sync Device Name with Applivery API ## Description: Automatically updates the Device Display Name in Applivery Dashboard to match the local macOS ComputerName. ## Author: Applivery ## Version: 1.0.0 ## --- ## ========================================== ## CONFIGURATION ## ========================================== ID_ORG="your-org-id" API_TOKEN="your-api-token" BASE_URL="https://api.applivery.io/v1/organizations/$ID_ORG/mdm/apple/enterprise/devices" ## ========================================== ## 1. LOCAL DATA GATHERING ## ========================================== SERIAL_NUMBER=$(system_profiler SPHardwareDataType | grep "Serial Number" | awk '{print $4}') NEW_DEVICE_NAME=$(scutil --get ComputerName) if [ -z "$NEW_DEVICE_NAME" ]; then echo "Error: Local ComputerName is empty. Please set a hostname on the Mac." exit 1 fi echo "Syncing Device Name for Serial: $SERIAL_NUMBER" echo "Target Name: $NEW_DEVICE_NAME" ## ========================================== ## 2. API INTERACTION ## ========================================== ## GET Device Info to find the internal Device ID response=$(curl -s -X GET "$BASE_URL/$SERIAL_NUMBER" \ -H "Authorization: Bearer $API_TOKEN" \ -H "Content-Type: application/json") if echo "$response" | grep -q '"admDevice"'; then DEVICE_ID=$(echo "$response" | grep -o '"admDevice":"[^"]*"' | sed 's/"admDevice":"\([^"]*\)"/\1/') if [ -n "$DEVICE_ID" ]; then echo "Found internal DeviceID: $DEVICE_ID" update_response=$(curl -s -X PUT "$BASE_URL/$DEVICE_ID" \ -H "Authorization: Bearer $API_TOKEN" \ -H "Content-Type: application/json" \ -d "{\"displayName\": \"$NEW_DEVICE_NAME\"}") if echo "$update_response" | grep -q '"status":200' || echo "$update_response" | grep -q '"displayName"'; then echo "SUCCESS: Display name updated to: $NEW_DEVICE_NAME" else echo "FAILURE: Error updating name: $update_response" fi else echo "ERROR: Could not find DeviceID for Serial Number $SERIAL_NUMBER" fi else echo "ERROR: Could not fetch device info from API. Check Token and Org ID." echo "Response: $response" fi exit 0 ``` **Assign the Script to a Device** Now, navigate to any of your **Devices**, select the **Scripts** tab, click on the **\+ Assign Script** button, and select the one you just created. :::info You can also assign Scripts to Policies. To do this, navigate to the **Policies** section, select the desired Policy, and click on the **Scripts** tab. The process will be the same as when assigning it directly to an individual Device. ::: **Choose the execution method** | Method | Behaviour | Recommended? | | --- | --- | --- | | **Once** | Runs one time per Device. | ✅ Useful for setting the display name from day one of enrollment. | | **Loop** | Runs repeatedly at the configured interval (15m, 1h, 6h, 1d, 7d). | ✅ Recommended for ongoing sync — keeps the Dashboard updated as users rename their machines. | | **On demand** | Only runs when manually triggered. | ✅ Useful for an ad-hoc update triggered by IT. | The recommended setup is to use **Loop** with a weekly interval (`7d`) to keep the Dashboard in sync without generating unnecessary API traffic, combined with **Once** during enrollment to set the name from the first day. This Script does not require any arguments. The Device name and serial number are obtained automatically from the local system. Click **Add** to save the assignment. * * * ### Available on GitHub This Script is part of the [Applivery Public Script Repository](https://github.com/applivery/applivery-mdm-scripts/tree/main/Apple/Sync%20Device%20Name%20%28API%29). The full source code is available there for review, adaptation, and contribution. --- ## Temporary Admin Rights (JIT Elevation) Source: https://docs.applivery.com/en/device-management/apple/macos/scripts/temporary-admin-rights/ Description: macOS bash script granting standard users temporary admin privileges for 3 minutes via JIT elevation, with reason logging and automatic privilege revocation. TL;DR: Automate repetitive tasks on managed devices using scripts in Applivery for efficient device management. Key topics: device management, automation, scripting, Applivery, MDM, IT administrators The principle of least privilege is the right default — but there are moments when a standard user legitimately needs to perform an admin task: installing approved software, changing a network setting, running a diagnostic tool. The wrong solution is granting permanent administrator privileges. The right solution is giving users exactly what they need, for exactly as long as they need it, then revoking it automatically. This Script implements Just-in-Time (JIT) elevation: the user triggers it from the Applivery Self-Service, a branded dialog prompts for a reason, and if the user confirms, they receive administrator privileges for exactly 3 minutes. When the time expires, the Script revokes access automatically and removes all traces of itself — no residual LaunchDaemons, no temporary files. :::warning The Applivery Agent for macOS must be installed and active on the Device. Learn more about the [macOS Agent](https://docs.applivery.com/en/device-management/apple/apple-policies/agent/#agent-app-for-macos-devices). ::: ### Requirements | Requirement | Detail | |---|---| | Platform | macOS | | Execution privileges | Root (default in Applivery) | | swiftDialog | Installed automatically if not already present | | Corporate branding | `/var/root/CompanyAssets/logo.png` (optional, for the branded dialog) | --- ### Setup **Deploy your company logo (optional)** For a branded experience, deploy your company logo to each managed Device before running this Script. The file must be at `/var/root/CompanyAssets/logo.png`. You can distribute it using [Applivery File Management](https://docs.applivery.com/en/device-management/apple/macos/policies/file-management/). If the file is not present, the dialog will use the default swiftDialog icon instead. **Create the Script** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), follow the steps described [here](https://docs.applivery.com/en/device-management/apple/macos/scripts/index) to create a Script. Paste the following Script into the editor, select **Bash** as the language, give it a descriptive name (e.g., `Temporary Admin Rights`), and click **Create**. ```bash #!/bin/bash ## --- ## Title: Temporary Admin Rights (JIT Elevation) ## Description: Grants local admin privileges to a standard user for 3 minutes with mandatory reason logging. ## Author: Applivery ## Version: 1.1.0 ## --- ## ========================================== ## 1. PRE-FLIGHT & PREREQUISITES ## ========================================== if [ "$(id -u)" -ne 0 ]; then echo "ERROR: This script must be run with sudo." >&2 exit 1 fi install_rosetta() { if [[ "$(uname -m)" == "arm64" ]]; then if /usr/sbin/pkgutil --pkgs | grep -q "com.apple.pkg.RosettaUpdateAuto"; then echo "Rosetta is already installed." else echo "Installing Rosetta..." /usr/sbin/softwareupdate --install-rosetta --agree-to-license fi fi } ensure_clt() { if /usr/bin/xcode-select -p >/dev/null 2>&1; then echo "Command Line Tools are already installed." return 0 fi echo "Command Line Tools not found. Attempting silent installation..." clt_label=$(softwareupdate -l 2>/dev/null | awk -F'*' '/Command Line Tools/ {print $2}' | sed -e 's/^ *//' | head -n1) if [[ -n "$clt_label" ]]; then softwareupdate -i "$clt_label" -a --agree-to-license || true fi if [[ -d "/Library/Developer/CommandLineTools" ]]; then /usr/bin/xcode-select --switch "/Library/Developer/CommandLineTools" 2>/dev/null || true fi } install_rosetta ensure_clt ## ========================================== ## 2. SWIFTDIALOG DEPLOYMENT ## ========================================== DIALOG_APP="/Library/Application Support/Dialog/Dialog.app" DIALOG_CLI="/usr/local/bin/dialog" get_swiftdialog_pkg_url() { curl -fsSL -H "Accept: application/vnd.github+json" "https://api.github.com/repos/swiftDialog/swiftDialog/releases/latest" | \ sed -nE 's/.*"browser_download_url":"([^"]*\.pkg)".*/\1/p' | head -n 1 } if [ ! -x "$DIALOG_CLI" ] || [ ! -d "$DIALOG_APP" ]; then echo "SwiftDialog not found. Installing..." pkg_url="$(get_swiftdialog_pkg_url)" if [ -n "$pkg_url" ]; then pkg_path="$(/usr/bin/mktemp /tmp/swiftDialog.XXXXXX.pkg)" curl -fL "$pkg_url" -o "$pkg_path" installer -pkg "$pkg_path" -target / rm -f "$pkg_path" fi fi ## ========================================== ## 3. USER DETECTION & BRANDING ## ========================================== currentUser=$(/bin/ls -l /dev/console | /usr/bin/awk '{ print $3 }') [ "$currentUser" = "loginwindow" ] && exit 0 brandIconSource="/var/root/CompanyAssets/logo.png" brandIconDir="/Library/Application Support/Dialog" brandIconPath="$brandIconDir/logo.png" if [ -f "$brandIconSource" ]; then mkdir -p "$brandIconDir" sips -z 512 512 "$brandIconSource" --out "$brandIconPath" >/dev/null 2>&1 || cp "$brandIconSource" "$brandIconPath" chmod 644 "$brandIconPath" fi if id -Gn "$currentUser" | grep -qw admin; then "$DIALOG_CLI" --title "Temporary Admin Rights" --message "You are already an administrator." --button1text "OK" --icon "$brandIconPath" --height 220 --width 480 exit 0 fi ## ========================================== ## 4. ELEVATION DIALOG ## ========================================== message="You are about to be granted administrator privileges for 3 minutes. Use them responsibly." dialogRaw=$("$DIALOG_CLI" \ --json \ --title "Temporary Admin Rights" \ --message "$message" \ --textfield "Reason,name=reason,prompt=\"Reason (optional)\"" \ --button1text "MAKE ME ADMIN" \ --button2text "CANCEL" \ --icon "$brandIconPath" \ --height 280 --width 720 2>&1) [ $? != 0 ] && exit 0 reason=$(/usr/bin/python3 -c "import json, sys, os, re; raw=os.environ.get('DIALOG_OUTPUT', ''); data=json.loads(re.search(r'\{.*\}', raw).group(0)); print(data.get('reason', ''))" 2>/dev/null <<<$dialogRaw) echo "Admin request approved by user: $currentUser | Reason: $reason" ## ========================================== ## 5. EXECUTION & AUTO-REVOKE ## ========================================== scriptDir="/Users/Shared/AdminTime" scriptFile="$scriptDir/admin_privileges.sh" launchDaemonFile="/Library/LaunchDaemons/com.applivery.adminprivileges.plist" mkdir -p "$scriptDir" cat << EOF > "$scriptFile" #!/bin/bash currentUser=\$(/bin/ls -l /dev/console | /usr/bin/awk '{ print \$3 }') dseditgroup -o edit -a "\$currentUser" -t user admin sleep 180 dseditgroup -o edit -d "\$currentUser" -t user admin rm -rf "$scriptDir" rm -f "$launchDaemonFile" EOF chmod +x "$scriptFile" cat << EOF > "$launchDaemonFile" Labelcom.applivery.adminprivileges ProgramArguments$scriptFile RunAtLoad EOF chown root:wheel "$launchDaemonFile" chmod 644 "$launchDaemonFile" launchctl load "$launchDaemonFile" echo "Success: User $currentUser elevated for 3 minutes." ``` **Assign the Script as an On-demand action** Now, navigate to any of your **Devices**, select the **Scripts** tab, click on the **\+ Assign Script** button, and select the one you just created. :::info You can also assign Scripts to Policies. To do this, navigate to the **Policies** section, select the desired Policy, and click on the **Scripts** tab. The process will be the same as when assigning it directly to an individual Device. ::: Select **On demand** as the execution method — this makes the Script appear as an action in the Applivery Self-Service that users can trigger when they need temporary admin access. | Method | Behaviour | Recommended? | |---|---|---| | **Once** | Runs one time per Device. | ❌ Not suitable — the Script is designed to be triggered on demand by the user. | | **Loop** | Runs automatically at a recurring interval. | ❌ Not recommended — this would grant admin privileges automatically and repeatedly without user interaction. | | **On demand** | Only runs when the user triggers it from the Self-Service. | ✅ Recommended — the user activates the elevation when they need it. | This Script does not require any arguments. The active user is detected automatically at runtime. Click **Add** to save the assignment. --- ### What users will see Once assigned as an On-demand action, the Script appears as an item in the Applivery Self-Service. When the user taps it, a branded dialog window opens showing a message about the 3-minute limit. The user enters an optional reason and clicks **MAKE ME ADMIN** to confirm, or **CANCEL** to abort. After confirmation, the user is added to the `admin` group. After 3 minutes, the Script revokes the privileges automatically and removes the auxiliary LaunchDaemon and helper Script from the Device, leaving no trace. ### Customizing the elevation window By default, the elevation lasts 3 minutes (180 seconds). To change this, edit the `sleep 180` value in the embedded helper script block: ```bash sleep 180 # Change this value (in seconds) to adjust the duration ``` For example, `sleep 600` would grant 10 minutes of admin access. --- ### Available on GitHub This Script is part of the [Applivery Public Script Repository](https://github.com/applivery/applivery-mdm-scripts/tree/main/Apple/Temporary%20Admin%20Rights). You can use it as-is or adapt the branding, duration, and dialog content to match your organization's needs. --- ## Troubleshooting Source: https://docs.applivery.com/en/device-management/apple/macos/troubleshooting/ Description: Troubleshoot common macOS Device Management issues in Applivery — resolve Enrollment problems, configuration issues, and security concerns. TL;DR: Find solutions for common macOS device management issues in Applivery. Key topics: macOS troubleshooting, Applivery, Enrollment issues, Configuration problems, Connectivity, macOS Diagnose and resolve common issues with macOS Device Management in Applivery — including enrollment failures, MDM profile problems, App installation errors, Policy conflicts, and connectivity issues. Each article explains the likely cause and the steps to resolve it, so you can get Devices back under management quickly. --- ## App Code Requirements Source: https://docs.applivery.com/en/device-management/apple/macos/troubleshooting/app-code-requirements/ Description: Retrieve the code requirement of a macOS App using the codesign command — required for configuring PPPC Profiles and privacy preferences. TL;DR: Learn how to use the `codesign` command to retrieve a macOS app's code requirement, which is essential for secure MDM configuration. Key topics: Code Requirements, macOS Security, MDM Configuration, codesign command, macOS, MDM, codesign, Apple, Maps.app A **code requirement** is a constraint that must be satisfied for the code to be considered valid for a specific purpose. It outlines the conditions necessary for the system to evaluate the code’s signature and determine whether the code can be trusted as secure. If the code does not meet these requirements during evaluation, the validation of the code signature will fail. You can include the code signature requirement and the bundle ID for an App to allow access to protected user data. Specifying the bundle ID and code requirement strengthens the security of the Privacy Preferences payload. You can retrieve the code signature requirement for the App by executing the `codesign` commands. ### Finding the Code Requirement of an App To find the code requirement of an App installed on the Mac, run the following command in the terminal: ``` codesign -dr - "path/Bundle ID" ``` For example: ``` codesign -dr - /System/Applications/Maps.app ``` Replace the `path/Bundle ID` with the path or Bundle Identifier of the App. You can find the code requirement starting after the text `designated =>`. Output example: ``` Executable=/System/Applications/Maps.app/Contents/MacOS/Maps designated => identifier "com.apple.Maps" and anchor apple ``` :::warning It is advisable to manually validate the script execution on a system before performing a bulk action. ::: --- ## Trigger DEP Re-enrollment Source: https://docs.applivery.com/en/device-management/apple/macos/troubleshooting/force-dep-enrollment/ Description: Trigger Apple DEP re-Enrollment on a Mac already set up — bypass a factory reset using a Terminal command with Apple Business. TL;DR: You can trigger Apple DEP enrollment on an already set up Mac without a factory reset by adding it to Apple Business and running `sudo profiles renew -type enrollment` in Terminal. Key topics: DEP enrollment bypass, Mac MDM enrollment, Apple Business Manager integration, Terminal commands for macOS, Avoiding factory reset, Mac, Apple Business, DEP, Applivery, MDM, Terminal, Smart Enrollment When a Mac is turned on and goes through the initial setup before being added to Apple Business, it misses the DEP check-in that normally happens at first boot. In most cases, the standard fix is a factory reset — but if you need to avoid wiping the device, there is an alternative. By adding the Mac to AB and running a single Terminal command, you can trigger DEP enrollment on a device that is already set up. :::warning This method triggers MDM enrollment, but **Smart Enrollment does not apply fully**. Automations that run at first boot — such as automatic admin account creation — will not execute. Configure those settings manually after enrollment if needed. ::: **Add the Mac to Apple Business** In [Apple Business](https://business.apple.com/), add the device and assign it to Applivery as the MDM server. Make sure a DEP profile is assigned to the device in Applivery before proceeding. If you need help with this, refer to [DEP configuration in Applivery](https://docs.applivery.com/en/device-management/apple/enrollment/dep/). **Run the enrollment command** On the Mac, open **Terminal** and run the following command: ```bash sudo profiles renew -type enrollment ``` Enter the admin password when prompted. This triggers the DEP check-in and sends the MDM enrollment profile to the device. **Complete enrollment** A system prompt will appear asking the user to allow device management. Follow the on-screen steps to complete enrollment. Once done, the device will appear under **Devices** in the Applivery Dashboard. --- ## Sign macOS PKG Source: https://docs.applivery.com/en/device-management/apple/macos/troubleshooting/sign-macos-pkg/ Description: Sign macOS PKG packages using the command line or Xcode with a Developer ID Installer Certificate to ensure Apps are trusted and verifiable. TL;DR: Sign your macOS PKG packages using the `productsign` command in Terminal or automatically through Xcode with a Developer ID Installer certificate for secure distribution. Key topics: macOS PKG Signing, Developer ID Installer Certificate, Command Line Signing (productsign), Xcode Signing Process, macOS, PKG, Xcode, Apple Developer, Terminal, Keychain Access To sign macOS packages, you’ll require an appropriate certificate, such as a TLS/SSL certificate with signing usage, which must be verifiable on the client. Typically, a **Developer ID Installer** certificate is used for this purpose, obtained from an Apple Developer account. However, third-party certificates meeting these criteria are also acceptable. If you don’t have a certificate and intend to use an Apple Developer account, you can commence the signup process on Apple’s website. If utilizing an Apple Developer account, certificates can be generated by linking your Developer account to Xcode and exporting the certificate file from Xcode. Alternatively, you can log in to your Apple Developer account online and download the certificate through a web browser. When creating the certificate, ensure that the certificate type is designated as a Developer ID Installer certificate and confirm that it is saved to your macOS Keychain. Once you obtain your certificate, there are several methods available for signing the macOS PKG. ### Signing PKGs with Terminal and Command Line In this example, you will have to use the `productsign` command. **Open Keychain Access** First, open **Keychain Access** on macOS and find the certificate. If you’re using an Apple certificate, it should start with **Developer ID Installer: …** followed by your Apple Developer account name, and end with a serial number in parentheses. **Open Terminal and Run the Command** Next, open the Terminal. The command to sign the package should look something like this: ```bash productsign --sign "Developer ID Installer: Your Developer Name (1A2B3C4D5E)" ~/Desktop/example.pkg ~/Desktop/signed-example.pkg ``` The text within quotes after `--sign` should be the Common Name of your certificate. The first argument (`~/Desktop/example.pkg`) indicates the current location of the unsigned package on your computer, while the second argument (`~/Desktop/signed-example.pkg`) is where you want to save your signed package. **Verify the Signed Package** Once done, run the command. If it works, you should see something similar to the following printed out in Terminal: ```bash productsign: using timestamp authority for signature productsign: signing product with identity "Developer ID Installer: Your Developer Name (1A2B3C4D5E)" from keychain /Users/sdeveloper/Library/Keychains/login.keychain-db productsign: adding certificate "Developer ID Certification Authority" productsign: adding certificate "Apple Root CA" productsign: Wrote signed product archive to /Users/sdeveloper/Downloads/munkitools_signed-3.2.0.3476.pkg ``` Verify that the signed package is located at the destination you specified. ### Signing using Xcode Suppose you’re building your macOS PKG in Xcode and your Apple Developer account is linked. In that case, Xcode can automatically request a certificate from your Developer account and include it in the signing certificate for the package during the Build and archive phases. We recommend referring to [Apple’s documentation](https://help.apple.com/xcode/mac/current/#/dev3a05256b8) for more detailed instructions. :::tip Ensure that you choose **Developer ID Installer** from the dropdown list for the **Signing Certificate** setting when using this approach. This option can be found under the Signing section of the General Settings tab. ::: --- ## Renew the Apple Push Certificate Source: https://docs.applivery.com/en/device-management/apple/renew-push-certificate/ Description: Renew your Apple Push Certificate with the account that created it, and find out which Apple ID that was when nobody remembers. TL;DR: Renew with the same Apple ID that created the certificate. A different account means losing control of every enrolled Device. Key topics: Renewing with the original Apple ID, Identifying a forgotten account, Verifying the right certificate, Applivery, Apple, Apple Push Certificate, Apple ID The Apple Push Certificate is what lets Applivery talk to your Apple Devices. It expires every year, and renewing it is routine — as long as you renew it with the account that created it. :::warning **The certificate must be renewed with the same Apple ID that created it.** Signing in with a different account does not renew your certificate: it creates a separate one. The original expires, Applivery stops being able to manage your enrolled Devices, and getting them back means re-enrolling the entire fleet. ::: For the initial setup, see [Get Started](https://docs.applivery.com/en/device-management/apple/get-started/). ### Finding out which Apple ID was used **If the Apple ID field was filled in during setup**, the account is recorded in your Workspace, under **Settings → Apple Setup**. That is the whole point of the field. **If it was left empty**, Applivery has no record of it. The account lives only on Apple's side, so it has to be identified from outside the platform: - **Old emails from Apple.** Receipts, renewal notices and expiry warnings all go to the account that owns the certificate. Search the shared mailboxes too, not just personal ones. - **Whoever set up the MDM originally.** Often an administrator who has since changed role or left, so it is worth asking beyond the current IT team. - **The Apple Push Certificates Portal.** Sign in with each corporate account you suspect and check whether the certificate is listed. The account that shows it is the owner. If none of that works, contact **Apple Support**. The certificate belongs to the Apple ID that created it, and Applivery cannot transfer or recover it. ### Checking you are renewing the right certificate Before you renew, confirm that the certificate identifier shown in Applivery matches the one in the Apple Push Certificates Portal. If they differ, you are looking at two different certificates — and renewing the wrong one leaves the real one to expire on schedule. ### Preventing it next year Fill in the **Apple ID** field in your Workspace. It costs one minute during setup, it records the account where the next administrator will look for it, and it is the difference between a routine renewal and re-enrolling every Device you manage. --- ## Security Info Source: https://docs.applivery.com/en/device-management/apple/security-info/ Description: Check the security state of an Apple device in Applivery — encryption, passcode presence and compliance — and understand what each value means. TL;DR: Check an Apple Device's encryption and passcode state in Details > Security info. On iOS, encryption is verified, not enabled — Apple requires hardware capabilities of 3 plus a passcode for data to be protected. Key topics: iOS Data Protection, Passcode compliance, FileVault reporting, Device security verification, Applivery, Apple, iOS, macOS, FileVault "Is this iPhone encrypted?" is a question that comes up in every security audit, and on Apple Devices it has an unusual answer: **encryption isn't something you turn on**. On iOS and iPadOS, Data Protection is a capability of the hardware, and it's always there. There is no policy setting to enable it, because there's nothing to enable. What there is, is a way to **verify** it — and that's what the Security info panel is for. ### Where to find it Open a Device from the device list in the [**Applivery Dashboard**](https://dashboard.applivery.io) and go to **Details** → **Security info**. ![security info](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/c03ec296-aa2b-4d95-ab51-bc931d8fc1c2.png) ### Verifying encryption on iPhone and iPad Encryption on iOS depends on two things at once, and Apple states the criterion explicitly: :::info **For a Device to have Data Protection, the hardware encryption capabilities must be** `3` **, and a passcode must be present.** Both conditions, not one or the other. :::

Value

What it means

Hardware encryption capabilities

1 — block-level encryption only · 2 — file-level encryption only · 3 — both

Passcode present

Whether the Device has a passcode set at all

This is why the [Passcode configuration](https://docs.applivery.com/en/device-management/apple/apple-policies/passcode/) matters so much on Apple Devices. The hardware does the encryption, but **the passcode is the key**. A Device with full hardware capabilities and no passcode is, in practice, an unprotected Device — and it will report exactly that here. If you're filling in a compliance checklist that asks _"is the Device encrypted?"_, this pair of values is your evidence. ### Passcode compliance Two values report whether the passcode is good enough, and the difference between them matters:

Value

What it checks

Passcode compliant

The passcode meets all requirements on the Device, including those coming from Exchange and other accounts.

Passcode compliant with profiles

The passcode meets the requirements coming from MDM profiles only.

When you're troubleshooting _"why is this Device flagged?"_, the second one is usually the one you want: it tells you whether **your** Policy is satisfied, without the noise of requirements set by a mail account you don't manage. :::warning **Neither value applies to Devices enrolled through User Enrollment.** Apple doesn't report passcode presence or profile compliance for personal Devices, so an empty value on a BYOD Device isn't a fault — it's the expected behaviour. Combined with the fact that [Apple ignores most passcode settings in User Enrollment](https://docs.applivery.com/en/device-management/apple/apple-policies/passcode/), personal Devices simply can't be verified this way. ::: ### Encryption on Mac macOS works the other way around: encryption **is** a real setting, and it's FileVault.

Value

What it reports

FileVault enabled

Whether full disk encryption is on.

Has institutional recovery key

Whether an organizational recovery key exists.

Has personal recovery key

Whether a personal recovery key exists.

Recovery keys are worth checking alongside the encryption state itself. An encrypted Mac with no escrowed recovery key is a Mac you can't help when the user forgets their password. FileVault is covered in [its own article](https://docs.applivery.com/en/device-management/apple/macos/policies/filevault/). ### iPhone and iPad work the opposite way to Mac Both report here, but the question you're answering is different on each:

iPhone / iPad

Mac

Is encryption a setting?

No — it's always in the hardware

Yes — FileVault

What you do about it

Verify it

Enable it, then verify it

What makes it effective

The passcode

FileVault being on

What to check

Hardware capabilities 3 + passcode present

FileVault enabled + a recovery key exists

The practical consequence: on an iPhone, "not encrypted" is really "no passcode", and you fix it with a [Passcode configuration](https://docs.applivery.com/en/device-management/apple/apple-policies/passcode/). On a Mac, it's a FileVault problem and you fix it there. ### What Security info does not tell you **There is no jailbreak or integrity status for iOS.** Apple's MDM protocol simply doesn't expose one — no MDM in the market can report it, Applivery included. The two integrity-related values that exist in this response, Secure Boot and System Integrity Protection, are **macOS-only** and return nothing on an iPhone or iPad. If your requirements include detecting compromised Apple Devices, that has to come from a third-party **Mobile Threat Defense** solution. --- ## Supervision Source: https://docs.applivery.com/en/device-management/apple/supervision/ Description: Apple Supervision mode in Applivery — benefits, how to enable it, and why it unlocks advanced MDM features for organization-owned Devices. TL;DR: Apple Supervision mode enhances iOS device management with advanced features, best suited for organization-owned devices and requiring a factory reset for activation. Key topics: Supervision Mode, Device Enrollment Program, Apple Configurator, iOS Management, MDM Features, Apple, iOS, Applivery, Apple Business ### What is Supervision? **Supervision** was introduced by Apple in iOS 5. It's a special working mode that enables administrators to have more control over Apple Devices. Supervision mode requires a factory reset or new Devices that are configured through [Apple Configurator](https://docs.applivery.com/en/device-management/apple/enrollment/apple-configurator/) or [Apple Device Enrollment Program (DEP)](https://docs.applivery.com/en/device-management/apple/enrollment/dep/). :::tip Supervision is highly recommended for organization-owned Devices as it unlocks powerful management features. ::: ### Why should I use supervision? Supervision enables many additional features and functionalities in Applivery. Below are some of the most commonly used features: | Feature | Description | | --- | --- | | **Lost Mode** | Enable Lost mode in any Device. Also known as **Find my**. | | **Activation lock bypass** | Prevent being locked out of a Device due to Apple ID activation lock. | | **Silent App installation** | Deploy Apps silently to Devices without prompting any message to the user. | | **Home screen layout** | Define how Apps are displayed in the Home Screen layout across pages and the dock. | | **Wallpaper change** | Remote configure wallpaper image for lock and home screens. | | **App restrictions** | Create a white list or black list of Apps. | | **Global HTTP Proxy** | Force all traffic to pass through a web proxy. | | **Web content filtering** | Create a whitelist or blacklist of websites in Safari. Block adult content. See [Block or Allow URLs in Safari](https://docs.applivery.com/en/device-management/apple/ios-ipados/policies/web-content-filter/). | | **Updates management** | Manage and push OS updates. | | **Activation lock management** | Disable activation lock and manage activation lock bypass codes. | | **Additional restrictions** | Block Apple ID and email account changes. Block app installs and uninstalls. Block passcode changes and much more... | ### When should I use supervision? Supervision is recommended mainly when the organization owns the Devices that are being managed, and normally, it's **not recommended** in Bring Your Own Device (BYOD) scenarios for two main reasons: 1. Most users will not be very comfortable granting such an advanced level of control over their Devices. 2. Supervision requires a factory reset of the Devices, so all content (Apps and media) is wiped from the Device, and this data cannot be restored without disabling supervision mode. ### How do I activate Supervision mode? There are three main ways to enable supervision: - Connect the Device via USB to an Apple computer and run **Apple Configurator**. - Enroll the Devices through the **Apple Device Enrollment Program (DEP)** in Apple Business. - Specifically for T2 Security Chip or Apple Silicon Devices, use the **Apple Configurator iPhone App** that will enroll the Device in Apple Business. :::warning In **macOS 11 or later**, all Mac computers enrolled using either Device Enrollment or Automated Device Enrollment (DEP) are supervised. ::: All these options will also enroll the Device in Applivery after the process, so that you can start managing it right away. --- ## General Settings Source: https://docs.applivery.com/en/device-management/general-settings/ Description: General Settings in Applivery Device Management — Enrollment, Policies, Automation Rules, Segments, and resource distribution. TL;DR: Applivery's General Settings allow administrators to centrally manage and configure Android devices, including system settings and security policies. Key topics: Android device management, Applivery platform, security policy enforcement, device configuration, Applivery, Android General Settings contains the cross-platform configuration options that apply across your entire Workspace — things like Segments, Device Audiences, Smart Attributes, Automation Rules, and Resource distribution. These settings let you structure your organization within Applivery, define how Policies are composed and applied, and automate routine Device Management tasks at scale. --- ## Auth Connector Source: https://docs.applivery.com/en/device-management/general-settings/auth-connector/ Description: Deploy the Applivery Auth Connector as a Docker container to supply SCEP challenge passwords for NDES Certificate Authority services. TL;DR: The Applivery Auth Connector, deployed as a Docker container, simplifies certificate requests by providing SCEP challenge passwords for devices, especially in private networks with NDES services. Key topics: Auth Connector Deployment, Certificate Provider Configuration, Docker Container Setup, SCEP Challenge Management, Applivery, Docker, SCEP, NDES, AMD64, ARM64 The **Applivery Auth Connector** is a helper service that supplies your Applivery Workspace with valid SCEP challenge passwords, which are then delivered to Devices so they can request certificates. This is typically required when NDES Certificate Authority services are hosted within private networks. Applivery distributes the Auth Connector as a **Docker container** for both **AMD64** and **ARM64** architectures. From an infrastructure perspective, the Auth Connector establishes outbound connections to the PKI server running the NDES service, retrieves SCEP challenges, and reports them back to the Applivery Dashboard for use in device configurations. **Configure the Certificate Provider** Before deploying the Auth Connector, you will need to configure a new Certificate Provider. Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), navigate to the **Resources** 1 section. From the left side menu, select **Certificate providers** 2 and click the **\+ Create Certificate provider** button 3. Fill in the provider's General, Server and Challenge Configuration, and at least one Certificate Profile with its authority name, key and subject. You'll find every field explained in [Certificate Providers](https://docs.applivery.com/en/device-management/general-settings/certificate-providers/). :::info One Auth Connector, one Connector Token and one challenge serve every Certificate Profile on that provider. You don't deploy a connector per profile. ::: Click **Save**, then reopen the configuration to copy the **Connector Token** 4 displayed at the top. ![auth connector token](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/06f0d79a-cf20-4c9f-b578-ec4ac2db686b.png) **Deploy the Auth Connector** Deploy the Auth Connector as a **Docker container**. The service is packaged as a Docker image, which you can download from the **Applivery Docker registry**: ``` europe-southwest1-docker.pkg.dev/applivery/public/auth-connector ``` #### Available versions

Architecture

Tags

linux/amd64

latest, 0.1.2

linux/arm64

latest-arm, 0.1.2-arm

#### How to configure the container You need to provide a few important pieces of information for the container to run: - **CONNECTOR\_TOKEN**: The token obtained from the Certificate Provider in the previous step. - **LOG\_LEVEL**: The level of logging detail. Options are `debug`, `info`, `error`, or `silent`. Default is `info`. - **LOG\_JSON**: Set to `true` to output logs in JSON format, or `false` for plain text logs. Default is `false`. You can provide these settings in **two ways**: 1. Using a `.env` file: A file that contains all the environment variables. 2. Directly as environment variables in your **Docker run command** or **Docker Compose file**. #### Configuration file example ``` ## Connector token of the Certificate provider. (required) CONNECTOR_TOKEN= ## Required for private instance deployments. ## TENANT= ## Log level can be debug, info, error or silent. (default: info) LOG_LEVEL=info ## Log as json. (default: false) LOG_JSON=false ## Listening port for the report server. (default: 3000) PORT=3000 ``` :::info You only need to set the **TENANT** variable for **Private Instances**. ::: #### Examples with Docker run ```bash ## Environment variables docker run \ -e CONNECTOR_TOKEN=YOUR_AUTH_TOKEN \ -p 3000:3000 \ europe-southwest1-docker.pkg.dev/applivery/public/auth-connector:latest ``` ```bash ## Config file docker run \ -v .env:/app/.env \ -p 3000:3000 \ europe-southwest1-docker.pkg.dev/applivery/public/auth-connector:latest ``` #### Examples with Docker Compose ```yaml services: # Config file applivery-auth-connector: image: europe-southwest1-docker.pkg.dev/applivery/public/auth-connector:latest volumes: - .env:/app/.env ports: - 3000:3000 ``` ```yaml services: applivery-auth-connector: image: europe-southwest1-docker.pkg.dev/applivery/public/auth-connector:latest-arm environment: CONNECTOR_TOKEN: YOUR_AUTH_TOKEN #TENANT: LOG_LEVEL: info ports: - 3000:3000 ``` ### Status report An HTTP service runs on port 3000 inside the Auth Connector container, exposing a status report with information such as: - Number of challenges requested. - Total error count. - Additional operational metrics. The same status information is also available directly in the Certificate Provider configuration in the Applivery Dashboard via the connector status icon. A **green checkmark** indicates that the connector has reported successfully within the **last 20 minutes**. :::info Errors such as **The password cache is full** indicate that **the NDES server has reached its request limit**. Adjust the corresponding Windows Server registry values to increase this limit. ::: --- ## Automation Rules Source: https://docs.applivery.com/en/device-management/general-settings/automation-rules/ Description: Automation Rules in Applivery orchestrate Device lifecycle management by triggering actions based on Device Audience criteria. TL;DR: Applivery's Automation Rules automate device management by triggering actions based on defined device audience criteria, simplifying configuration and policy enforcement. Key topics: automation rules, device audience, actions, policy enforcement, device configuration, Applivery, iOS, Android, Windows, iPhone, Tablet **Applivery’s Automation Rules** are a **device orchestration** mechanism that enables administrators to define automated business logic for the **life cycle management** and configuration of mobile and desktop Devices. An Automation Rule consists of a **Device Audience** definition that, when met, automatically triggers one or more **actions** on Devices that satisfy the criteria. This allows you to dynamically apply configurations, security Policies, or app deployments without manual intervention. ### Creating an Automation Rule Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), navigate to the **Automation** 1 section. Select **Automation Rules** 2 and click the + **Create Automation Rule** button 3. The configuration form includes the following sections: #### Configuration - **Name**: A unique and descriptive identifier for the rule. - **Description** (Optional): A brief explanation of the rule’s purpose. #### Devices audience The **Device Audience** defines which Devices will be affected by the rule’s actions. Devices are selected based on: - **Device tags**: Metadata associated with Devices, such as location (_Madrid_, _Nursing_), operating system (_iOS_, _Android_, _Windows_), or device type (_iPhone_, _Tablet_). - **Employee tags**: Metadata associated with the user assigned to the Device. - **Serial numbers**: Explicit selection of individual Devices by their unique serial numbers. - **Add device / Add employee**: Manually include specific Devices or users. :::info The rule applies to all Devices that meet **all** criteria defined in the Device Audience (AND logic between selection types). ::: You can learn more about [**Device Audiences**](https://docs.applivery.com/en/device-management/general-settings/device-audiences/) by following this link. #### Actions **Actions** define what the system will execute on Devices that match the defined audience. There are two: - **Set a Policy** 4 — applies a previously defined configuration Policy to the selected Devices. - **Add a Smart Attribute** — assigns a [Smart Attribute](https://docs.applivery.com/en/device-management/general-settings/smart-attributes/) value to the selected Devices. Because Smart Attributes feed [Device Audiences](https://docs.applivery.com/en/device-management/general-settings/device-audiences/) in turn, this lets you build layered automation: one rule labels the Devices, another acts on that label. :::info **These are the only two actions available.** Automation Rules configure Devices — they don't send commands. There is no action to lock, wipe or disenroll a Device from a rule. To reach those outcomes automatically, apply a restrictive Policy with the rule and let that Policy's own [Policy Enforcement Rules](https://docs.applivery.com/en/device-management/android/policies/enforcement-rules/) (Android only) handle blocking and wiping. Otherwise, use remote commands manually. ::: When configuring the **Set a Policy** action, you specify the **target platform** 5, such as Apple, Android, or Windows, to determine which Devices the Policy applies to. You also assign a numeric **priority** 6 value, for example, 100. If multiple rules affect the same device, the system applies the Policy associated with the rule that has the **highest priority** (with lower numbers indicating higher priority). This ensures consistent and predictable behavior across the fleet. ![actions for Automation Rules](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/9f1166a0-bdbb-41fe-8079-098a694fdc3b.png) Automation Rules continuously evaluate Devices to determine if they meet the defined audience criteria. When a Device matches, the specified actions—such as applying a Policy—are automatically executed. If the Device no longer meets the criteria, actions can be reverted or updated according to the rule’s configuration. This ensures Devices always reflect the intended settings and simplifies fleet management by enabling automatic segregation and configuration based on metadata. --- ## Bulk Enrollment Source: https://docs.applivery.com/en/device-management/general-settings/bulk-enrollment/ Description: Invite multiple users to enroll their Devices at once in Applivery, instead of creating enrollments one by one. TL;DR: Go to Devices, open the dropdown next to + Enroll device and select + Enroll multiple Devices to invite a whole list of employees in one action. Key topics: Bulk enrollment, Device Employees, Mass onboarding, Enrollment expiration, Applivery, Apple, Android, AOSP Once you have your Policies configured, you can start enrolling Devices. Creating them one at a time is fine for a handful of people, but for onboarding a whole team, opening a new office or refreshing a fleet, Applivery lets you invite everyone at once. Let's take a look at it. Bulk Enrollment creates **one enrollment per employee**: you add a list of people, and each one gets their own enrollment in the Devices list, with its own instructions and its own expiration. It works for Apple, Android, AOSP and Windows — the form is the same one you already know, only asking for a list of employees instead of a single one. ### Creating a bulk enrollment Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), navigate to **Devices** 1. Next to the **\+ Enroll device** button, open the dropdown and select **\+ Enroll multiple devices** 2. ![enroll multiple devices](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/d5eead26-c31e-4763-a9ab-52375f06d6d0.png) **Configure the enrollment settings** Fill out the form as follows: - **Platform:** Choose the platform for this batch. - **Management mode:** On Android, choose how the Devices will be managed. - **Employees:** The people you want to invite. Start typing to search your existing employees, or enter a new email address directly — **an enrollment will be created for each employee you add**. - **Policy:** The Policy the Devices will have applied once enrolled. :::info If an employee's email is not found, a new employee is created automatically. You don't need to add anyone to your directory beforehand. ::: **Review the optional settings** Expand **More options** for the rest: - **Tags:** Organize, group, and filter the resulting Devices. - **Display name**: A friendly name to identify the Devices among the others. - **Expire after**: How long the enrollments remain usable. Once the time passes, they stop working. - **VPP Location** _(Apple)_: App licenses will be associated automatically to the Devices from this Apple Business location. - **Skip personal info** _(Apple)_: Skips the personal information steps during setup. - **Send instructions email to employee**: Notifies each person with the steps to enroll. When enabled, you can also set the **Instructions language** and add a custom **message**. **Create the enrollments** Click **Create enrollments** — the button shows how many are about to be created, one per employee. Each enrollment is then added to the list of Devices with a pending state, the assigned Policy, and its expiration countdown. Click on any of them to display its details and instructions, exactly as you would with an individual enrollment. :::warning **A batch applies one Policy to everyone in it.** If different people need different Policies, create one batch per Policy — or assign them conditionally using [Smart Attributes](https://docs.applivery.com/en/device-management/general-settings/smart-attributes/). ::: ### What the employee receives If you chose to send the instructions email, each employee gets their own message with the steps for their platform and management mode. From their point of view nothing indicates they were part of a batch — the enrollment is individual, and so is the code or QR they receive. The enrollment instructions vary by platform, and are covered in each platform's enrollment article: - [Apple](https://docs.applivery.com/en/device-management/apple/enrollment/enrollment-methods/) - [Android](https://docs.applivery.com/en/device-management/android/enrollment/manual-enrollment/) - [Windows](https://docs.applivery.com/en/device-management/windows/enrollment/enrollment-methods/) --- ## Certificate Providers Source: https://docs.applivery.com/en/device-management/general-settings/certificate-providers/ Description: Configure a SCEP Certificate Provider once and add a Certificate Profile for each certificate you need, then pick the profile from Apple and Android Policies. TL;DR: Configure the SCEP server and challenge once on a Certificate Provider, add a profile for each certificate you need, and pick the provider and profile from an Apple SCEP payload, an Android WPA-EAP Wi-Fi network or an Android Policy assignment made through the API. Key topics: Provider and profile settings, Certificate Provider configuration, Challenge modes, Certificate Profiles and key pair aliases, Certificate reissue, Apple SCEP payload, Android WPA-EAP Wi-Fi with EAP-TLS, Android Policy assignments through the API, Device certificates and certificate report, Existing providers and the Default profile, Certificate Providers API, Applivery, SCEP, NDES, Auth Connector, Apple, Android A **Certificate Provider** is a resource that stores one SCEP connection, meaning the server Devices request certificates from it and the challenge they use to prove they're allowed to. On top of that connection, each provider holds one or more **Certificate Profiles**: the authority name, key settings, and subject for one type of certificate. When you need a different certificate, you add a profile instead of creating another provider. Your Policies then pick the provider and the profile they need, from an Apple **SCEP** payload or an Android **WPA-EAP** Wi-Fi network. One server and one challenge can issue different identities, for example, one for Wi-Fi and another for VPN, without duplicating the configuration or its secrets. :::info One [Auth Connector](https://docs.applivery.com/en/device-management/general-settings/auth-connector/), one Connector Token, and one challenge serve every profile on a provider. You don't deploy a connector per profile. ::: ### Provider and profile settings Every field in the form belongs to one of two levels. The level decides where the value is stored and how many Devices are affected when you change it.

Level

What it describes

Fields

Provider

How Devices talk to the SCEP server. You set it once, and every profile uses it.

Type, Server URL, CA Fingerprint, Retries, Retry Delay, and the Challenge Configuration

Profile

What the certificate contains. Each profile can have different values.

Profile name, Authority name, the Key Configuration, and the Subject Configuration

**Name** and **Description** also belong to the provider, but they only identify it in the list and never reach the certificate. The **Certificate providers** list shows, for each provider, its segment, its SCEP server, its profiles, and its challenge mode. ### Create or edit a Certificate Provider The form has four numbered blocks: **General Configuration**, **Server Configuration**, **Certificate Profiles**, and **Challenge Configuration**. **Open Certificate providers** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), go to **Resources** 1. From the left-hand menu, select **Certificate providers** 2 and click **\+ Create Certificate provider** 3, or open an existing provider. ![configure certificate provider](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/bf34c055-be42-44ce-b532-730efc0ea20b.png) **Fill in the General Configuration** - **Name**: the name you'll see in the list and when you select the provider from a Policy. - **Description**: optional. - **Type**: **SCEP**. On an existing provider, this section also shows its **ID** and its **Connector Token**. ![scep creation](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/c76e99e7-7c15-4039-99c7-ea1b29a63bb0.png) **Fill in the Server Configuration** - **Server URL** (required): the URL of the SCEP server. For NDES, for example: `https:///certsrv/mscep/mscep.dll`. - **CA Fingerprint** (optional): the SHA-1 fingerprint of the CA issuer, so the Device can validate the CA before it trusts the response. To get it, open the CA certificate used by the NDES server, go to the **Extensions** section, and copy the **CA Fingerprint** entry. - **Retries**: how many times to retry the request if it fails. - **Retry Delay**: the delay, in seconds, between retry attempts. Adjust **Retries** and **Retry Delay** to how your CA behaves: they're the only controls you have over a request that fails on the Device. **Configure the Certificate Profiles** Fill in the profile that's already created, with its authority name, key, and subject. Until you give it a name, it shows as **Untitled profile** with the **Default** mark: it's the profile that assignments use when they don't select one. All the fields and how to add more profiles are in [Certificate Profiles](#certificate-profiles). **Fill in the Challenge Configuration** Choose the **Mode**, meaning how Devices get the challenge:

Mode

Fields

When to use it

None

—

Your CA doesn't require a challenge.

Manual

Challenge value

A static secret that you paste. It's the same for every request.

NDES

URL, Username, Password, Challenge pool size

Applivery requests single-use challenges from the NDES mscep_admin endpoint and keeps a pool of them ready. The pool size goes from 10 to 10,000.

For **NDES**: - **URL**: `https:///certsrv/mscep_admin`. - **Username**: a domain user with permissions for the Certificate Template configured on the NDES server. - **Password**: the password for that user. - **Challenge pool size**: how many challenges Applivery keeps ready, from 10 to 10,000. Although it comes after the profiles in the form, the challenge belongs to the provider, and every profile uses it. **Save and copy the Connector Token** Click **Save**. The provider gets its own ID, shown in the URL and at the top of its details, and Policies use this ID to refer to it. Reopen the provider to copy the **Connector Token** shown at the top. You'll need it to [deploy the Auth Connector](https://docs.applivery.com/en/device-management/general-settings/auth-connector/). ### Certificate Profiles Each profile defines the authority, key, and subject of the requested certificates, sharing the server and challenge configuration. Policies select the profile to use. The **Certificate Profiles** section shows a badge with the number of profiles on the provider, and each profile has its own tab. - One profile is the **Default** profile: its tab shows **(Default),** and its name has a **Default** badge. A provider always has one, and it's the profile used when an assignment doesn't select any. - **\+ Add profile** adds another tab. Each tab is an independent profile with its own subject, key, and key pair alias. - Profiles other than the Default one have a delete (trash) icon. You can't remove the Default profile, or a profile that a Policy still uses. ![Certificate profiles](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/b8871659-2f68-4a55-8ab4-02b904c261e0.png) #### Profile name and Authority name - **Profile name**: the label you'll see in the Dashboard and when you select the profile from a Policy. - **Authority name**: used to identify the profile or template requested, for example `mycompany-pki`. Enter the intermediate or issuing CA name exactly as it appears in the CA certificate. #### Key Configuration - **Key Usage**: the allowed uses for the key: **Both**, **Signing,** or **Encryption**. - **Key Size**: the size of the generated key: **1024**, **2048,** or **4096**. It's typically **2048** or **4096**, depending on your security policy. - **Key Type**: RSA, the default value. - **Key Is Extractable**: whether the private key can be extracted from the Device keystore. - **Allow All Apps Access**: whether all Apps on the Device can use the key. #### Subject Configuration Fields with the `{}` button support [interpolation tags](https://docs.applivery.com/en/device-management/general-settings/dynamic-variables/), placeholders that Applivery replaces with Device or employee data when it deploys the certificate. Fields without the button don't support them. :::info Click `{}` to open the list of available tags and insert them from there instead of typing them. Two syntaxes coexist, `%…%` and the `{{…}}` syntax of older providers, and the selector always inserts the right one. ::: - **Subject**: the certificate subject. Supports interpolation tags, for example `CN={{user.email}}`. - **NT Principal**: the User Principal Name (UPN) in NT format, for example `john.doe@MYCOMPANY`. Supports interpolation tags. - **URI**: associated URLs or URNs. Click **Add** for each one. - **Email**: the RFC822 name. Click **Add** for each one. - **DNS**: valid domain names. Click **Add** for each one. If you store your own employee metadata, such as a `cn` or `upn` key, you can use it with `{{user.metadata.PROPERTY}}`, for example `CN={{user.metadata.cn}}` or `{{user.metadata.upn}}`. ![subject configuration](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/58e41dc3-0980-4beb-b243-677216e2bc6b.png) #### Key pair alias Each profile has a key pair alias (`keyPairAlias`): the name the Device uses to store the key pair in its keystore. Applivery generates it following a fixed pattern. It doesn't appear in the form, and you can't change it.

Profile

Key pair alias

Default

apl-scep-<providerId>

Any other profile

apl-scep-<providerId>-<profileId>

The Default profile's alias has no suffix: it's the same alias providers used before profiles existed. The profile ID suffix makes sure two profiles from the same provider never overwrite each other's key pair on the Device. Use the alias to match what the Dashboard shows with what the Device reports, as explained in [Check the certificates on a Device](#check-the-certificates-on-a-device). ### What happens when you change a provider Editing the Server or Challenge Configuration doesn't change the profiles: their settings and aliases stay exactly as they were. Changing a field in a profile tab only affects that profile. Even so, changing a provider triggers a certificate reissue. How many Devices get a new certificate depends on the level of the field you changed:

You change…

Certificates are reissued for…

Example

A profile field

Only the Devices assigned to that profile.

Changing the Subject of a VPN profile reissues certificates for the VPN profile's Devices. Devices on the Wi-Fi profile keep their serial number and their challenge.

A provider field

The Devices on every profile of the provider.

Changing Retry Delay reissues certificates for every Device. The subjects don't change, because only the connection was changed.

A reissued certificate has a new serial number and a new challenge. If the serial number stays the same, the certificate wasn't reissued. :::info Android Devices don't sync one by one: the change applies in the next reporting cycle, which can take up to about 60 minutes. When you change a provider field, expect every Device on that provider to renew its certificate within that window. ::: ### Use a profile in an Apple Policy The **SCEP** payload (`com.apple.security.scep`) configures Simple Certificate Enrollment Protocol (SCEP) settings. Its card lists iOS 10.0, macOS 10.12 Sierra, tvOS 10.0, watchOS 3.0, and visionOS 1.1. The payload's **Source** selector has two options: - **Manual**: you enter the SCEP settings in the payload yourself. There's no provider behind them, so changes in **Resources** don't apply to this payload. - **Certificate Provider**: the payload stores a reference to a provider and a profile, and Applivery fills in the actual settings when it delivers the payload to the Device. **Choose the source** In the SCEP payload of your Apple Policy, set **Source** to **Certificate Provider**. The manual fields disappear. The card shows the selected provider, with the **Change** and **View details** options. **Pick the profile** In **Profile**, select the profile you need from that provider. The Default profile shows as **(Default)**. The list only shows the profiles of the selected provider. To use a profile from another provider, click **Change**, select that provider, and pick the profile again. ![scep](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/48bcc8fe-e8de-45bc-b9c6-3d9695f6149f.png) Each SCEP configuration selects one provider and one profile. #### What the Device receives The Device never receives the references to the provider and the profile. It receives the SCEP payload with the server URL, the challenge, and the subject of the selected profile already filled in. In the Device's **Profiles** tab, the `com.apple.security.scep` payload shows as installed, along with the `com.apple.security.root` root CA payload that lets the Device trust the issuer. If a payload points to a profile that doesn't exist, for example, when you build it through the API, Applivery rejects it when you save, and the configuration profile isn't stored. ### Use a profile in an Android Wi-Fi network From an Android Policy, go to **WiFi** → **\+ Add WiFi network**, as described in [Configure Wi-Fi Networks](https://docs.applivery.com/en/device-management/android/policies/configure-wifi-networks/), and then: 1. Set **Security** to **WPA-EAP**. 2. In the EAP configuration, set **Outer** to **EAP-TLS**. 3. Set **Certificate Type** to **Certificate Provider**. 4. Select the Certificate Provider, then the profile. The certificate requested through SCEP is installed into the Device keystore by the [Android Agent](https://docs.applivery.com/en/device-management/android/policies/agent/#resources-management). :::warning If you plan to block manual Wi-Fi changes on the device, make sure at least one valid and tested network is already declared in the policy — otherwise the device may lose Wi-Fi access entirely. ::: ### Assign a profile to an Android Policy through the API Besides Wi-Fi networks, an Android Policy can request certificates with its `certificateProviderAssignments` list. The Policy editor in the Dashboard doesn't include these assignments, so you set them through the [Applivery API](https://docs.applivery.com/en/api/android/policies/put-policy/). Each assignment in the list has these fields:

Field

Description

certificateProviderId

Required. The provider the certificate is requested from.

profileId

Optional. The profile to use, as a string. If you leave it out, the Policy uses the provider's Default profile. The profile must belong to that provider.

storeCredentials

Required. Whether the issued credentials are stored on the Device. Accepts a boolean or a string.

The shortest assignment has two keys and uses the Default profile: ```json "certificateProviderAssignments": [ { "certificateProviderId": "", "storeCredentials": false } ] ``` - If you send the `profileId` of the Default profile, Applivery stores the assignment without it. When you read a Policy, a missing `profileId` always means the Default profile. - The Policy also has a `certificateProviderIds` list. Applivery fills it in from the assignments, so you don't need to send it, and writing it has no effect. - On the Device, an assignment without a profile delivers the Default profile's subject and the alias without a suffix. An assignment with a profile delivers that profile's subject and the alias with its suffix. If the `profileId` doesn't belong to the provider, Applivery rejects the save with a `400` error that names both: ```text Profile not found in certificate provider ``` Always take the `profileId` from the `profiles` list of that same provider. :::warning Applivery discards any key it doesn't recognize in an assignment, without warning. A typo in a field name doesn't return an error: the field just isn't saved. After writing through the API, read the Policy again and check that it stored what you expected. ::: ### Check the certificates on a Device A Device's **Certificates** tab lists the certificates installed on it, with their **Subject**, **Issuer**, **Serial number**, and validity period. The **Identity** label marks the certificates that include a private key. #### Android certificate report For Android Devices, the full details are in the Device's `config.certificateReport[]` field, which you get through the [Applivery API](https://docs.applivery.com/en/api/android/devices/get-device/). Use it to check that what the Device received matches what you configured:

Field

What to check

originId

It's the ID of the provider you expect.

commonName

It matches the Subject of the assigned profile, not the Default profile's.

keyPairAlias

It follows the profile's pattern and matches the alias in the Agent log.

certificateInfo.serialNumber

It only changes when the certificate is reissued.

certificateInfo.issuer

It's the same for every profile of a provider, because the CA is the same.

certificateInfo.subject

It contains the same CN as commonName.

state

It's installed when the certificate is on the Device.

numFailedRetries

It's 0 for a healthy request. A higher value means the retries ran out.

updatedAt

It matches the moment the Agent reported the installation.

#### Android Agent log The Applivery Agent on Android has a **Log Console**. Filter by `SCEP` to see the `I/SCEPEnrollment` entries and a `Certificate reporting completed` line that names the alias used. That alias and the `keyPairAlias` from the API must be the same. If they don't match, the Dashboard and the Device disagree on which key was issued. :::warning The challenge appears in plain text in the report. To document or report an issue, share its SHA-256 hash, never the challenge itself. ::: ### Example You have one NDES server and need two different certificates: 1. Create one Certificate Provider with the NDES **Server URL** and the challenge, using your own `` values. 2. In the first profile, enter the authority name as it appears on the issuing CA certificate, **Key Size** 2048, **Key Usage** **Both**, and **Subject** `CN={{user.email}}`. 3. Click **\+ Add profile** and create a second profile, with its own authority name and subject, for a different destination in your Policy. Your Apple SCEP payload and your Android WPA-EAP network each select the profile they need, without a second Certificate Provider. ### Providers created before Certificate Profiles If you created a Certificate Provider before profiles were available, open it: its previous authority name, key, and subject now make up the **Default** profile. The authority name, which used to sit under Server Configuration, is now in that profile, and the Server Configuration only keeps the shared fields. The conversion guarantees that: - The resulting profile is the Default profile, and its ID is the same as the provider's ID. - The subject, subject alternative names, key size, key type, and key usage keep their exact values, now inside the profile. The subject keeps its original `{{…}}` tags. - The provider's own settings no longer include those fields. - The key pair alias is still `apl-scep-`, with no suffix. That's why Devices don't notice the change: they keep their certificate with the same serial number and the same alias. The conversion doesn't reissue certificates. Policies that already used the provider keep using its Default profile, so you don't need to recreate anything. The Connector Token stays on the provider, and you can add more profiles with **\+ Add profile**. ### Manage Certificate Providers through the API All the operations use the base path `/organizations/{organizationId}/certificate-providers`:

Operation

Description

GET /

Lists the organization's providers.

POST /

Creates a provider. The objects in profiles can't include an id.

GET /{id}

Returns config and profiles, each profile with its config and its keyPairAlias.

PUT /{id}

Replaces the provider. Leaving out a profile deletes it.

:::warning Applivery assigns the profile IDs. If you include an `id` in a profile when you create a provider, the request is rejected with a `4xx` error, and the provider isn't created. ::: #### Edit a provider with PUT A `PUT` doesn't patch the `profiles` list, it replaces it. Any profile you leave out of the request body is deleted: ```json // Provider with P-ONE and P-TWO. This PUT keeps only P-ONE: { "config": { …unchanged… }, "profiles": [ { "id": "", … } ] } // Result: one profile. P-TWO no longer exists. ``` To edit a provider safely, always follow the same pattern: `GET` the provider, change the response, and `PUT` the full object. The IDs of the profiles you keep don't change. - If you leave out a profile that a Policy uses, the `PUT` is rejected with a `4xx` error and the provider stays as it was, with all its profiles and their IDs. Remove the profile from the Policy first, or delete the Policy, and then edit the provider. - Don't send `keyPairAlias` in a `PUT`: it's read-only. A later `GET` always returns the correct alias. #### Response format ```json { "id": "", "name": "Corporate SCEP Certificates", "config": { "type": "scep", "serverUrl": "https://scep.mycompany.com/scep", "CAFingerprint": "A789E5…AB18", "retries": 3, "retryDelay": 10, "challenge": { "mode": "ndes", … } }, "profiles": [ { "id": "", "keyPairAlias": "apl-scep-", "config": { "name": "Corporate Wi-Fi", "subject": "CN=%UserName%,O=MyCompany", "subjectAltName": { … }, "keySize": 2048, "keyType": "RSA", "keyUsage": "both", "keyIsExtractable": true, "allowAllAppsAccess": false } }, { … } ] } ``` The provider's `config` holds the shared settings, and each `profiles[].config` holds that profile's settings. `retries` and `retryDelay` only appear once, at provider level, while `subject`, `keySize`, `keyUsage`, and `keyType` only appear inside `profiles[].config`. --- ## Compliance Checks Source: https://docs.applivery.com/en/device-management/general-settings/compliance-checks/ Description: Read the Compliance checks of a Device in Applivery. Understand the shield colours, what each platform reports, and how to resolve every check. TL;DR: Compliance checks list what's wrong with a Device in its Overview. Green, grey and red shields summarise the result in the device list. Apple reports pending profiles, apps and books; Android adds setting failures and security posture. Key topics: Device compliance, Non-compliance reasons, Pending installations, Security posture, Applivery, Android, Apple, AOSP Assigning a Policy to a Device is only half the job. The other half is knowing whether the Device actually did what you asked — and if it didn't, why not. That's what **Compliance checks** answer. They work as a list of open issues. Each entry is one problem, titled with what's wrong and expanded with the details behind it. :::info **Checks only appear when there's something to report.** A Device with an empty list is a Device with nothing pending — there are no green entries confirming that each item passed. Silence is the good outcome here. ::: ### Where to find them Open a Device from the device list and go to the **Overview** section, where you'll find the **Compliance checks**. ![security posture device overview](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/3a32e80c-2687-47ff-abfd-7bb7c8a39b41.png) The **shield icon** next to the Policy field in the device list is the summary of that same information, so you can triage the fleet without opening Devices one by one:

Shield

What it means

🟢 Green

The Device is compliant. Nothing to do.

⚪ Grey

At least one check is open, and it isn't a security problem.

🔴 Red

The security posture is At risk or Potentially compromised.

The distinction between grey and red is worth internalising. **Grey is operational** — something hasn't landed yet, or a setting isn't supported. **Red is a trust issue** — the operating system itself may have been modified. They call for completely different responses. ### What each platform reports Compliance checks are a common view, but each Device only reports what **its own operating system exposes**. A block that doesn't appear isn't missing data — that platform has no such concept.

Check

Apple

Android

AOSP

Policy version not yet pushed

—

✅ current + desired

✅ current

Pending configuration profile

✅

—

—

Pending apps

✅

—

—

Pending books

✅

—

—

Setting-level failures

—

✅

✅

Security posture

—

✅

—

Two consequences worth knowing before you promise anything to a customer: - **On Apple you don't get setting-level failures.** You see what's still pending, not a per-setting reason. If a restriction isn't taking effect on an iPhone, this view won't tell you why. - **On AOSP there's no security posture**, because it depends on the Play Integrity API. That's covered in [Device Security Posture](https://docs.applivery.com/en/device-management/android/security-posture/). ### Apple checks #### Policy profile **Policy profile is not up to date** means the Device hasn't applied the current version of the Policy profile. When a profile is meant to be removed instead, the check reads **Policy profile should be uninstalled**. #### Apps Apps produce one check each, and the title tells you which of the three situations you're in:

Title

What it means

App not installed

The Device doesn't have the App yet.

App not updated

The App is installed, but at an older version than the one deployed.

App should be uninstalled

The App is on the Device and shouldn't be.

Each one shows the **Bundle ID**, tagged with its origin — _Applivery_ for Apps uploaded to the platform, _VPP_ for Apps licensed through Apple Business — plus the expected **Version** and, when the App is already there, the **Installed version**. Comparing those two is what separates a failed install from an outdated one. #### Books Books work the same way: **Book not installed** or **Book should be uninstalled**, showing either the **Resource name** for a book uploaded as an asset, or the **App Store's name** for one distributed through the store. ### Android and AOSP checks #### Policy version **Policy version is not yet pushed to the device** means the Device is still running an older version of the Policy than the one assigned. On Android the check shows both the **Current policy** and the **Desired policy**, each with its version, so the gap is visible at a glance. On AOSP only the current one is shown. This usually clears itself on the next sync. If it persists, the Device is either offline or unable to apply one of the settings — in which case you'll also see a setting-level check explaining which. #### Setting-level failures This is the block that answers _"which setting failed, and why"_. Each check is **titled with the reason**, and expands with the details:

Field

What it tells you

Package

The App the problem relates to, when it relates to one.

Field

The exact setting, or the precise field path inside it for settings with nested fields.

Reason

A more specific explanation where one exists — an app installation failure, or a password or Wi-Fi specific reason. Shown in orange.

Current value

What the Device actually has, when the setting couldn't be applied.

WiFi GUID

The specific network configuration at fault, on Wi-Fi problems.

That combination is what makes the block useful in support: you don't get _"the Device is non-compliant"_, you get the field, the reason and what the Device has instead. Two of these deserve a note: - **Password problems** add the scope in brackets — whether the requirement applies to the whole Device or only to the Work Profile. On Devices where the two are separate, that's the difference between the user changing the right password and the wrong one. - **App installation failures** are where the _Reason_ field earns its place. It distinguishes an install still in progress from an App that isn't approved, has no licences left, isn't available in the user's country, or isn't compatible with the Device — each of which is a completely different fix. #### Security posture On Android, a Device whose posture is at risk appears as a check in red, titled **At risk** or **Potentially compromised**, listing the risk detected and Google's advice for mitigating it. It's the check behind the red shield, and the only one that isn't about your configuration. See [Device Security Posture](https://docs.applivery.com/en/device-management/android/security-posture/). ### Compliance checks report, they don't enforce Nothing in this view blocks or wipes a Device on its own. Acting on what you find is a separate decision: - **Remote commands** from the Dashboard, for a one-off response to a specific Device. - [**Policy Enforcement Rules**](https://docs.applivery.com/en/device-management/android/policies/enforcement-rules/) on Android, to block and then wipe automatically after a number of days. These react to exactly the setting-level failures above, and have no equivalent on Apple. - [**Automation Rules**](https://docs.applivery.com/en/device-management/general-settings/automation-rules/), to apply a different Policy automatically to a [Device Audience](https://docs.applivery.com/en/device-management/general-settings/device-audiences/). --- ## Create Policies Source: https://docs.applivery.com/en/device-management/general-settings/create-policies/ Description: Device Policies in Applivery define how Devices are configured, secured, and controlled across Apple, Android, and Windows. TL;DR: Learn how to create and manage device policies in Applivery MDM to configure, secure, and control your Apple, Android, and Windows devices. Key topics: Device Policy Creation, Policy Configuration, Policy Assignment, MDM, Applivery, Apple, Android, Windows **Device Policies** are the core element of MDM management in Applivery. They define how Devices are configured, secured, and controlled, allowing organizations to centrally apply **settings**, **restrictions**, **applications**, and **security measures** across their fleet. Although each operating system has its own capabilities and limitations, the Policy creation workflow follows the same logic for Apple, Android, and Windows. This unified approach makes it easy to manage heterogeneous environments while still taking advantage of platform-specific features. ### What is a Policy A Policy is a collection of configurations that define how a Device behaves once it is managed. Depending on the platform, a Policy may include system restrictions, security settings such as passcodes or encryption, application installation rules, scripts or automated actions, integrations with security services, and even kiosk mode configurations. Policies are assigned to individual Devices or groups of Devices, enabling scalable, flexible, and dynamic management as your environment grows or changes. ### Supported platforms Applivery supports platform-specific Policies for the following operating systems: - Apple (iOS, iPadOS, macOS). - Android. - Windows. Each Policy targets a single platform, as management capabilities and configuration options differ between operating systems. ### How to create a new Policy Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), navigate to the **Policies** 1 section and click the **\+ Create Policy** button 2. ![create policy](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/2bd75ccd-14d3-4e59-8620-bda5c3bd38a3.png) Choose the **operating system** 3 that the Policy will apply to: Apple, Android, or Windows. **A Policy can only be associated with one platform**. Give the Policy a **clear and descriptive name** 4 that reflects its purpose or target audience. Consistent naming conventions make long-term maintenance and scalability much easier. Applivery allows you to create Policies in two 5 different ways: - **An empty Policy**, which starts from scratch and is ideal for highly customized environments. - **Template-based Policy**, available for Apple, Android, and Windows. Templates cover common use cases such as single-app or multi-app kiosk mode, secure password enforcement, Wi-Fi configuration, or restricted device setups. Using templates speeds up Policy creation and applies recommended default settings. ![policy form](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/e635edde-ca09-4ec4-9fdd-c1268f173959.png) #### Policy configuration After creating the Policy, you can add configurations based on the selected platform. For **Apple** Devices, this includes passcode and auto-lock settings, system restrictions, configuration profiles, scripts, Apps and books, network settings, and security controls. For **Android**, Policies may include kiosk configurations, system restrictions, setup actions, managed applications, security settings, and network configurations. For **Windows**, available options include scripts, application installation, security configurations, system restrictions, and update management. #### Assigning a Policy to Devices Once the Policy is configured, it can be assigned directly from the Policy Dashboard. Click **\+ Assign to device** 6, select the target device or Devices, and confirm the assignment. The Policy will then be applied automatically. ![assign policy to device](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/dd7a4886-edeb-43ea-a18f-adec64d00793.png) Applivery Policies provide a unified, flexible, and scalable way to manage Apple, Android, and Windows Devices. Carefully defining the platform, selecting the appropriate Policy type, and assigning Policies to the right Devices is essential to maintaining a secure, reliable, and easy-to-manage environment. A well-designed Policy strategy reduces operational errors, strengthens security, and supports the long-term growth of your MDM deployment. :::tip Using Policy templates can significantly speed up the Policy creation process and ensure best practices are followed. ::: --- ## Device Audiences Source: https://docs.applivery.com/en/device-management/general-settings/device-audiences/ Description: Build dynamic Device Audiences in Applivery with ALL/ANY filter groups based on tags, devices, employees, serial numbers, Smart Attributes, and Segments. TL;DR: Build Device Audiences with an ALL/ANY filter tree, nested groups, and exclusion operators, and check the result in the live Matched devices preview. Key topics: Creating Device Audiences, ALL and ANY groups, Filter types and operators, Nested groups, Matched devices preview, Migrated audiences, Automation Rules integration, Applivery, Device Audiences, Automation Rules, Smart Attributes, Segments A **Device Audience** is a saved group of Devices. You define who's in it with filters, and its membership updates automatically as device and employee data changes. Device Audiences let you target **Policies**, **configurations**, and **deployments** to exactly the right Devices **through Automation Rules**. :::info You can learn more about **Automation Rules** by following this [link.](https://docs.applivery.com/en/device-management/general-settings/automation-rules/) ::: ### How Device Audiences work A Device Audience is defined by a tree of **filters** and **groups**: - A **filter** is a single condition, for example _Device tag is any of madrid_. - A **group** is a set of filters and/or nested groups, joined by **ALL** or **ANY**.

Label

Logic

What it means

What you see in the tree

ALL

AND

Every filter or nested group in this group must match.

An ALL badge on the group header, and AND connectors between children.

ANY

OR

At least one filter or nested group in this group must match.

An ANY badge on the group header, and OR connectors between children.

This flexible, rules-based approach ensures that audiences automatically adjust as device or employee attributes change, keeping your configurations up to date without manual intervention. #### Nested groups Add a group inside another group when part of your logic needs a different join than its parent — for example, an outer **ANY** group that contains an inner **ALL** group. Nested groups stay visible in the tree, so you can see the full logic at a glance. ![nested operators](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/72d44108-d2ba-43d1-abab-a1eb773a1bea.png) - **Outer group**: joins its filters and nested groups. - **Nested group**: has its own **ALL** or **ANY** join. - **+**: adds filters or further groups inside the nested group. There's no limit on how many groups you can nest. Still, keep trees as shallow as possible and nest only when you need to mix AND and OR — it makes the audience easier to read and maintain. ### Creating a Device Audience Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), navigate to the **Automation** 1 section. Select **Device Audiences** 2 and click the **\+ Create Device Audience** button 3, or open an existing audience to edit it. ![device audiences](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/e93dbd52-8d9b-44d0-8907-9cbcadb6c109.png) The configuration form includes the following sections, all on the same page: ![configuration](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/f54b8a20-58d6-40d4-aaf2-0ebc7a7edf19.png) #### Configuration - **Name**: enter a descriptive name for the audience. - **Description** (optional): add context about the audience's purpose. #### Devices selection **Devices selection** is the tree editor where you add filters and groups. It starts with a single root group set to **ALL** or **ANY of these must match**. 1. Use the **ALL / ANY** control to choose how the root group joins its children. 2. Click **New filter** or the **+** control. 3. From the **+** menu, select **Add filter** to add a condition, or **Add group** to add a nested group. ![popover](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/72ec26c2-0167-434c-a847-1a9cbe668ca0.png) 4. In **What do you want to filter by?**, choose a filter type: **Device tag**, **Employee tag**, **Device**, **Device employee**, **Serial number**, **Smart attribute**, or **Segment**. ![filter by](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/9bf14903-0086-44b1-83f5-77b1cfd59d36.png) 5. In the **Edit filter** panel, set the condition (operator) and the values. You can click any filter to open **Edit filter** again. If you picked the wrong filter type, click **Change type** in the top right of **Edit filter** to switch that row to another type, without deleting it and starting over. ![change type](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/e8a8d7db-ef91-4da3-bcaa-e5b12cc96955.png) :::info The footer under **Devices selection** reminds you that only Devices in the segment where the audience is created, and in its child segments, can match. This is the scope of the audience itself, and it's separate from the **Segment** filter you can add inside the tree. ::: #### Matched Devices preview As you edit, the **Matched devices preview** panel on the right shows a live list and count of the Devices that currently match the whole audience tree. ![any with two filters](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/c6eaaa30-4ad3-4d3a-871b-561aaeb95f57.png) - **Filters**: the conditions you've built in **Devices selection**. - **Matched count**: the total number of Devices that currently match. - **Selected by**: a column that shows which filter caused each Device to match. Use this preview to confirm your filters work as intended before you save. If no Devices appear, review your operators and values. ### Working with groups and filters #### Groups Select a group row to show its toolbar on the group header. From there you can: ![preview matched devices](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/7d61ae05-1a4b-4246-99ac-1a1c1bf477cc.png) - **Move**: drag the group, or use the arrow, to move it up or down within its parent. - **Switch ALL / ANY**: change how that group joins its children. - **Visualize:** click the eye icon to see the Devices that match only this group. This doesn't replace the full audience preview. - **Delete**: click the trash icon to remove the group. When a collapse control is shown, you can also collapse the group to hide its children. #### Filters Select a filter row to show its toolbar. From there you can: ![preview matched devices device employee](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/0c11b1c7-9bf4-4baf-a65e-9acfcfe158d1.png) - **Edit**: click the filter to open **Edit filter** and change the field, operator, or values. - **Move**: move the filter up or down among the other items in the same group. - **Visualize**: click the eye icon to see the Devices that match this filter. - **Delete**: click the trash icon to remove the filter. ### Filter types and operators Exclusion operators such as **is none of** let you keep Devices out of the audience directly inside the tree. #### Device tag Matches Devices by their tags. - **is any of**: the Device has at least one of these tags. - **is none of**: the Device has none of these tags. - **contains**: some tag on the Device contains this text. ![device tag condition](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/2d4bedec-f92e-4bd9-82b8-db7b71cdb95c.png) #### Employee tag Matches Devices by the tags of their assigned employee. - **is any of**: the employee has at least one of these tags. - **is none of**: the employee has none of these tags. ![employee tag](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/c2296e00-bae0-44fe-a81a-6d5724e31d26.png) #### Device Matches specific Devices. First pick the platform (**Apple**, **Android**, **AOSP**, or **Windows**), then the condition: - **is one of**: the Device is one of the selected Devices. - **is none of**: the Device is none of the selected Devices. ![apple is](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/3fca86a1-c352-4c06-8117-ddea04f6f24c.png) #### Device employee Matches Devices by their assigned employee. - **is one of**: the Device belongs to one of these employees. - **is none of**: the Device doesn't belong to any of these employees. ![device employee](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/d6d3b441-757c-45ef-a4d7-22f77789fade.png) #### Serial number Matches Devices by serial number. - **is any of**: the serial number is one of the values you enter. - **is none of**: the serial number is none of those values. Serial numbers are an **exact, case-sensitive match**, as noted in **Edit filter**. ![serial number](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/b1fab5c1-9845-4ef4-a709-f96b02835eb4.png) #### Smart attribute Matches Devices by the value of a [Smart Attribute](https://docs.applivery.com/en/device-management/general-settings/smart-attributes/). Pick the attribute first: the options in the **Condition** dropdown depend on the attribute's type (string, number, date, boolean, or enum), so not every attribute offers the same operators. ![smart attribute](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ad9a1c53-5331-462f-863c-615cab2b7e55.png) #### Segment Matches Devices by the [Segment](https://docs.applivery.com/en/device-management/general-settings/segments/) they belong to. - **is only this segment**: the Device is in this segment itself, not only in one of its child segments. - **is one of**: the Device is in one of the selected segments. ![segment](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/de4d74e9-7f4a-416d-b548-d48b7ee7cd8f.png) ### Examples #### Devices with a tag A simple group of Devices for a location or platform: - Root **ALL** - **Device tag** is any of `madrid` #### Rollout with an exclusion Target Devices tagged for a rollout, but keep VIP Devices out: - Root **ALL** - **Device tag** is any of `shipping` - **Device tag** is none of `vip` You can use the same pattern with **Device** is none of to keep specific Devices out of the audience. #### Mixed logic with Segment Match a specific employee's Devices, all Android-tagged Devices, or a list of Apple Devices that are directly in the Global segment: - Root **ANY** - **Device employee** is one of `user@company.com` - **Device tag** is any of `android` - Nested **ALL** - **Device** (Apple) is one of _\[your list of Devices\]_ - **Segment** is only this segment `Global` ### Migrated audiences Device Audiences created before the filter tree editor are **migrated automatically**. You don't need to rebuild them. When you open a migrated audience, its membership appears as filters in the **Devices selection** — for example, **Device tag** is `windows` under the Windows segment scope. The **Matched devices preview** works the same as for new audiences. ![migrated audience](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/7fb84372-5d71-41f4-9996-821a485f8778.png) The migration keeps the audience's original membership. If an audience is critical, check the **Matched devices preview** the first time you open it. ### Device Audiences and Automation Rules [Automation Rules](https://docs.applivery.com/en/device-management/general-settings/automation-rules/) still select a Device Audience exactly as before, and so do other features that use an audience, such as Smart Attribute assignment. There's no new step to configure inside Automation Rules: you build and update the membership in the audience itself, and every rule that uses it picks up the change. :::info Device Audiences are dynamic — once created, they continuously update based on the most recent device and employee data. This keeps your Policies and configurations aligned with your organization's current structure. ::: --- ## Device States Source: https://docs.applivery.com/en/device-management/general-settings/device-states/ Description: What "inactive" means in Applivery, what the Last report field actually tracks, and which value to read when you need real Device activity. TL;DR: Inactive means no report in 5 days. Last report is a reporting timestamp, not a connectivity indicator. Key topics: Inactive Devices, The Last report field, Reading real Device activity, Applivery, Android Device Policy, Google A Device shows up as **inactive** and the first assumption is that it is switched off, out of coverage or broken. Usually none of those is true, and the confusion comes from reading two different things as if they meant the same. ### What inactive means A Device is marked as inactive when **it has not reported in the last 5 days**. That is the whole rule. It says something about reporting, not about connectivity. ### What Last report actually tracks The **Last report** field shows the last time **Android Device Policy** sent a status report. Google decides when that happens, not Applivery, and it does not happen at fixed intervals: the report goes out when a relevant change is detected. :::warning **Last report is not a connectivity indicator.** A Device can be online, in use and perfectly healthy, and still show an old Last report simply because nothing changed that was worth reporting. ::: ### Reading real activity instead The timestamp of the **last reported location** is generated by the Applivery agent rather than by Google, so it does track real Device activity. Through the API, the device detail endpoint exposes the values worth reading:

Field

What it tells you

sync

Last synchronization with the Policy.

agent.location

Last location reported by the Applivery agent.

agent.lastReportDate

When the agent last reported.

If a Device is genuinely not reporting on Android, the usual cause is the manufacturer's battery layer suspending the agent — see [The Agent Stops Reporting](https://docs.applivery.com/en/device-management/android/troubleshooting/agent-not-reporting/). --- ## Distribute Resources Source: https://docs.applivery.com/en/device-management/general-settings/distribute-resources/ Description: Deploy Apps, Scripts, files, and Certificates across Android, Windows, and Apple Devices in Applivery — bulk via Policies or individually. TL;DR: Applivery simplifies resource distribution to managed devices (Android, iOS, Windows, macOS) through policies or direct assignment, enabling efficient deployment of apps, scripts, and certificates. Key topics: Resource types supported by Applivery, Methods of resource distribution (policies, direct assignment), Uploading resources to the Applivery Dashboard, Adding resources to policies, Assigning resources to devices, Applivery, Android, Windows, macOS, iOS, iPadOS, bash, PowerShell, Applivery MDM Agent Applivery Device Management allows you to deploy a wide range of Resources—such as Apps, scripts, files, certificates, and other assets—across your managed Devices, including Android, Windows, and Apple platforms (macOS, iOS, and iPadOS). Distribution can be performed either in bulk through Policies or individually per device, giving you full flexibility and control. :::warning These features require the **Applivery MDM Agent** to be enabled in the Device policy. ::: ### Resource Types | Resource Type | Description | | --- | --- | | Scripts | Automate operational tasks and system configurations by deploying `bash` scripts for macOS and `powerShell` scripts for Windows. | | Apps | Deploy custom-built or third-party applications to ensure Device Employees have access to the tools they need. Supported formats include `.ipa`, `.pkg`, `.msi`, `.msix`, `.appx`, and `.apk`. | | Books | Deploy documents in a variety of formats, including `.pdf`, `.epub`, `.rtf`, `.rtfd`, and `.txt`, to ensure compatibility and accessibility across Devices. | | Images | Deploy images in `.jpg` or `.png` formats. | | Certificates | Deploy certificates to secure device connections, supporting formats such as `.p12`, `.der`, `.pem`, `.crt`, and `.cer`. | | Certificate Providers | Configure them to automate certificate issuance and lifecycle management. This allows Devices to dynamically request and renew certificates through integrated identity or certificate authorities, improving security and reducing manual administrative overhead. | :::info Books are only available for **iOS Devices**. For Shared iPad environments, books can only be assigned to **user accounts**, not directly to Devices. ::: :::info Image deployment to Android Devices is currently not available. Importing contacts is not currently supported. ::: :::info Importing contacts is not currently supported. ::: ### Resource Distribution Depending on the operating system and asset type, Applivery allows you to define how Resources are delivered: - **User-level deployment** (when supported): Targets the primary or logged-in user of the Device. - **Device-level** (system-wide) deployment: Applies assets at the machine level, regardless of user sessions. - **Policy-based deployment**: Distributes assets automatically to all Devices assigned to a specific Policy. - **Direct device assignment**: Applies assets individually to selected Devices. This flexibility enables tailored deployments based on your organization’s structure, compliance requirements, and operational needs. #### Uploading Resources to the Dashboard Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), navigate to **Resources**. Use the left-hand menu to choose the asset type you wish to upload. Then, simply click the upload button to add your asset to your Workspace. ![resources section](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/20661682-7656-43c0-828d-56f93d0ee268.png) #### Adding Resources to Policies Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), navigate to **Policies** 1. Choose the Policy to which you’d like to add a Resource. Then, from the left-hand menu, click on **Resources** 2 and select the **\+ Add Resource** button 2 to begin the upload process. ![add resource](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/8d9da070-d31a-4fe0-b925-91120d6f9a75.png) A modal window will appear where you can select the type of Resource you want to assign to the Policy. You can choose to upload it from the **Resources** section (if you have previously uploaded it) or directly from your machine. Additionally, you will be able to select the deployment scope and specify the location where the Resource will be placed on the Devices where the Policy is applied. #### Assigning Resources to Devices If you don’t want to perform a bulk deployment via a Policy, you also have the option to assign Resources individually to each Device. Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), navigate to **Devices**, and select the Device where you want to add the Resource. :::info Keep in mind that the types of Resources you can deploy depend on the Device, as explained above. ::: --- ## Dynamic Variables Source: https://docs.applivery.com/en/device-management/general-settings/dynamic-variables/ Description: Applivery interpolation tags personalize Device configurations, Scripts, and Policies with user and Device-specific data for automated deployments. TL;DR: Applivery's interpolation tags allow administrators to personalize device configurations and automate deployments by dynamically replacing placeholders with user and device-specific data. Key topics: Interpolation tags, Dynamic variables, Device configuration, Applivery Dashboard, Supported variables, Applivery, Apple Silicon Applivery supports a set of **Interpolation Tags**, also known as **Dynamic Variables**, that allow administrators to automatically personalize and adapt device configuration profiles, scripts, Smart Enrollments, and Policies with user- or device-specific data. These tags are dynamically replaced at deployment time, enabling organizations to deliver flexible, context-aware configurations across all managed Devices without requiring manual input. ### What are Interpolation Tags? **Interpolation tags** are placeholders that can be embedded within configuration values. When a profile, policy, or script is deployed to a Device, Applivery automatically replaces each tag with the corresponding real value retrieved from the Device or user record. This allows IT administrators to automate personalized deployments at scale—streamlining configuration management and minimizing human error. In the **Applivery Dashboard**, all fields and input areas that support interpolation (except those inside scripts) are marked with the interpolation symbol: ![interpolation-symbol](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ad70e326-b435-4d27-8483-961be40d6d00.png) :::info Fields without this visual indicator do not support interpolation and will treat any input as plain text, depending on the specific field type. ::: When a configuration or script is deployed to a Device, Applivery automatically replaces each interpolation variable with its corresponding real value from the Device or user record. This process streamlines the management of large device fleets by applying customized settings to each endpoint automatically. ![interpolation-input](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/83188411-c739-4ca7-bfd3-da4dd4554975.png) ### Supported interpolation variables | Variable | Description | Format | | --- | --- | --- | | `{{device.id}}` | Unique device identifier. | String | | `{{device.displayName}}` | Device display name (as configured in Applivery). | String | | `{{device.serialNumber}}` | Device hardware serial number. | String | | `{{device.osVersion}}` | Operating system version installed on the Device. | String | | `{{device.chip}}` | Device processor or chipset information. | String | | `{{device.isAppleSilicon}}` | Boolean indicating whether the Device uses Apple Silicon. | true/false | | `{{device.hostName}}` | Hostname reported by the Device. | String | | `{{device.udid}}` | Unique UDID assigned to the Device. | String | | `{{user.id}}` | Unique Applivery employee identifier. | String | | `{{user.email}}` | Applivery employee email address. | String | | `{{user.name}}` | Full name of the Applivery employee. | String | | `{{user.metadata.PROPERTY}}` | Custom metadata value for the Applivery employee. | String | | `{{incremental}}` | Global incremental counter for deployments, starting from 1. | 1,2,3, n… | | `{{incremental:N}}` | Fixed-length incremental counter with N leading zeros (N = 1–10), useful for generating unique tags. | N=1 (01,02,03…), N2 = (001, 002, 003…), etc. | --- ## Policy Composition Source: https://docs.applivery.com/en/device-management/general-settings/policy-composition/ Description: Policy Composition in Applivery — apply multiple Policies to a single Device for granular control, enhanced security, and scalability. TL;DR: Policy Composition allows administrators to apply multiple policies to a single device for flexible and granular device configuration management. Key topics: Policy Composition concepts, Single-policy model limitations, Policy layering and priority, Policy assignment and conflict resolution, Platform-specific behavior, Applivery, Apple MDM, Android Enterprise, Windows MDM, iOS, iPadOS, macOS, Windows, Android As organizations expand their Device fleets, the demand for flexible, modular configurations becomes increasingly critical. **Policy Composition** addresses this need by enabling the application of multiple Policies to a single device. This allows administrators to layer specific configurations, app deployments, and assets without interfering with existing overarching settings. Historically, Applivery’s Policy model relied on a single, monolithic Policy per device or group, which bundled all configurations, application deployments, and asset distributions together. While effective for simpler environments, this approach often limited agility in dynamic scenarios—such as targeted compliance updates, role-based application assignments, or phased rollouts—frequently necessitating full Policy recreations or overwrites. With Policy Composition, Applivery introduces a composable architecture that treats Policies as reusable building blocks. Administrators can now construct device configurations by stacking multiple Policies, setting priorities as needed, and dynamically assigning or revoking them. This granular control not only streamlines administrative operations but also reduces overhead and enhances security, compliance, and scalability across enterprise environments. ### Key terminology Understanding the key terms below is essential for effectively managing device configurations using Policy Composition in Applivery: - **Policy**: A configurable set of rules that define device behavior, including restrictions, App deployments, asset provisioning (e.g., certificates, Wi-Fi profiles), and compliance checks. - **Policy Composition**: The method for applying multiple Policies to a single device, with optional priority settings to resolve conflicts. - **Composition Set**: The complete collection of Policies assigned to a Device, representing its effective configuration at any given time. ### The Single-Policy Model In traditional Applivery deployments, each Device or device group was assigned a **single Policy** encompassing all configurations, including: - **Device configurations**: Settings and restrictions, such as passcode requirements, camera access, and network restrictions. - **Applications**: Managed Apps deployed to Devices, including in-house Apps and public App Store applications. - **Assets**: Resources such as books, certificates, wallpapers, or other device assets. While simple to manage in small environments, this model presented limitations in dynamic or complex scenarios. For instance, applying a temporary Policy—like a time-sensitive compliance update—often required creating a new Policy from scratch or modifying the existing one, which could unintentionally overwrite unrelated settings. ### Introducing Policy Composition **Policy Composition** provides a modular approach to device management by allowing multiple Policies to be applied to a single device or group. Each Policy can focus on a specific aspect of the Device—security, App deployment, branding, or other configurations—enabling administrators to manage and update settings without impacting unrelated configurations. #### Key components Policy Composition is built on three fundamental concepts that give administrators flexibility and control over device configurations: - **Policy layers**: Each Policy acts as an independent layer. For example, a base Policy may enforce general security settings (like encryption and passcode complexity), a departmental Policy could deploy role-specific applications, and a temporary Policy might enforce event-specific restrictions, such as enabling eSIM configuration. - **Priority and conflict resolution**: When multiple Policies are applied, Applivery’s Policy Composition Preview allows administrators to see the resulting configuration before deployment. Conflicts between settings are resolved according to the assigned priority of each Policy. - **Dynamic assignment**: Policies can be assigned or revoked in real time via Automation Rules, allowing updates without interrupting existing device configurations. #### Architecture flow The Policy Composition workflow follows these steps: **Policy creation** Administrators define individual Policies in the Applivery Dashboard, specifying configurations, Apps, or Resources. **Policy assignment** Policies are assigned to Devices or groups, optionally with priority levels to control how conflicts are resolved. **Composition processing** The Applivery MDM server aggregates the assigned Policies into a Composition Set, ensuring priorities are respected. **Device sync** The composed configuration is pushed to Devices using platform-specific protocols (Apple MDM, Android Enterprise, Windows MDM). **Monitoring and updates** Any changes to Policies are propagated automatically, with audit logs tracking assignments and conflicts. #### Implementation guide ##### Availability The Policy Composition feature is available across all areas where a single Policy could previously be assigned. This includes **Manual Enrollment Links**, which allow creating links with multiple Policies for initial device setup; **Direct Device Assignment**, where Policies can be applied directly to individual Devices; **Smart Enrollments**, which enable applying composed Policies during automated enrollment workflows; and **Automation Rules**, allowing multiple Policies to be applied based on **Device Audience**. ##### Assigning Policies When assigning Policies in any of these scenarios, an enhanced modal window opens, similar to the previous single-policy interface. Administrators can now add multiple Policies to a Device or group and control the order in which they are applied. Policies can be reordered either by using the interface arrows or by assigning numerical priority values, where lower numbers indicate higher priority at the top of the Composition Set. To open the modal from a Device, select the Device and look at the **device summary** on the left. Hovering over the **Policies** field reveals a pencil icon — click it and the modal opens. The interface includes several elements to facilitate management. The **Policy list** 1 displays all assigned Policies, while the **Priority** 2 field lets administrators set the order of application. **Interpolations** 3 show all dynamic variables used across Policies, and the **Preview** 4 option allows reviewing the raw composed configuration before deployment. Finally, the **Add Policy** 5 button lets administrators include additional Policies in the set. ![policy composition](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/bdc72b48-c51a-40e4-81a9-687b5bd8f7c6.png) #### Platform-specific conflict resolution The behavior of the Composition Set varies depending on the Device platform. :::info **Priority order and conflict outcome are two different things**, and it's easy to read them as contradictory. The priority value sets the **order** in which Policies are applied — lower numbers go first, at the top of the Composition Set. When two of them configure the same setting, the Device keeps the value applied **last**, which is the one further down the set. In other words: a lower number means the Policy is applied earlier, not that its value survives a conflict. ::: **Apple** On **Apple Devices** (iOS, iPadOS, macOS), Policies are executed sequentially according to priority, with lower numbers taking precedence. For example, if three Policies toggle the same setting, the Device adopts the final state from the last Policy in the sequence. **Android** On **Android Devices**, the priority order is maintained similarly, but in case of conflicting settings, the most restrictive configuration takes effect. **Windows** On **Windows Devices**, Policies also execute sequentially, respecting the assigned priority order. This matters most when a [Custom ADMX Configuration](https://docs.applivery.com/en/device-management/windows/policies/admx-configs/) defines a registry path that a built-in Policy category already covers. Use **Preview** before saving to see which value the Device ends up with. #### Best practices When using Policy Composition, assign clear priority values to avoid conflicts and confusion. :::tip It is recommended to test compositions in a pilot group before deploying them broadly. ::: :::tip Regularly review audit logs to monitor Policy application and resolve any conflicts. ::: :::tip For better organization, use priority numbers below 100 for Automation Rules and above 100 for other Policy assignments, ensuring Automation Rules consistently take higher precedence. ::: --- ## Segments Source: https://docs.applivery.com/en/device-management/general-settings/segments/ Description: Segments in Applivery organize Devices hierarchically, delegate roles, and scope Policies for granular control and efficient scaling. TL;DR: Applivery Segments allow organizations to structure and manage devices hierarchically, delegate roles, and scope policies for efficient device management. Key topics: Segment Hierarchy, Role-Based Access Control, Policy Management, Device Assignment, Segment Creation, Applivery, Active Directory, LDAP, SAML Segments are a core structural component of Applivery Device Management. They allow organizations to replicate their real operational structure—such as regions, departments, stores, or business units—within the platform. Rather than being a simple filtering mechanism, **Segments** define administrative boundaries, visibility scope, and governance rules across Devices, Policies, resources, and automations. By using Segments, organizations can scale device management while maintaining strict control over who can access and modify specific parts of the environment. Through Segments, you can: - Organize Devices hierarchically. - Delegate roles and permissions with precision. - Scope visibility of Policies, resources, and automations. - Build complex deployment scenarios while maintaining strict governance. ### What is a Segment A Segment is a logical container used to group and structure Devices within a hierarchical tree. Segments can represent: - Geographic regions. - Organizational units. - Operational domains. Each Segment can have child Segments, forming a tree structure. This hierarchy enables inheritance of visibility and administrative scope from parent to child levels. ![segments](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/42952a00-c2fc-482d-b80e-22780900e9e8.png) #### Hierarchical structure Segments are organized in a parent-child structure. Administrators assigned to a higher-level Segment can manage all its descendant Segments, while administrators assigned to a lower-level Segment are restricted to that specific branch. For example, a regional administrator may have full control over all stores within their region. In contrast, a store-level administrator can only manage Devices, Policies, and configurations within that store. They cannot access or modify configurations defined at the regional or global level. This hierarchical model enables centralized governance with controlled decentralization. #### Segment-based role delegation Each Segment can define its own permission groups and assign roles such as **administrator**, **editor**, or **viewer**, or a [custom Collaborator role](https://docs.applivery.com/en/platform/roles-permissions/custom-collaborator-roles/) with exactly the actions each job needs. Users can be added to these groups individually or dynamically through identity provider integrations (such as SAML, LDAP, or Active Directory). This allows organizations to automate access control based on corporate directory attributes. Permissions are always scoped to the assigned Segment and its descendants. Users can only edit, view, or manage elements that fall within their authorized Segment scope. This ensures clear separation of responsibilities across distributed teams. :::info You can find more information about integrations with your **Active Directory** by following [this link](https://docs.applivery.com/en/platform/authentication/sso/saml/), or about the **LDAP open standard** by following [this link](https://docs.applivery.com/en/platform/authentication/sso/ldap/). ::: #### Segments across the Dashboard Segments apply consistently across the entire Device Management module. When working within a selected Segment in the Dashboard: - Devices are filtered according to that Segment. - Only Policies belonging to that Segment (and optionally its descendants) are visible. - Resources and Automation Rules follow the same scoping logic. Each element in the platform is associated with a specific Segment. This association determines who can manage it—not necessarily which Devices receive it. :::info It is important to distinguish between **administrative scope (defined by Segments)** and **Policy assignment logic (defined by automation and audiences)**. ::: #### Segments and device assignment Every Device belongs to a specific Segment. This assignment determines which administrators can manage the Device and which configurations are visible in its context. However, Segment membership does not automatically define which Policies a Device receives. Policy delivery is controlled through [Automation Rules](https://docs.applivery.com/en/device-management/general-settings/automation-rules/) and [Device Audiences](https://docs.applivery.com/en/device-management/general-settings/device-audiences/). Segments define who can configure those rules and Policies, not the final configuration outcome itself. This separation ensures operational flexibility while preserving governance boundaries. #### Policies and priorities Segments enable advanced deployment scenarios when combined with identity groups, Device Audiences, automation logic, and Policy priority. For example, a Device located in a specific store may inherit a global baseline Policy, a regional configuration, and a store-specific customization. If the Device is associated with a user belonging to a particular department, additional Policies may also apply. Policy priority ensures deterministic behavior in the event of configuration overlap. Segments define administrative ownership, while Policy priority defines technical resolution. #### Visibility and inheritance rules The following principles govern Segment behavior: - Higher-level administrators inherit visibility over lower-level Segments. - Lower-level administrators cannot modify parent-level configurations. - Editing rights are always restricted to the assigned scope. - Visibility can be limited to a specific Segment or expanded to include its descendants. This model supports enterprise-grade governance, making Segments especially valuable in large or distributed organizations. ### Inheritance scoping: blocking downward inheritance By default, configurations and visibility defined at a parent Segment propagate down through the entire hierarchy — all child and descendant Segments can see and be affected by what is defined above them. In most scenarios, this is the desired behavior, but there are cases where it is not. **Inheritance scoping** allows administrators to explicitly mark a Segment as a boundary that stops downward inheritance. When enabled on a Segment, configurations, Policies, and visibility defined within that Segment are contained to it — they do not propagate to child Segments below it. #### When to use inheritance scoping This is particularly useful in scenarios such as: - **Isolated business units**: A subsidiary or business unit that shares the platform but must operate independently, with no visibility into or from sibling branches. - **Sensitive data environments**: A Segment containing Devices or configurations with restricted access requirements, where sub-segments must not be able to access or inherit the parent's configuration. - **Franchise or multi-tenant structures**: Each franchise or tenant has its own Segment and should not be affected by Policies defined in a neighboring or parent Segment, beyond a global baseline set at the root level. - **Scoped delegations**: A scenario where an administrator has full control within a Segment, but that control must not cascade further than intended. #### How it works When inheritance scoping is enabled on a Segment: - Policies, resources, and configurations defined within that Segment are **not visible or applicable** to any Segment below it in the hierarchy. - Administrators assigned to child Segments of the scoped Segment **cannot access or inherit** what has been defined at the scoped level. - The scoped Segment itself continues to function normally — its administrators retain full visibility and control within their scope. - Higher-level (parent) administrators **retain visibility** over the scoped Segment as part of their broader scope, but configurations do not flow downward through it. > **Example:** Consider a hierarchy structured as Global → Region → Country → Store. If the Country Segment has inheritance scoping enabled, any configuration defined at the Country level will not propagate to Store-level Segments beneath it. Store administrators will only see and receive what is explicitly defined at their own Segment level or pushed directly to them, not what is configured at the Country level above. #### Inheritance scoping vs. role restrictions It is important not to confuse inheritance scoping with role-based access restrictions: | | Inheritance scoping | Role restriction | | --- | --- | --- | | **What it controls** | Whether configurations flow down the hierarchy. | Whether a user can access or edit a Segment. | | **Applied to** | The Segment itself. | Users within a Segment. | | **Effect on child Segments** | Stops the downward propagation of configurations. | No effect on configuration flow. | | **Use case** | Isolating configuration scope. | Controlling who can act within a scope. | Both mechanisms can and should be used together to achieve fine-grained governance in complex organizational structures. ### How to create Segments and Permissions **Create a Segment** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), navigate to the **Settings** 1 section. From the left side menu, select **Segments & Permission** 2 and click the **\+ Create child** button 3. ![create segment](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/579ae4ed-a54c-4694-91e1-2fb648d31b6e.png) A form will appear allowing you to define the Segment name, select an icon, choose a color, and preview how the Segment will appear within the hierarchy before saving it. **Create Permissions** Now, in the same section, click the **\+ Create permission** button 4. In the side modal that appears, you can **give the permission a name** and **assign a role**, either built-in or [custom](https://docs.applivery.com/en/platform/roles-permissions/custom-collaborator-roles/). From here, you can add segment administrators by **including groups** using `AND` or `OR` logic, or by entering **individual `users` email addresses** directly. ![create permission](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/c6807b1a-3d0b-4d2c-8377-4685bfc37b40.png) ### Best practices When designing your Segment structure: - Align it with real operational boundaries rather than temporary projects. - Keep global or baseline configurations at higher levels, and apply local customizations at lower levels. - Use identity-based group mapping whenever possible to avoid manual access management. Careful planning of the Segment tree significantly improves scalability, clarity, and long-term maintainability. --- ## Smart Attributes Source: https://docs.applivery.com/en/device-management/general-settings/smart-attributes/ Description: Smart Attributes are dynamic Device properties in Applivery MDM that enable automation, Segmentation, and Device Management across all platforms. TL;DR: Smart Attributes in Applivery MDM enable dynamic device management and automation through custom attributes and integration with Device Audiences. Key topics: Smart Attribute types, Smart Attribute configuration, Device Audience integration, Automation use cases, Applivery MDM, Android, iOS, macOS, Windows ### What are Smart Attributes and how do they work? **Smart Attributes** are dynamic Device properties that **enable advanced automation**, **segmentation**, and **Device Management** in Applivery MDM. They allow administrators to define custom attributes that can be assigned to Devices based on specific conditions, enabling sophisticated automation workflows and precise Device targeting. They provide a unified and flexible way to define, store, and manage Device-specific metadata across all supported platforms (Windows, Android, iOS, and macOS). Acting as an abstraction layer between raw Device data and higher-level features—such as **Policies**, **Automation**, and **Segmentation**—they allow administrators to work with consistent and reusable attributes regardless of the underlying operating system. Smart Attributes can be **OS-specific** (separate values for Android, iOS/macOS, and Windows) or **cross-platform** (single value applied across all platforms). They integrate directly with [Device Audiences](https://docs.applivery.com/en/device-management/general-settings/device-audiences/), allowing you to create dynamic Device groups based on attribute values. :::info Smart Attributes are segment-scoped, meaning they can be configured at the Workspace level (global segment) or within specific organizational segments ::: By combining static values, predefined selections, manual inputs, system variables, and script-based evaluations, Smart Attributes enable precise targeting and advanced conditional logic across your entire Device fleet. ### **Why Smart Attributes?** Managing Devices across multiple platforms often requires dealing with inconsistent data sources and OS-specific logic. Smart Attributes solve this by: - Standardizing how Device metadata is defined and consumed. - Enabling reusable and centralized logic for segmentation and automation. - Eliminating the need to duplicate platform-specific configurations. - Providing both static and dynamic data sources for maximum flexibility. This allows organizations to scale Device Management while maintaining consistency, control, and predictability. ### What types of Smart Attributes are available? Applivery MDM offers five distinct Smart Attribute types, each designed for different use cases. However, before understanding these types, it’s important to understand their source—that is, who or what provides the value of the attribute. Smart Attributes are defined based on this source, which determines how their values are created, updated, and maintained. #### Attribute sources - **IT Admin**: Values managed directly from the Dashboard. - **User**: Values provided by the end user through the Device Agent. - **Device**: Values automatically obtained from the Device. - **Constant**: Fixed values defined by administrators. #### Supported types by source | Source | Supported types | How it works | Use case | | --- | --- | --- | --- | | **IT Admin** | Manual, Enum | Values are defined in the Dashboard. Manual allows free input, while Enum restricts values to predefined options. | Store identifiers, department names, or locations. Standardize values such as Device tiers or compliance levels | | **User** | Manual, Enum | Values are provided by the end user through the Device Agent. | Collect contextual or user-provided data while ensuring consistency | | **Device** | Selector, Script | Values are automatically generated from the Device. Selectors retrieve system properties, while Scripts execute logic locally. | Dynamic Device properties, computed values, compliance checks | | **Constant** | Constant | Static value defined once by an administrator. | Baseline configurations, global settings | :::info The initial release supports all Smart Attribute sources except User. Support for the User source will be introduced in a future release, allowing end users to provide attribute values directly from the Device Agent. ::: This view helps quickly understand which combinations are possible when designing your Smart Attributes. | Source ↓ / Type → | Manual | Enum | Selector | Script | Constant | | --- | --- | --- | --- | --- | --- | | **IT Admin** | ✅ | ✅ | ❌ | ❌ | ❌ | | **User** | ✅ | ✅ | ❌ | ❌ | ❌ | | **Device** | ❌ | ❌ | ✅ | ✅ | ❌ | | **Constant** | ❌ | ❌ | ❌ | ❌ | ✅ | #### Update behavior The update frequency of Smart Attributes depends on how their values are generated. | Type | Update | Behavior | | --- | --- | --- | | **Manual (Admin/User)** | Manual input | Updated whenever the value is modified via Dashboard or Agent. | | **Enum (Admin/User)** | Manual selection | Updated whenever a new option is selected. | | **Selector** | System scheduler/Device updates | Re-evaluated dynamically every 15 minutes or when Device data changes. | | **Script** | Agent execution | Updated each time the script runs on the Device. | | **Constant** | System scheduler/Device updates | Updated every 15 minutes or when Device information changes. | #### Selector type details The **Selector** type uses interpolators to reference other Device properties or Smart Attributes: - **Initial version**: Supports interpolators and string operations. - **Future versions**: Will support advanced functions, including: - String manipulation (split, substring, concatenation). - Conditional logic. - Mathematical operations on numeric values. - Date/time calculations. ### How do I create and configure Smart Attributes? **View and manage existing Smart Attributes** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), navigate to **Automation** 1 and select **Smart Attributes** 2. In this section, you’ll find a table listing all existing attributes. This table provides a complete overview of each attribute, including its name, type, associated segment, scope, number of affected Devices, and last update timestamp. From here, you can also perform actions like editing, deleting, or viewing attribute details. To create a new attribute, simply click **\+ Create Smart Attribute** 3. ![Smart Attributes](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/82d00499-c343-4fe9-9452-3dfc31fdb6a5.png) **Select attribute type and scope** Start by selecting the Smart Attribute **source** from the available options. Each source includes a brief description to help you understand how it works and when to use it. Next, define the **input type** (how the value is provided or generated) and the **output type**, followed by the attribute scope: - **OS-specific:** Configure different values for each platform (Android, iOS/macOS, and Windows). - **Cross-platform**: Define a single value that applies consistently across all platforms. :::info When using an OS-specific scope, the system handles platform differences automatically in the backend while maintaining a unified configuration experience. ::: ![Smart Attributes form](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/c730468e-8fe5-4a52-b948-6254eaaeb495.png) **Configure attribute properties** Define the core properties of your attribute: - **Name**: The display name shown in the UI. - You can also include an optional **description** to clarify the attribute’s purpose. Depending on the selected scope: - For **OS-specific** attributes, provide values for each platform (Android, iOS/macOS, Windows). - For **cross-platform** attributes, define a single value that applies to all Devices. **Configure type-specific settings** Some attribute types require additional configuration depending on their behavior. - **Enum** attributes allow you to define a list of predefined options, ensuring consistent and structured data. - **Script** attributes require you to provide the script logic that will be executed on the Device. You can write or paste your script directly in the editor, use AI assistance if available, and test it before deployment. The script must return the value in the expected format in its final line. - **Selector** attributes use dynamic variables to retrieve Device or attribute data. These are defined using interpolators such as: `{{device.serial_number}}-{{device.model}}`. `{{smart_attribute.department}}-{{device.os_version}}`. **Define Device Assignment (optional)** Finally, you can decide how the Smart Attribute is assigned to Devices. You can assign attributes **manually** to specific Devices through the Device details view, or **automate** the process using **Device Audiences**, which dynamically assign attributes based on defined conditions. This flexibility allows you to apply attributes either on a case-by-case basis or at scale through automated targeting. ### How do Smart Attributes work with Device Audiences? Smart Attributes integrate seamlessly with **Device Audiences**, enabling dynamic Device segmentation based on attribute values. When creating or editing a Device Audience, you can use Smart Attributes as part of your filtering criteria to target Devices more precisely. #### Device Audience filter structure Device Audience filters follow this structure: **Attribute → Operator → Value** This allows you to define conditions based on Device properties, tags, or Smart Attributes. For example, you can: - Filter Devices by tags (e.g., location or department). - Use Smart Attributes to define conditions such as OS version or security status. - Combine multiple filters to build more advanced targeting logic. #### Example configurations 1. **Device Tag** filter: Devices that include specific tags such as _Madrid_ and _Barcelona._ 2. **Smart Attribute** filter: Devices where a Smart Attribute like _OS Version_ is greater than a specific value (e.g., 26.2). 3. **Combined filters**: You can combine multiple conditions, such as FileVault enabled (True AND), OS Version greater than 26.2 (OR), Devices tagged with Madrid. #### Logical operators between filters Understanding how filters are combined is key to building correct Device Audiences. - **AND logic** (within the same filter type)**:** When using multiple Smart Attribute conditions, all of them must be met. For example, a Device must have _OS Version > 26.2,_ **and** _FileVault must be enabled_. - **OR logic** (across different filter types)**:** Different types of filters (e.g., Device Tags vs Smart Attributes) are evaluated independently, and a Device can match if it satisfies any of those groups. - **Device Tags behavior:** Device Tags use the **“Includes (has all)”** operator, meaning the Device must contain all specified tags to match. #### Available operators by attribute type Operators vary based on the Smart Attribute data type: | Data Type | Available Operators | | --- | --- | | **Text/String** | Equals, Not equals, Contains, Not contains, Starts with, Ends with. | | **Number** | Equals, Not equals, Greater than, Less than, Greater than or equal, Less than or equal, Between. | | **Boolean** | Equals, Not equals. | | **Date** | Equals, Not equals, Before, After, Between. | | **Enum** | Equals, Not equals, In list, Not in list. | #### Understanding filter logic The Device Audience interface provides a visual formula that represents how your filters are evaluated: ``` (device_tag includes "Madrid" OR device_tag includes "Barcelona") AND (smart_attribute.os_version > 26.2 AND smart_attribute.filevault = true) ``` This representation helps you clearly understand how conditions are applied and ensures that your targeting behaves as expected. ### What are common use cases for Smart Attributes? Smart Attributes support a wide range of scenarios: - **Static tagging:** Assign fixed metadata like office location or business unit. - **Dynamic data extraction:** Retrieve system-level information automatically. - **Custom calculations:** Generate values using scripts (e.g., compliance status). - **Standardized inputs:** Enforce consistent values using enums. - **Manual data entry:** Capture information not available programmatically. --- ## Get Started Source: https://docs.applivery.com/en/device-management/getting-started/ Description: Navigate the Applivery Device Management Dashboard, enroll Devices, configure Policies, and automate Device Management workflows. TL;DR: This guide introduces the Applivery Device Management dashboard and its features for managing Apple, Android, and Windows devices. Key topics: Applivery Dashboard Overview, Device Enrollment, Policy Configuration, Resource Management, Automation Workflows, Applivery, Apple, Android, Windows, bash, PowerShell Applivery provides a **unified platform to manage Apple, Android, and Windows Devices** in corporate environments. From Enrollment to Policies, Automation, and Resources, administrators can centrally control every aspect of Device Management. ### How to create an account in Applivery **Account data** ![Account data](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/c2e556e7-f021-4dac-bcc5-8df3db479c09.png) Go to https://dashboard.applivery.io/welcome/register and complete the registration form with your details. **Validate your email** ![Validate your email](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/0d4fd017-ec2b-48d8-9997-3e0d4f9cdfb6.png) Verify your email address to activate your account (required for security purposes). **Set up your Workspace** ![Set up your Workspace](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/7ff9efd2-62a9-4cd3-8246-700897580c65.png) Set up your Workspace. You can modify the name and URL at any time, but using your company name is recommended as a best practice. **About you** ![About you](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ecb1a78f-5667-48d3-a66c-2a44471cb3c4.png) Tell us about you **Welcome 👋** ![Welcome 👋](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/a9a41c1a-3232-4075-b1de-96ea790fc984.png) Welcome to the Applivery Dashboard ### Accessing the Applivery Dashboard To start managing your Devices, log in to the [**Applivery Dashboard**](https://dashboard.applivery.io). Users with access are called **Collaborators** and have different permissions depending on their role. This ensures that tasks like Device Enrollment, Policy assignment, and automation can be delegated while maintaining security and operational control. Getting started with Applivery is straightforward. Once your Workspace is created, you can immediately begin enrolling and managing your Devices. #### The Dashboard The **Device Management Dashboard** is organized into dedicated sections that allow administrators to monitor, enroll, configure, and automate Device management across the organization. From high-level fleet visibility to granular Policy configuration, the Dashboard centralizes all Device operations into a structured and role-based interface.**Overview** The **Overview** section 1 is the first screen in your Workspace and provides key metrics to quickly assess your Device fleet. Here you can find information about: - Total number of enrolled Devices. - Device status (active, inactive, or disabled). - Most used models and OS versions. - Battery levels. - Compliance status. These metrics allow administrators to detect trends, identify potential issues, and make data-driven decisions regarding Device Management. ##### Devices The **Devices** section displays all Devices currently enrolled in your Workspace. Devices are listed according to segments created by Workspace administrators. Access to Devices is controlled based on the segment permissions assigned to each Collaborator. From this view, users can: - Enroll new Devices (Apple, Android, or Windows). - Execute bulk actions, such as Policy assignments or remote Commands. :::info For detailed guidance on enrolling Devices, refer to the dedicated Apple, Android, and Windows Enrollment documentation. ::: ![Devices section](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/9de1d323-0c4b-4d1c-8cbb-eb6f927a3f4d.png) ##### Policies A **Policy** is a collection of configurations that defines how a Device behaves once it is managed. Depending on the platform, a Policy may include: - System restrictions and security settings (passcodes, encryption). - Application installation rules. - Scripts or automated actions. - Integrations with security services. - Kiosk mode settings. The Policies section lists all Policies available to your account. As with Devices, visibility and access to Policies depend on your Workspace segment permissions. From here, administrators can create new Policies or modify existing ones. :::info Learn how to create a new Policy in our dedicated [Policy documentation article](https://docs.applivery.com/en/device-management/general-settings/create-policies/). ::: ![Policies section](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/20acb7cf-cac8-4818-9858-fa5c43e3cc21.png) ##### Resources The **Resources** section centralizes all deployable assets used across your Device Management workflows. These Resources can be: - **Apps**: Deploy custom-built or third-party applications to ensure Device Employees have access to the tools they need. Supported formats include `.ipa`, `.pkg`, `.msi`, `.msix`, `.appx`, and `.apk`. This enables secure enterprise distribution of internal Apps, line-of-business tools, and approved external software across managed Devices. - **Scripts**: Automate operational tasks and system configurations by deploying **bash** scripts for macOS and **PowerShell** scripts for Windows. Scripts can be used for software installation, system configuration changes, remediation actions, compliance enforcement, or maintenance tasks. - **Books**: Distribute documentation and digital content in multiple supported formats, including `.pdf`, `.epub`, `.rtf`, `.rtfd`, `.txt`. :::info Books are only available for **iOS Devices**. For Shared iPad environments, books can only be assigned to **user accounts**, not directly to Devices. ::: - **Images**: Deploy image files in `.jpg` and `.png` to your Apple and Windows Devices. Images can be used for branding, kiosk configurations, lock screen customization, or internal content distribution. - **Certificates**: Secure Device communications and authentication by deploying digital certificates. Supported formats include `.p12`, `.der`, `.pem`, `.crt`, `.cer`. Certificates are essential for Wi-Fi authentication, VPN access, email security, and secure application communication. - **Certificate providers**: Configure them to automate certificate issuance and lifecycle management. This allows Devices to dynamically request and renew certificates through integrated identity or certificate authorities, improving security and reducing manual administrative overhead. :::info You can read more about Resources in the following [link to our documentation](https://docs.applivery.com/en/device-management/general-settings/distribute-resources/). ::: ![resources section](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/2fd67f25-4a08-45e3-9fa3-db6bad7a7347.png) ##### Automation The **Automation** section is organized by operating system and allows administrators to streamline Device lifecycle management through automated workflows: - **Smart Enrollments**: They allow you to automate the Device Enrollment process based on predefined rules and conditions. You can define criteria that Devices must meet during Enrollment and automatically assign the appropriate Policies based on those conditions. This ensures Devices are configured correctly from the very beginning, without manual intervention. :::info For detailed guidance on Smart Enrollments, refer to the dedicated Apple, Android, and Windows documentation. ::: - **Device Audiences**: They allow administrators to create dynamic groups of Devices based on specific attributes such as operating system, compliance status, model, or custom criteria. These audiences make it easier to target specific subsets of Devices for configurations, Policies, or deployments. To learn more about Device Audiences, refer to [our documentation](https://docs.applivery.com/en/device-management/general-settings/device-audiences/). - **Automation Rules**: They allow administrators to automatically execute actions when certain conditions are met. Each rule is linked to a Device Audience. When a Device matches the defined criteria, one or more predefined actions—such as Policy assignments, App deployments, or configuration updates—are automatically triggered. This enables dynamic, large-scale Device Management without requiring manual operations. To learn more about Automation Rules, refer to [our documentation](https://docs.applivery.com/en/device-management/general-settings/automation-rules/). ![automation secion](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/55c896cc-d231-42ac-b2b4-2ec8137e9d45.png) These features allow IT teams to reduce manual tasks, maintain compliance, and ensure Devices are configured consistently across the fleet. ##### Directory and Configuration The **Directory and Configuration** section centralizes identity management, access control, Workspace segmentation, and operating system–specific settings within Applivery’s Device Management environment. This section ensures that administrators can securely control who manages Devices, which Devices they can access, and how platform-specific configurations are applied across the organization. - **Collaborators**: Users with access to the Applivery Dashboard. They can be assigned granular roles and permission levels depending on their operational responsibilities, such as full administrative control, Device management permissions, Policy creation and modification, and read-only access. Role-based access control (RBAC) ensures operational security by limiting access to sensitive Device actions and preventing unauthorized configuration changes. - **Device Employees**: End users who have one or more Devices assigned to them. These users represent the human layer of your Device fleet and are essential for Device ownership tracking, compliance association, Policy targeting, and Resource assignment (Apps, configurations, Books, etc.). - **Segments & Permissions**: Segments allow administrators to logically divide the Workspace into structured groups for granular control. They can be used to restrict Collaborator access to specific subsets of Devices, isolate environments (e.g., departments, regions, subsidiaries), control visibility of Policies and Resources, and delegate management responsibilities securely. Permissions are enforced based on segment membership, ensuring that administrators only manage the Devices and configurations relevant to their scope. This structure is critical for large-scale or multi-entity deployments. - **Operating system configurations**: This section also includes platform-specific configuration settings for each supported operating system (Apple, Android, and Windows). Depending on the platform, administrators can configure Enrollment methods and platform integrations. :::tip You can find more information about user types in the following article from [our documentation](https://docs.applivery.com/en/device-management/getting-started/manage-users/). ::: ![settings section](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/e9222326-767b-4d7d-b7e0-616e6892d98c.png) --- ## Main Concepts Source: https://docs.applivery.com/en/device-management/getting-started/main-concepts/ Description: Core Device Management concepts in Applivery — Workspaces, Devices, Enrollment, Policies, Automation Rules, and compliance explained. TL;DR: Learn the core concepts of Applivery's Device Management, including workspaces, enrollment, policies, and automation rules, to effectively manage and secure your devices. Key topics: Workspaces, Device Enrollment, Device Policies, Automation Rules, Compliance, Applivery, Apple, Android, Windows As an introduction to Applivery’s Device Management, we highly recommend you explore and understand the following basic concepts that will be explained in detail in the following chapters of the documentation since they represent the very basic concepts of our platform. ### Workspaces A **Workspace** is the organizational environment where Devices, Policies, resources, Automation Rules, and administrators are managed. Each Workspace operates independently and contains its own configuration, segmentation model, and access control structure. ### Device A **Device** is any enrolled Apple, Android, or Windows endpoint managed through Applivery. Once enrolled, a Device can receive Policies, applications, scripts, configurations, and security settings defined by administrators. ### Enrollment **Enrollment** is the process of registering a Device into Applivery’s management system. During enrollment, the Device establishes trust with the platform and becomes eligible to receive configurations, Policies, and automated actions. Enrollment methods vary depending on the operating system and organizational setup. ### Smart Enrollment **Smart Enrollment** automates the enrollment process by applying predefined rules and conditions. Devices that meet specific criteria can automatically receive Policies and configurations during enrollment, ensuring standardized setup without manual intervention. ### Policy A **Policy** is a structured collection of configurations that define how a managed device behaves. Depending on the operating system, Policies may include: - Security restrictions. - Passcode and encryption requirements. - Application management rules. - Network configurations (Wi-Fi, VPN, email). - Kiosk mode settings. - System restrictions. Policies enforce compliance and operational standards across Devices. ### Device Audience A [**Device Audience**](https://docs.applivery.com/en/device-management/general-settings/device-audiences/) is a dynamic group of Devices automatically generated based on predefined conditions (such as OS version, compliance status, model, or custom attributes). Device Audiences update automatically as Devices meet or no longer meet the defined criteria, enabling scalable targeting for automation and policy assignments. ### Automation Rule An [Automation Rule](https://docs.applivery.com/en/device-management/general-settings/automation-rules/) is a rule-based mechanism that automatically triggers actions when a Device matches the conditions of a Device Audience. Actions may include: - Assigning Policies. - Deploying Apps or scripts. - Updating configurations. Automation Rules enable dynamic lifecycle management without manual execution. ### Segment A [**Segment**](https://docs.applivery.com/en/device-management/general-settings/segments/) is a structural division within a Workspace that enables granular administrative control. Segments restrict visibility and management permissions, ensuring that administrators can only access the Devices, Policies, and resources assigned to their scope. This is especially important in multi-department or multi-entity environments. ### Resource A [**Resource**](https://docs.applivery.com/en/device-management/general-settings/distribute-resources/) is any deployable asset that can be assigned to Devices, either manually or through Policies and automation. Resources may include: - Applications. - Scripts. - Books. - Images. - Certificates. - Certificate Providers. Resources extend device functionality and enable secure configuration management. ### Compliance Status **Compliance Status** indicates whether a Device meets the security and configuration standards defined by assigned Policies. Devices may be marked as compliant or non-compliant depending on factors such as encryption status, passcode requirements, OS version, or [security posture](https://docs.applivery.com/en/device-management/android/security-posture/). Compliance monitoring helps enforce corporate security standards. See [Compliance checks](https://docs.applivery.com/en/device-management/general-settings/compliance-checks/) for how to read the result on an individual Device. ### Directory The **Directory** centralizes the management of: - Collaborators (Workspace administrators). - Device Employees (end users). - Access control and segmentation. It defines who can manage Devices and how Devices are associated with users within the organization. :::tip You can find more information about user types in the following article from [our documentation](https://docs.applivery.com/en/device-management/getting-started/manage-users/). ::: --- ## Manage Users Source: https://docs.applivery.com/en/device-management/getting-started/manage-users/ Description: Applivery organizes users into Collaborators (admins) and Device Employees (end users) — enabling precise access control and targeted policies. TL;DR: Learn how to manage users (Collaborators and Device Employees) in Applivery Device Management with access control, device audiences, and activity tracking for enhanced device security. Key topics: Collaborator Management, Device Employee Management, Device Audiences and Segments, User Activity Tracking, Applivery User Roles, Applivery, Collaborators, Device Employees, Device Audiences, Segments, Applivery Dashboard Effective user management is essential for securing and organizing corporate Devices. Applivery provides a centralized interface to manage both administrators (Collaborators) and end users (Device Employees) with precise access control. In Applivery Device Management, there are two main categories of users: **Collaborators** and **Device Employees**. ### Collaborators Collaborators are team members who manage Devices and Workspace configurations via the Applivery Dashboard. What each Collaborator can do depends on the role assigned to them on their [Segment permissions](https://docs.applivery.com/en/device-management/general-settings/segments/#how-to-create-segments-and-permissions). Besides the built-in Admin, Editor and Viewer roles, you can create [custom Collaborator roles](https://docs.applivery.com/en/platform/roles-permissions/custom-collaborator-roles/) with just the actions each job needs. ![mdm Collaborators](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/5cf3e09a-ded8-422d-9917-559cc07046b3.png) ### Device Employees Device Employees represent end users assigned to managed Devices. They can be grouped and assigned Policies, Apps, or configurations. ![mdm Device Employees](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ea6d02de-aac9-471e-8bc6-d1b01569dec6.png) ### Device Audiences and Segments Device Management allows administrators to define audiences and segments to organize Devices and users for targeted Policies and deployments. - [**Segments**](https://docs.applivery.com/en/device-management/general-settings/segments/): Static collections of Devices or users for access control. - [**Device Audiences**](https://docs.applivery.com/en/device-management/general-settings/device-audiences/): Dynamic groups that automatically adjust based on device attributes or criteria. This helps ensure that Policies, Apps, and scripts are deployed to the correct users without manual intervention. ### User activity overview Applivery tracks activity for Collaborators to monitor usage and Workspace engagement. The system records: - Logins update both the last login and last action timestamps. - Other actions (policy changes, device management tasks, etc.) update the last action timestamp. :::info Activity tracking **does not apply to Device Employees,** as they do not have access to the Dashboard. ::: #### Best Practices - Use Device Audiences for dynamic management of large fleets. - Monitor Collaborator activity regularly to identify inactive accounts or potential misconfigurations. - Ensure that new Device Employees or Collaborators are assigned the appropriate segments and permissions for their responsibilities. ### How to invite your team Once in the [**Applivery Dashboard**](https://dashboard.applivery.io), navigate to the **Settings** section 1 and, in the left-hand menu under the **Directory** section 2, select the type of user you want to add. ![add users](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/22eddd09-883e-4e43-be7c-52947d724d5b.png) #### Invitation flow​ When you invite a Collaborator to join your team, they will receive an email invitation to register. In contrast, creating a Device Employee does not trigger an invitation, as these users are nominal end users tied directly to enrolled Devices. ##### Collaborators When inviting a new Collaborator to your Workspace: **Invitation Email** The user receives an email invitation to join Applivery. Their email address is pre-filled in the registration form. **Registration** After registering, they receive a second email to verify their email address. **Verification** Once verified, they are redirected to the login page to enter the credentials they just created. **Dashboard Access** Finally, they can access the Dashboard and will only see the Workspace Segments they have been assigned to. ![Collaborators invitation flow](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/9952e706-cf25-4abe-b29e-925129f9c67d.png) ##### Device Employees Device Employees are a logical entity used to group Devices. Each Device Employee is identified by an email address, which does not require confirmation. You can use real emails or generic ones to represent individuals, teams, departments, or locations. --- ## Integrations Source: https://docs.applivery.com/en/device-management/integrations/ Description: Device Management Integrations in Applivery — SSO, SCIM, notifications, and security integrations for centralized authentication and compliance. TL;DR: Applivery integrates with Okta and Google Workspace for simplified SSO and user provisioning, enhancing device management security. Key topics: SSO, user provisioning, Applivery integrations, Okta, Google Workspace, Applivery Applivery Device Management integrates with external tools and platforms to extend its capabilities. This includes SSO and identity providers for centralized authentication, security solutions for Mobile Threat Defense, and notification services to keep your team informed. Device Management integrations are organized by type: SSO, Security, and Notifications. --- ## Notifications Source: https://docs.applivery.com/en/device-management/integrations/notifications/ Description: Device Management Notifications in Applivery — stay informed with Slack, webhooks, and real-time alerts for Device and Certificate events. TL;DR: Applivery notifications integrate with Slack and webhooks to provide real-time alerts and visibility for device management activities. Key topics: Applivery notifications, Slack integration, webhook integration, device management alerts, Applivery, Slack, webhooks, Device Management Notification integrations let you stay informed about Device Management activity in real time. You can connect Applivery to Slack to receive alerts in your channels, or configure custom webhooks to push events to any external service. Set up and configure each notification integration available for Device Management. --- ## Slack Source: https://docs.applivery.com/en/device-management/integrations/notifications/slack/ Description: Integrate Applivery with Slack to receive instant notifications for Device enrollments, certificate expirations, and inventory updates. TL;DR: Integrate Applivery with Slack to receive real-time notifications about device enrollments, certificate expirations, and other key events. Key topics: Slack integration, Applivery notifications, Device management alerts, Workspace settings, Integration configuration, Applivery, Slack, Apple Push Certificate ![applivery-slack-macIphone | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/8e0ca2d7-921c-47eb-b6f9-0d4b32d04df1.png) Now you can integrate Applivery with Slack and start receiving notifications when the following events take place: - A new **Enrollment Token** has been created. - A new **Device** has been successfully enrolled. - A **Device Employee** has been assigned to or changed on a Device. - The **Apple Push Certificate** is about to expire. - A new **Inventory item** has been registered. Integrating Applivery in your Slack team is quite simple thanks to our Official App, and the configuration will take you less than 1 minute. Just follow the next steps. ### Getting started Slack integration can be configured at the **Workspace** level, so notifications from all Devices and enrollment activity within your organization are sent to a specific `#channel` or `@user`. **Navigate to Integrations** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), go to your Workspace Settings 1 from the top dropdown menu, then open Integrations 2 in the left-hand menu and click the + Create integration 3 button. ![integrations](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/a4fd9792-8503-4f69-96d2-920a820650b9.png) **Slack events** Choose the **Slack** option, select the events you want to receive from the list and then click **Add to Slack** button. ![slack integration](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/64bf647b-46bd-4f8b-8203-e88d90f37717.png) **Authorize the integration** Now it’s time to sign into your team, so you’ll need to enter your **Slack account email address** and **Slack password**. After that, select where the messages from Applivery should be posted using the bottom drop-down menu that will display the list of available users and channels under your Slack team. Once done, click **Allow** button. ![slack-step4-1 | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/92f790ba-de74-448d-9a6a-aee13fa8274c.png) **Manage Slack integrations** You will be automatically redirected to the **Integrations** section, where the new Slack integration should be listed, including all the details you have selected: - **Type:** Slack. - **Configuration:** `#channel` or `@user` that will receive the messages. - **Events:** list of events that will be notified. ![slack-step4-1 | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/92f790ba-de74-448d-9a6a-aee13fa8274c.png) That’s all! You’ll be automatically redirected back to Applivery, and we’ll start sending notifications to your Slack team immediately. **Update Slack integration settings** You can edit your current Slack Integrations at any time by going to the **Integrations section** of your **Workspace** and then clicking one of your existing Slack Integrations. A side panel will be opened, allowing you to choose which events will be posted to your `@users` or `@channels`. You will be able to also delete the integration by clicking the **Delete** button. ![slack integration notifications](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/16a8bb97-6804-4148-8909-88126ba060ef.png) #### Notification examples ![new-Builds-messages | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/99ca45b9-c2b3-439b-86a2-999d16107ab0.png) ![new-feedback-messages | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/265daebc-72c2-4c22-9355-b8cca6b0bbb7.png) **Custom Webhooks** Learn how to configure custom webhooks for advanced integration scenarios. --- ## Custom Webhooks Source: https://docs.applivery.com/en/device-management/integrations/notifications/webhooks/ Description: Connect Applivery Device Management with external services using webhooks — real-time notifications for Device Enrollment, Certificate expiration, and more. TL;DR: Integrate Applivery with webhooks to receive real-time notifications about device management events like enrollment, certificate expiration, and inventory changes. Key topics: Webhook configuration, Event payloads, Device management events, Integration management, Applivery, HTTP POST, JSON, Apple Push Notification service (APNs), ITSM platforms ![webhooks](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/a78842cc-a70c-4563-8b35-9740ae11e2d1.png) Integrate Applivery with external services using custom webhooks to receive real-time notifications about key Device Management events. Webhooks allow you to connect Applivery to any external service that accepts HTTP POST requests — ITSM platforms, custom dashboards, automation tools, and more. When a relevant event occurs in Applivery, a JSON payload is sent automatically to the URL you configure. For Device Management, the following events can trigger a webhook notification: - A new **Enrollment Token** has been created. - A new **Device** has been successfully enrolled. - A **Device Employee** has been assigned to or changed on a Device. - The **Apple Push Certificate** is about to expire. - A new **Inventory item** has been registered. ## Getting started Webhook integrations can be configured at the **Workspace** level, so notifications from all Devices and enrollment activity within your organization are sent to the configured URL. **Navigate to Integrations** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), go to your **Workspace Settings** 1 from the top dropdown menu, then open **Integrations** 2 in the left-hand menu and click the **\+ Create integration** 3 button. ![integrations](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/f35947b0-3416-4397-b188-4469361632d7.png) **Configure the Webhook** 1. Select **Webhook** as the integration type. 2. Enter the **URL** that should receive the webhook payloads. 3. Select the **events** you want to subscribe to from the list. 4. Click **Save**. ![device management webhook](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/abce7f4c-69a6-43ba-867b-035d5ca77964.png) ### Managing Webhook Integrations After saving, you will be redirected to the Integrations section, where your new webhook is listed with a summary of its configuration: - **Type:** Webhook. - **Configuration:** The destination URL. - **Events:** The list of subscribed events. #### Editing a Webhook Just click on an existing webhook integration. A side panel will open where you can update the destination URL and the subscribed events. #### Deleting a Webhook Open the webhook integration and click the **Delete** button in the side panel. ### Event Payloads All webhook notifications are delivered as HTTP POST requests with a JSON body. Use the `action` field to identify the event type and route your processing logic accordingly. The `{os}` prefix in some action names is replaced at runtime by the platform identifier — for example `emm` for Android or `win` for Windows. _[Accordion]_ Fired when a new MDM Enrollment token has been created."> ```json { "action": "emm_enrollment_token_created", "sendEmail": true, "enrollmentToken": { "type": "Fully Managed" }, "mdmUser": { "id": { "id": "5e9099ee4da32b180204770e", "email": "[email protected]" }, "email": "[email protected]", "url": "https://dashboard.applivery.io/test/mdm/users/5e9099ee4da32r180204770e" }, "organization": { "id": "5d4d1391cd523c15f50df235", "name": "Applivery Test", "url": "https://dashboard.applivery.io/test" } } ``` :::info The `enrollmentToken.type` field indicates the management mode — for example, `Fully Managed` or `Work Profile`. ::: _[Accordion]_ Fired when a new Device has been successfully enrolled in Applivery."> ```json { "action": "emm_device_enrolled", "organization": { "id": "5d4d1391cd523c15f50df235", "name": "Applivery Test", "url": "https://dashboard.applivery.io/test" }, "emmDevice": { "type": "Fully Managed", "url": "https://dashboard.applivery.io/test/mdm/users/5e9099ee4da32b180204770e?id=5f634c11034824062256e38c" }, "mdmUser": { "id": "5e9099ee4da32b180204770e", "email": "[email protected]", "url": "https://dashboard.applivery.io/test/mdm/users/5e9099ee4da32b180204770e" } } ``` _[Accordion]_ Fired when a Device Employee has been assigned to or changed on a managed Device."> ```json { "action": "win_device_added_mdm_user", "organization": { "id": "5c34ec7810399b6cc062a04a", "name": "Applivery Test", "url": "https://dashboard.applivery.io/test" }, "winDevice": { "productName": "", "url": "https://dashboard.applivery.io/test/mdm/users/65f83a5e4ecbfd693b7486d6?id=66d05845114a9509d18e7266" }, "mdmUser": { "id": "65f83a5e4ecbfd693b7486d6", "email": "[email protected]", "url": "https://dashboard.applivery.io/test/mdm/users/65f83a5e4ecbfd693b7486d6" }, "trigger": "deviceUpdate" } ``` :::info The `trigger` field indicates what caused the user assignment — for example, `deviceUpdate`. ::: _[Accordion]_ Fired when the Apple Push Notification certificate (APNs) is approaching its expiration date. This certificate is required for Apple MDM to function. Renewing it before it expires is critical to maintaining Device Management on iOS, iPadOS, and macOS Devices."> ```json { "action": "apple_push_certification_renovation", "organization": { "id": "5d4d1391cd523c15f50df235", "name": "Applivery Test", "url": "https://dashboard.applivery.io/test" }, "numDays": "5", "appleId": "[email protected]" } ``` :::info The `numDays` field indicates how many days remain before the certificate expires. The `appleId` field identifies the Apple ID used to create the certificate. ::: _[Accordion]_ Fired when a new item is registered or updated in the Inventory. "> ```json { "action": "A new InventoryItem is being registered", "subAction": "created", "organization": { "id": "5d4d1391cd523c15f50df235", "name": "Applivery Test", "url": "https://dashboard.applivery.io/test" }, "inventoryItem": { "id": "62bd71d980df8b001b085ceb", "type": "monitor", "members": { "type": "mdmUser", "memberId": "6241d3d804e388001b3c605c", "email": "[email protected]" }, "metadata": {} } } ``` :::info Use the `subAction` field to determine the specific operation performed on the inventory item — for example, `created`, `updated`, or `deleted`. ::: ### Event Reference | Action | Trigger | | --- | --- | | `{os}_enrollment-token_created` | A new MDM Enrollment token has been created. | | `{os}_device_enrolled` | A Device has been successfully enrolled. | | `{os}_device_added_mdm_user` | An MDM user has been assigned to or changed on a Device. | | `apple_push_certification_renovation` | The Apple Push Certificate is approaching expiration. | | `A new InventoryItem {action}` | An item has been registered or updated in Inventory. | --- ## Security Source: https://docs.applivery.com/en/device-management/integrations/security/ Description: Explore Applivery's security features for device protection, communication security, and compliance. Integrate Check Point & Threema. Centralized dashboard. TL;DR: Applivery enhances device security and compliance through integrated solutions and a centralized dashboard. Key topics: device security, compliance, integrated security solutions, Applivery, Check Point Harmony Mobile, Threema Work Security integrations let you extend Applivery's Device Management with third-party protection tools. Currently supported integrations include Check Point Harmony Mobile for Mobile Threat Defense and Threema Work for secure enterprise messaging. Connect each security integration with Applivery and configure it within your Policies. --- ## Check Point Harmony Mobile Integration Source: https://docs.applivery.com/en/device-management/integrations/security/checkpoint-harmony-mobile-integration/ Description: Integrate Check Point Harmony Mobile with Applivery for advanced mobile threat defense on Android and Apple Devices. TL;DR: Integrate Check Point Harmony Mobile with Applivery to enhance mobile security through real-time threat detection and centralized policy management. Key topics: Applivery integration, Check Point Harmony Mobile configuration, Android device setup, iOS device setup, Mobile threat defense, Check Point Harmony Mobile, Applivery, Android Enterprise, Harmony Mobile Protection App [CheckPoint Harmony Mobile](https://www.checkpoint.com/harmony/mobile-security/) integrates seamlessly with Applivery to deliver advanced mobile threat defense and comprehensive Device security. This solution offers real-time malware detection, phishing protection, and network security monitoring, ensuring that corporate Devices are continuously safeguarded from emerging threats. With Harmony Mobile and Applivery integration, administrators gain a unified console to monitor Device risk levels, categorize Devices dynamically into groups based on threat severity, and apply tailored security Policies accordingly. The integration supports Zero-touch deployment, enabling the automatic installation and activation of the Harmony Mobile Protect App across large fleets without user intervention. ### In the Applivery Dashboard Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), go to your **Workspace Settings** 1 from the top dropdown menu, then open **Integrations** in the left-hand menu and enable **Check Point Harmony Mobile** 2. ![checkpoint](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/93a2c2f8-e259-4b95-a684-810158c67c6d.png) To begin the integration, type or paste the **Portal Account ID** from the [Harmony Mobile Portal](https://portal.checkpoint.com/signin). You can find this by going to **Settings > General > Account ID**. Once you’ve entered it, click Next step. Applivery will display all the information you need to enable the integration on the Harmony Mobile Portal. ### In the Harmony Mobile Portal Go to **Settings**, select **Integrations** from the left-hand menu, and add a new integration (you can temporarily select Hexnode until Applivery appears as an option). Alternatively, you can access it directly from [this link](https://portal.checkpoint.com/dashboard/mobile/harmonymobile#/settings/integrations). In the integration form, enter a **Display Name** of your choice, and fill in the **Server Address**, **Username**, and **Password** provided in your Applivery Dashboard. Once done, click **Verify**, and after successful verification, click **Next** to continue. ![server-details | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/4841973b-84bd-47e3-8d59-ecf9b8d2be42.png "server-details | Applivery") Once the groups finish loading, those associated with your Devices will be added automatically. Note that in Harmony Mobile, **groups correspond to tags** in Applivery, so **tags must be assigned to Devices in Applivery** for them to appear in the Harmony Mobile group list. :::info The Android Enterprise groups field in the UEM integration is used to manage and protect Android Devices that include both Work and Personal Profiles, allowing you to apply different Policies to each profile. This configuration is particularly useful when working with UEM solutions that support Android Enterprise. For more details, you can refer to the [Using Android Enterprise with Harmony Mobile](https://sc1.checkpoint.com/documents/Infinity_Portal/WebAdminGuides/EN/Harmony-Mobile-Integration-Guide/Topics-Integration-Guide/Citrix-Endpoint-Management/Using-Android-Enterprise-with-Harmony-Mobile.htm#_Ref40278689) guide. ::: ![sync | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/afc343ae-fa23-4702-b1af-7c87f001157c.png "sync | Applivery") Next, copy the **token** provided in the final step of the integration and paste it into the corresponding field in the Applivery Dashboard. ![token | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ac4966ac-efe2-42c0-b43f-ac9a7d430792.png "token | Applivery") Once this is completed, your Devices will start appearing in the **Devices** section of the Harmony Mobile Portal. Keep in mind that until a Device is fully provisioned, its information may appear empty. ### Configuration for Android Devices **Enable Check Point Harmony Mobile** In the [**Applivery Dashboard**](https://dashboard.applivery.io/), go to any of your **Policies**. From the left side menu, open the **Security** section and enable **Check Point Harmony Mobile**. ![checkpoint integration](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/08e4a155-f6f9-4bc6-9842-089cd3334ea4.png) **Configure Always On VPN** For Check Point Harmony Mobile to work correctly, you need to configure Always On VPN using the Harmony Protect app’s package name. This ensures the VPN remains continuously active and all device traffic is protected at all times. Within the policy, go to the **Network** section from the left-hand menu and locate the **Always On VPN** configuration. In the **Package Name** field, enter: `com.lacoon.security.fox` **Add the Harmony Mobile Protection app** Go to the **Apps** section and click the **\+ Add App** button. Add the **Harmony Mobile Protection** app. Once selected, its managed properties will automatically appear: - The **MDM UUID** (using interpolations, retrieved from the device’s network summary under UDID). - The **GW Address** and **Infinity Portal Account ID** (both found in the Harmony Mobile Portal settings). - The **Token**, which you’ll get from the last step of the integration, is usually added automatically. ![harmony app](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/eb66541c-dcd8-4d8b-9778-8f49f44b8e91.png) **Complete setup on the device** Open the app on the device and complete the setup process. Once the integration is active, any new alerts will appear in the portal as they occur. ### Configuration for Apple Devices **Configure the VPN payload** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), go to any of your **Policies**. Click **\+ Add configuration**, select the **VPN** payload type, and configure the following fields:

Field

Value

User Defined Name

Check Point Local Tunnel

Account Username (under VPN)

{{device.serialNumber}}

Authentication Method (under VPN)

Certificate

Remote Address (under VPN)

www.checkpoint.com

VPN Subtype

com.checkpoint.capsuleprotect

Type

VPN

Vendor Config

{ "zero_touch": "true" }

Then **Enable VPN On Demand** (`1`) and add the following On Demand Rules:

On Demand Action

Interface Type Match

Connect

Wi-Fi

Connect

Cellular

Optionally, add a third rule with **Connect** + **Ethernet** to cover wired connections. **Add the Harmony Mobile Protection app** Add the **Harmony Mobile Protection** app to your Policy, ensuring you have enough [VPP licenses](https://docs.applivery.com/en/device-management/apple/app-management/vpp/) available. Configure the required parameters in the configuration field: - `Lacoon Server Address`: `eu-gw.locsec.net` - `Device Serial Number`: `{{device.serialNumber}}` - `token`: Use your token here. - `ios_dep_notification_permission`: `true` - `portalAccountId`: Harmony Mobile Account ID. ![harmony mobile protect configuration](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/47b4a1a0-b6b9-4e8b-b4e0-e5c3e910553f.png) --- ## Threema Work Integration Source: https://docs.applivery.com/en/device-management/integrations/security/threema-work-integration/ Description: Integrate Threema Work with Applivery MDM for centralized User and Policy management of secure enterprise communications. TL;DR: Integrate Threema Work with Applivery MDM to centrally manage licenses and configure policies for secure enterprise messaging on Android and iOS devices. Key topics: Threema Work MDM license creation, Applivery policy configuration, Android Threema Work configuration, iOS Threema Work configuration, Threema Work, Applivery, Android, iOS, GDPR [Threema Work](https://work.threema.ch/en/login) is a secure enterprise messaging solution designed for professional use in organizations that prioritize data protection and privacy. Unlike conventional messaging Apps, Threema Work ensures end-to-end encryption for all communications, including messages, voice calls, and files. It complies with strict privacy regulations such as GDPR and does not require a phone number or email address, preserving user anonymity. Designed for corporate environments, Threema Work offers centralized user and Policy management. IT admins can preconfigure the App, enforce usage Policies, and distribute it at scale across managed Devices. ### Create the MDM licenses in Threema Work To begin, log in to the [Threema Work](https://work.threema.ch/en/login) and select your active subscription. Navigate to the **User management** 1 section and click + **Add** 2 to begin assigning MDM licenses to your subscription. ![threema-user-management](https://www.applivery.com/wp-content/uploads/2025/05/threema-user-management-2-1024x415.png "threema-user-management | Applivery") Choose the option **License for MDM system** 3 and specify a username and password—these credentials will later be used to integrate the licenses with Applivery. You can choose to store the password either in plain text or as a hash. If you opt for a hashed password, be sure to save the link displayed after clicking **Save**, as hashed passwords cannot be retrieved later. :::info If saved in plain text, the credentials will remain visible and can be copied at any time by clicking the three dots next to the license entry. ::: ![threema-license-mdm](https://www.applivery.com/wp-content/uploads/2025/05/threema-license-mdm-1024x415.png "threema-license-mdm | Applivery") Select the desired number of licenses for Applivery Device Management and hit **Save** 4. ### Create a Policy for Threema Work in Applivery Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), go to the **Policies** section and create a new one. Click the **\+ Create Policy** button. Select the desired operating system, then choose the **Threema Work** template, which comes with a predefined configuration Policy that includes the following parameters: | Configuration keys | Value type | Description | | --- | --- | --- | | th_license_username | String | MDMLicenseCompany | | th_license_password | String | Password123! | | th_firstname | String | {{user.firstname}} | | th_csi | String | {{use.email}} | | th_safe_enable | Boolean | True | ![threma apple](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/48713e7d-c00f-41cc-a266-f039db5267d7.png) If you selected **Apple**, go to the **Apps** section from the left-hand menu, find the **Threema Work** App, and click the **settings** icon at the end of its row. You can now configure the App using the parameters provided below: ![threma appe configuration](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/2a41e2d3-253f-4023-9e9f-a302c75ca978.png) If you selected **Android**, navigate to the **Apps** section and click on the **Threema Work** App. A menu will appear on the right side, displaying the available managed properties. ![threma android configuration](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/2b8b97f5-75c9-4dfc-a35e-b17d6f370ced.png) --- ## SSO Source: https://docs.applivery.com/en/device-management/integrations/sso/ Description: Configure SSO in Applivery Device Management using Okta and Google Workspace — streamline User authentication and provisioning. TL;DR: Configure SSO in Applivery with Okta or Google Workspace for centralized authentication and user provisioning. Key topics: SSO configuration, identity provider integration, user authentication, access control, Applivery, SSO, Okta, Google Workspace SSO integrations let your team authenticate to the Applivery Dashboard using your organization's existing identity provider. Applivery supports SAML-based SSO with providers such as Okta, Azure AD, and Ping Identity, as well as automated user and group provisioning via SCIM. Configure SSO for Device Management, from setting up the identity provider to mapping groups and roles in Applivery. --- ## Google Workspace Source: https://docs.applivery.com/en/device-management/integrations/sso/google-workspace/ Description: Configure Google Workspace with Applivery MDM — set up OAuth 2.0 credentials for seamless Device Management and SSO integration. TL;DR: Configure Google Workspace with Applivery MDM by setting up a Google Cloud Platform project, configuring OAuth 2.0 credentials, and enabling API access. Key topics: Google Cloud Platform setup, OAuth 2.0 configuration, Applivery MDM integration, API access, Google Workspace, Applivery, Google Cloud Platform, OAuth 2.0, Admin SDK API :::warning This is a premium feature that might not be available in your current plan. Check the availability on our [pricing page](https://www.applivery.com/pricing/). ::: To configure it, make sure you have admin access to your organization’s Google Workspace. This way, you can either create a new project or get the permissions needed to set up OAuth 2.0 credentials for an existing project. Please follow the next steps carefully. ### Set up your Google Workspace **Create a new Google Cloud Platform (GCP) project** Log in to the Google Cloud Platform [console](https://console.cloud.google.com/). This is separate from your Google Workspace console. A Google Cloud project is required to enable Google Workspace APIs. Navigate to **IAM & Admin** > **Create Project**. Name the project and select **Create**. Then, navigate to **APIs & Services** and click on **\+ Enable APIs and Services**. This action will load the API Library. Once in the library, search for `admin`, choose the **Admin SDK API** and proceed to **enable** it. Return to the **APIs & Services** page and go to **Credentials**. You will see a warning that you need to configure a consent screen. Select **Configure Consent Screen.** Verify the project name listed in the upper left corner near the logo to make sure that you are using the correct project. ![Credentials | Applivery](https://www.applivery.com/wp-content/uploads/2023/09/Credentials-1024x432.png "Credentials | Applivery") **Configure the consent screen** Select **Internal** as the User Type. This choice restricts authorization requests to users within your Google Workspace, preventing access for individuals with standard Gmail addresses. Provide a name for the application, include a support email, and fill in the contact fields. Keep in mind that the Google Cloud Platform requires an email in your account. You can leave the **Scopes** page empty. Once the summary page loads, save your settings and exit. **Configure the credentials** Return to the **Credentials** page and select **\+ Create Credentials** > **OAuth client ID**. ![68747470733a2f2f6465762d646f63732e636c6f7564666c6172656163636573732e6f72672f6163636573732f7374617469632f636c6f7564666c6172652d6f6e652f6964656e746974792f6773756974652f6372656174652d6f617574682e706e67 | Applivery](https://www.applivery.com/wp-content/uploads/2023/09/68747470733a2f2f6465762d646f63732e636c6f7564666c6172656163636573732e6f72672f6163636573732f7374617469632f636c6f7564666c6172652d6f6e652f6964656e746974792f6773756974652f6372656174652d6f617574682e706e67-1024x392.png "68747470733a2f2f6465762d646f63732e636c6f7564666c6172656163636573732e6f72672f6163636573732f7374617469632f636c6f7564666c6172652d6f6e652f6964656e746974792f6773756974652f6372656174652d6f617574682e706e67 | Applivery") Choose **Web application** as the Application type. For the **Authorized redirect URIs** box, input: `https://mdm-portal.applivery.io/login/`. Google will provide the **OAuth Client ID and Secret** values. Remember that the secret field functions as a password and should be kept confidential. Copy both values. On your [Google Admin console](https://admin.google.com/), go to **Security** > **Access and data control** > **API controls**, open the Settings menu, and enable the **Trust internal, domain-owned Apps** option. ![Untitled | Applivery](https://www.applivery.com/wp-content/uploads/2023/09/Untitled-1024x432.jpg "Untitled | Applivery") ### Get the Service Provider information from Applivery Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), go to your **Workspace Settings** 1 from the top dropdown menu, then open **Login providers** 2 in the left-hand menu and click the **Google Workspace** option under the **MDM Portal** section 3. ![google Workspace login provider](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/2d3b3e80-afde-4dab-9bb6-e1f8808c6892.png) You will see your Google Workspace configuration, where you will need to input the **Client ID** and **Client Secret** fields. ![google Workspace](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/10cdb784-b181-4b68-af61-dc4125b31719.png) ### Troubleshooting #### Error 5137: Could not retrieve user groups (`invalid_grant`) When a user tries to enroll a device through the MDM Portal, they may see the following error: ``` 5137: {"reason":"Could not retrieve user groups","err":"invalid_grant"} ``` This error means that Applivery's authorization to read Google Workspace groups has expired or been revoked. To fix it, you need to reauthorize Applivery from the Dashboard: **Open your Workspace Settings** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), click the top-right dropdown menu and go to **Workspace Settings**. **Reauthorize Applivery** In the left-hand menu, go to **Login providers** and click **Configure** next to the **Google Workspace** option under the **MDM Portal** section. Under **Step 2**, **reauthorize** to grant Applivery permission to obtain groups again. ![reauthorize](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/8ece9115-1122-40a4-9aa2-d8f837f1958b.png) Once the reauthorization is complete, the enrollment flow should work without errors. --- ## SCIM User Provisioning & Attribute Management Source: https://docs.applivery.com/en/device-management/integrations/sso/scim-attribute-creation-and-assignment-in-okta/ Description: Manage User provisioning and attributes in Okta using SCIM — core, enterprise, and custom schemas for seamless identity management. TL;DR: Learn how to manage user provisioning and attributes in Okta using SCIM, including creating custom attributes and mapping them to your applications. Key topics: SCIM Schemas, Custom Attributes, Attribute Mapping, Okta Provisioning, Okta, SCIM, JSON, URN :::warning This is a premium feature that might not be available in your current plan. Check the availability on our [pricing page](https://www.applivery.com/pricing/). ::: SCIM (System for Cross-domain Identity Management) is an open standard that automates the exchange of user identity data across systems. Okta includes native SCIM 2.0 support for provisioning, user synchronization, and attribute lifecycle management with third-party applications. ### Supported SCIM Schemas Okta implements several SCIM 2.0 schemas, each defining a set of attributes that describe a user. These schemas are used during user provisioning and sync operations. #### Core User Schema - **URN**: `urn:ietf:params:scim:schemas:core:2.0:User`. The core schema contains the standard SCIM 2.0 user attributes and is always included in outbound SCIM payloads. ##### Example JSON ``` { "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"], "id": "00u12345abcdXYZ", "userName": "john.doe@example.com", "name": { "formatted": "John Doe", "familyName": "Doe", "givenName": "John", "middleName": "A", "honorificPrefix": "Mr.", "honorificSuffix": "Jr." }, "displayName": "John Doe", "nickName": "Johnny", "profileUrl": "https://example.com/john.doe", "emails": [ { "value": "john.doe@example.com", "type": "work", "primary": true } ], "addresses": [ { "type": "work", "streetAddress": "123 Main St", "locality": "San Francisco", "region": "CA", "postalCode": "94105", "country": "US", "primary": true } ], "phoneNumbers": [ { "value": "+1-415-555-1234", "type": "work" } ], "preferredLanguage": "en-US", "locale": "en-US", "timezone": "America/Los_Angeles", "active": true, "password": "hashed-password" } ``` #### Enterprise User Schema - **URN**: `urn:ietf:params:scim:schemas:extension:enterprise:2.0:User`. This schema extends the core user resource with enterprise-centric attributes such as department, manager, and costCenter. ``` { "schemas": [ "urn:ietf:params:scim:schemas:core:2.0:User", "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User" ], "userName": "john.doe@example.com", "name": { "givenName": "John", "familyName": "Doe" }, "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User": { "employeeNumber": "E12345", "costCenter": "CC1001", "organization": "Engineering", "division": "Software Development", "department": "R&D", "manager": { "managerId": "00u67890abcdXYZ", "displayName": "Jane Smith" } } } ``` #### Custom Extension Schema - **URN**: `urn:okta:custom:schema`. Okta allows administrators to define custom schemas for attributes that fall outside the SCIM standard. This schema can use any URN string of your choice. ``` { "schemas": [ "urn:ietf:params:scim:schemas:core:2.0:User", "urn:okta:custom:schema" ], "userName": "john.doe@example.com", "name": { "givenName": "John", "familyName": "Doe" }, "urn:okta:custom:schema": { "customEmployeeType": "Contractor", "customStartDate": "2024-01-10", "customSecurityClearance": "Level 3" } } ``` ### Creating New Custom Attributes To define and expose a new SCIM custom attribute in Okta, start by opening your SCIM application and navigating to **Applications** > **Your SCIM App** > **Provisioning** > **To App**. Next, go to the Profile Editor by clicking **Go to Profile Editor**. From there, create a new attribute by clicking **Add Attribute** and configuring the following properties: - **Display Name** (for example, Security Clearance Level). - **Variable Name** (e.g., `customSecurityClearance`). - **External Name** (the SCIM attribute key, such as `urn:okta:custom:schema:customSecurityClearance`). - **External Namespace** (the URN of your custom schema). - **Data Type** (`String`, `Boolean`, `Number`, or `Date`). After saving the new attribute, assign it to a user profile by opening any user in Okta and confirming that the attribute appears in the profile section. ### Mapping Attributes in Okta After creating both standard and custom attributes, they need to be mapped to ensure that data flows correctly between Okta and your SCIM-enabled application. To do this, go to **SCIM App** > **Provisioning** > **To App** and click **Edit** to enable attribute mappings. For each attribute you want to map, select **the corresponding Okta User Profile Attribute** (for example, `user.profile.department`) and specify the **App User Attribute path** (e.g., `urn:ietf:params:scim:schemas:extension:enterprise:2.0:User.department`). Once all mappings are configured, save your changes. Finally, test the provisioning by updating a user in Okta and verifying that the changes propagate correctly to the target application via the SCIM API. ### Example mapping table | OKTA Attribute | SCIM Attribute Path | | --- | --- | | `user.profile.firstName` | `name.givenName` | | `user.profile.lastName` | `name.familyName` | | `user.profile.email` | `emails[primary eq true].value` | | `user.profile.department` | `urn:ietf:params:scim:schemas:extension:enterprise:2.0:User.department` | | `user.profile.customSecurityClearance` | `urn:okta:custom:schema:customSecurityClearance` | --- ## SCIM Attribute Mapping Source: https://docs.applivery.com/en/device-management/integrations/sso/scim-attributes-mapping/ Description: Map SCIM attributes to User metadata in Applivery for consistent user information — customize attribute mapping for better User Management. TL;DR: Applivery allows mapping SCIM attributes to user metadata for improved user management by configuring custom mappings and following specific resolution rules. Key topics: SCIM attribute mapping, User metadata configuration, Applivery SCIM integration, SCIM attribute resolution, Identity provider integration, SCIM, Applivery, IdP, Okta :::warning This is a premium feature that might not be available in your current plan. Check the availability on our [pricing page](https://www.applivery.com/pricing/). ::: When receiving user information through SCIM, the data is often organized across multiple schemas. To keep this information consistent, usable, and accessible, Applivery can map specific SCIM attributes into the user’s `metadata` field. ### Understanding SCIM Attribute Storage All mappable SCIM fields are automatically stored in an internal object called `attributesHistory`. This object tracks every attribute received from SCIM, whether or not it is currently mapped to metadata. #### SCIM Attributes History The `attributesHistory` object contains all SCIM attributes in the following structure: ```typescript type IProviderSCIMAttributesHistory = { namespace: string key: string } ``` This object is populated automatically with all attributes provided in SCIM requests. Its purpose is to serve as a complete record of any field that can potentially be mapped. #### Custom Attribute Mapping To map SCIM fields into the user’s metadata, you can define a custom mapping through the `mappedAttributes` property in the SCIM configuration model. ```typescript type IProviderSCIMCustomAttributes = { name: string attributes?: { namespace?: string key: string }[] } ``` Each mapping entry supports the following fields: - **Name**: The key under which the mapped value will be stored inside the user’s metadata. - **Attributes**: A list of SCIM attributes (optionally specifying their namespace/schema) that will be used to generate this metadata value. :::tip For guidance on defining custom attributes inside your Identity Provider (IdP), refer to the [following article in our documentation](https://docs.applivery.com/en/device-management/integrations/sso/scim-attribute-creation-and-assignment-in-okta/). ::: #### Resolution rules When resolving which SCIM value to map into `metadata`, Applivery follows these rules: 1. If a namespace is specified, the system searches for the SCIM attribute inside that exact namespace/schema. 2. If no namespace is defined, the system maps the first matching attribute key found in any schema. 3. When a SCIM payload includes a value for a mapped custom attribute, Applivery automatically writes it into the user’s `metadata`: - **Key**: The name defined in the `mappedAttributes` entry. - **Value**: The resolved SCIM attribute value based on the mapping rules. #### Example of a namespace-based mapping ##### SCIM payload ```json { "schemas": [ "urn:ietf:params:scim:schemas:core:2.0:User", "urn:company:params:scim:schemas:extension:custom:2.0:User" ], "urn:ietf:params:scim:schemas:core:2.0:User": { "userName": "jane.smith" }, "urn:company:params:scim:schemas:extension:custom:2.0:User": { "employeeId": "EMP-4567", "department": "Engineering" } } ``` ##### Custom mapping configuration ```javascript const mappedAttributes = [ { name: "department", attributes: [ { namespace: "urn:company:params:scim:schemas:extension:custom:2.0:User", key: "department" } ] }, { name: "employeeCode", attributes: [ { namespace: "urn:company:params:scim:schemas:extension:custom:2.0:User", key: "employeeId" } ] } ] ``` ##### Result in the user's metadata ```json { "metadata": { "department": "Engineering", "employeeCode": "EMP-4567" } } ``` ### Configure Attribute Mapping on Applivery **Navigate to Login Providers Settings** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), go to your **Workspace Settings** 1 from the top dropdown menu, then open **Login providers** 2 in the left-hand menu and click the **SAML** option under the **MDM Portal** section 3. ![login providers](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/0c5fb7b6-4277-4b92-830c-ebb4a3cdc744.png) **Enter Namespace** Scroll down to **Step 3** and enter the appropriate namespace. You can determine the correct namespace based on the attribute type (Core, Enterprise, or Custom) and its value. ![attribute mapping](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/1295fb1c-b743-4791-8354-339c41df6e2c.png) **Save Changes** To save your changes, simply click Save. Once your IdP performs its next scheduled sync, the mapped attributes on both sides will begin populating each user’s `metadata` in Applivery. To summarize: - SCIM attributes can be mapped to user metadata using `mappedAttributes`. - `namespace` helps disambiguate attributes when multiple schemas are involved. - Any unmapped SCIM attributes are stored in `attributesHistory` for future reference. - This mapping system gives you full control over how user data is stored and leveraged downstream. --- ## Windows Device Management Source: https://docs.applivery.com/en/device-management/windows/ Description: Securely manage Windows devices at scale with Applivery. Enroll, configure policies, deploy apps, and ensure compliance. Learn more! TL;DR: Applivery simplifies Windows device management with features for enrollment, security policies, app deployment, and compliance. Key topics: Windows Enrollment, Security Policies, App Deployment, Compliance Management, Windows, Applivery, BitLocker, Microsoft Store, Win32 Applivery enables you to enroll, secure, and manage Windows Devices at scale. You can deploy Apps from the Microsoft Store or as Win32 packages, configure Policies for BitLocker, Firewall, and beyond, and keep Devices updated and compliant — all through a single Dashboard. Windows Device Management in Applivery includes enrollment methods, App management, Policies, and troubleshooting. --- ## App Management Source: https://docs.applivery.com/en/device-management/windows/app-management/ Description: Windows App Management in Applivery — deploy, update, and control Apps on Windows Devices at scale from a centralized Dashboard. TL;DR: Applivery simplifies Windows app management by providing a centralized platform for device enrollment, app deployment, and policy enforcement. Key topics: Windows app management, Device enrollment, Policy enforcement, Applivery platform, Applivery, Windows, MDM Windows App Management in Applivery lets you deploy and maintain applications on managed Windows Devices. You can install Apps from the Microsoft Store, deploy Win32 packages (`.msi`, `.exe`), and manage App assignments through Policies. Choose an App distribution method for Windows, upload and configure Apps, and assign them to Devices or users. --- ## Block Microsoft Store Source: https://docs.applivery.com/en/device-management/windows/app-management/block-microsoft-store/ Description: Disable access to the Microsoft Store on company-owned Windows Devices using Applivery Policies to enhance security and compliance. TL;DR: Learn how to block the Microsoft Store on Windows devices using Applivery to improve security and compliance. Key topics: Microsoft Store blocking, Applivery configuration, Windows device management, Microsoft Store, Windows, Applivery Because any user can download and install Apps from the Microsoft Store, it can become a security risk for company-owned Devices. Unauthorized Apps may introduce vulnerabilities, violate compliance Policies, or interfere with enterprise configurations. To maintain a secure and controlled environment, it’s recommended to disable access to the Microsoft Store on managed Windows Devices. This can be achieved easily through Applivery by configuring the appropriate policy. ### Set up your Policy Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), head to **Policies** 1. Choose the Policy where you want to block the Microsoft Store. Then, from the left-hand menu, click **\+ Add configuration** 2 and use the search bar to find the **Windows Store** 3 Group Policy. ![microsoft store](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/e8f2ce9b-1b04-4896-b34a-83690aa4661b.png) Next, enable the **Turn off the Store application** setting to disable the Microsoft Store on your Devices. ![turn off store](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/8025fead-abeb-4d2e-9264-bdc84eabf4d8.png) --- ## Manage Apps Source: https://docs.applivery.com/en/device-management/windows/app-management/manage-apps/ Description: Manage Windows Apps using Applivery MDM — deploy, update, and control software on Windows Devices for security and compliance. TL;DR: Applivery MDM simplifies Windows app management by providing tools to deploy, update, and control applications through various methods, including the Microsoft Store and a self-service app catalog. Key topics: Windows MDM, Applivery, Application Deployment, App Catalog, MDM Policies, Microsoft Store, Windows, MDM, Applivery Agent Application management is a core pillar of any Windows Mobile Device Management (MDM) strategy. In corporate environments, ensuring that Devices run only approved, properly configured, and up-to-date software is essential to maintain security, productivity, and compliance with internal Policies. Applivery provides a comprehensive set of tools to centrally manage applications on Windows Devices at scale, enabling IT teams to deploy, update, and control software without requiring user interaction. Through native MDM Policies and, when needed, the Applivery Windows Agent, administrators can address both standard deployment scenarios and advanced use cases that require deeper control. ### Install type options - **Force installed**: The App will be force installed. - **Available**: The App will be available to be installed on-demand, either from the dashboard or using the Self-Service App on Windows Devices. ### App management Once in the [**Applivery Dashboard**](https://dashboard.applivery.io), go to any of your **Policies** 1. From the left side menu, go to **Apps** 2 and click the **\+ Add App** button 3. A modal window will appear, allowing you to select the application source. ![add app](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/60217f47-ed98-4fdd-af94-18cad5f02c99.png) - **Microsoft Store**: This source allows you to deploy applications directly from the Microsoft Store. It is the recommended option for modern applications that support MDM management, as it ensures native integration with Windows, improved security, and automatic updates. - **Applivery**: This source refers to applications distributed directly through Applivery (App Distribution or App Catalog). - **Resource**: This source enables the deployment of applications packaged in `.msi`, `.msix`, and `.appx` formats that have been previously uploaded to the Resources section in Applivery, or that can be uploaded directly using the **Upload new resource** button. This option is ideal for internal corporate applications, third-party software, or custom installers that are not available in the Microsoft Store. #### Applivery App Management There are two options for managing applications through Applivery. ![app management](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/6f7d0616-6993-48f7-8181-2d8885a89807.png) On one hand, you can select **Your Workspace**; applications that have been previously uploaded to your Workspace through App Distribution. These applications are managed and deployed directly using Applivery, allowing administrators to control installation, updates, and availability across the Device fleet. On the other hand, you can choose **App Catalog**. This option is directly linked to applications managed by the Applivery Agent. The App Catalog enables end users to install approved applications on demand through the self-service experience, while IT maintains full control over which applications are available. This approach reduces administrative overhead, improves flexibility, and empowers users without compromising security or compliance. --- ## Wrap Files into MSI Source: https://docs.applivery.com/en/device-management/windows/app-management/wrapping-msi-files/ Description: Wrap files into a single MSI package for deployment via Applivery MDM — deploy custom Apps, Scripts, and installers on Windows Devices. TL;DR: Learn how to package files into an MSI for easy deployment via MDM, enabling custom application and script installations on Windows devices. Key topics: MSI packaging process, Using batch files to trigger PowerShell scripts, Deploying applications via MDM, MSI Wrapper tool, MSI, MDM, Applivery, Windows, PowerShell, MSI Wrapper, EXEMSI Wrapping files into a single MSI file is helpful when deploying custom applications or scripts through Applivery MDM. Once packaged, the MSI can be uploaded to Applivery and deployed like any standard application, triggering your custom scripts or installers on target Devices. ### Common use cases Wrapping into a single MSI is useful for: - Installing `.exe` applications. - Installing `.msix` or `.msixbundle` packages. - Deploying custom scripts. :::info MSI files deployed through Applivery are executed with **administrator privileges** under the **SYSTEM account** in Windows. Keep this in mind when deploying scripts or applications intended for user-level execution, as they will also run in the SYSTEM context. ::: ### How it works The most straightforward approach is to include all necessary files in a folder, along with a **batch** file (`.bat`). This batch script serves as the entry point, allowing it to call PowerShell scripts or launch installers. **Example: Deploying** `xbox.msixbundle` **Create a batch file (installXbox.bat) to trigger a PowerShell script** ```batch @echo off powershell.exe -ExecutionPolicy Bypass -File "%~dp0installXboxApp.ps1" ``` **Create the PowerShell script (installXboxApp.ps1) to install the App** ```powershell Dism /Online /Add-ProvisionedAppxPackage /PackagePath:".\xbox.msixbundle" /SkipLicense exit 0 ``` **Place the following files in a single folder** - `installXbox.bat` - `installXboxApp.ps1` - `xbox.msixbundle` ### Creating an MSI with EXEMSI’s MSI Wrapper There are multiple tools available to create MSI packages. The steps below use **MSI Wrapper by EXEMSI** — a simple utility that offers both free and paid versions. :::info The free version adds a watermark to the MSI file name but does not limit functionality. ::: #### Prepare Your Files Before wrapping, create a folder with **only** the necessary files (e.g., batch file, scripts, app packages). :::warning MSI files cannot execute PowerShell scripts directly. You must use a `.bat` file to trigger any PowerShell logic. ::: In this example, the batch file is set as the **primary executable**. When the MSI is run, the batch script initiates the PowerShell script, which performs the actual installation. **Open MSI Wrapper and click Next to begin the configuration process** ![step-1](https://www.applivery.com/wp-content/uploads/2025/08/step-1.png "step-1 | Applivery") **Select the batch file as the executable (this is your trigger file)** - Make sure to **check the box** to include all files in the setup folder. - Choose the appropriate **platform architecture** (usually x64). ![step-2](https://www.applivery.com/wp-content/uploads/2025/08/step-2.png "step-2 | Applivery") **Set the installation context based on your deployment needs** - In most cases, you’ll want to install for **all users** or **system-wide**. ![step-3](https://www.applivery.com/wp-content/uploads/2025/08/step-3.png "step-3 | Applivery") **Define the application identity** - Enter an **Application ID** (any string of your choice). - Click to **generate a new Upgrade Code**. ![](https://www.applivery.com/wp-content/uploads/2025/08/step-4.png "step-4 | Applivery") **Fill in product details manually** - Provide the **Product Name**, **Manufacturer**, and **Version**. - Click **Next** through the remaining steps. ![](https://www.applivery.com/wp-content/uploads/2025/08/step-5.png "step-5 | Applivery") **Click Build to generate the MSI file** - The output MSI will be created in the **same directory** as your source files. ![step-6](https://www.applivery.com/wp-content/uploads/2025/08/step-6.png "step-6 | Applivery") --- ## Commands Source: https://docs.applivery.com/en/device-management/windows/commands/ Description: Remote commands for managed Windows Devices in Applivery — reboot, sync, wipe and disenroll without physical access. TL;DR: Remote commands for Windows Devices: sync, update status, reboot, force sync, wipe, disenroll and move segment. Windows MDM Commands let you perform real-time remote actions on managed Windows Devices — pushing the latest Policy, rebooting a Device, wiping it, or removing it from management without requiring physical access. Each remote command available for Windows includes when to use it and what happens on the Device when it's executed. --- ## Remote Commands Source: https://docs.applivery.com/en/device-management/windows/commands/remote-commands/ Description: Remotely reboot, sync, wipe or disenroll a Windows Device from the Applivery Dashboard, without needing physical access. TL;DR: Use the Action button on a Windows Device to sync, reboot, wipe, disenroll or move it between Segments. Check the Commands tab to see whether each one reached the Device. Key topics: Remote actions, Wiping Windows Devices, Disenrollment, Command status, Applivery, Windows Once a Windows Device is enrolled, Applivery can manage it remotely without physical access: pushing the latest Policy, rebooting it, wiping it, or removing it from management. All of these are one-click actions from the Device's detail page, and each one is tracked so you can confirm it actually reached the Device. ### Sync policy Pushes the Device's currently assigned Policy again, without waiting for the next scheduled check-in. It's the first thing to try after changing a Policy, when you'd rather not wait for the Device to pick the change up on its own. **Navigate to the Device** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), navigate to any of your **Devices** and click the **Action** button 1. **Select Sync policy** From the dropdown menu, select **Sync policy** 2. ![sync policy](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/e10d5bfd-a9dc-41e4-a583-6a7770ffaef0.png) ### Update status Requests a fresh report from the Device — battery, storage, installed apps and the rest of the information shown on the **Overview** tab. Useful when the Device details look stale, or before making a decision based on what the Dashboard is showing. **Navigate to the Device** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), navigate to any of your **Devices** and click the **Action** button 1. **Select Update status** From the dropdown menu, select **Update status** 2. ![update status](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/3178bf71-fbb1-4a41-9599-95b48b4b5495.png) ### Reboot Restarts the Device remotely. Sending a restart is useful in several situations: it frees up memory when performance degrades, applies system updates that only take effect after a reboot, and clears minor faults such as unresponsive Apps. It's also worth doing on Devices that have been running for weeks without a restart, and after applying settings that need one to take effect. **Navigate to the Device** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), navigate to any of your **Devices** and click the **Action** button 1. **Select Reboot** From the dropdown menu, select **Reboot** 2. ![reboot](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/8ccba7bf-295b-4a03-b497-09038c8cff70.png) ### Wipe Resets the Device. Selecting **Wipe** opens a dialog where you choose between two types: - **Wipe device** — resets the Device to factory state. All data is removed. - **Protected wipe** — resets the Device and fully cleans the internal drive. Unlike a standard wipe, the Device **keeps attempting to complete the reset even if the process is interrupted**, for example by a power loss. Use the standard wipe for an ordinary reset — a Device being reassigned internally, say. Use **Protected wipe** when you need to guarantee the data is actually gone: a lost or stolen Device, or one leaving the organization. **Navigate to the Device** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), navigate to any of your **Devices** and click the **Action** button 1. **Select Wipe and choose the type** From the dropdown menu, select **Wipe** 2, then choose **Wipe device** or **Protected wipe** in the dialog. ![reboot](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/7190f861-3a06-4ce2-a62f-b3a0d7a23adb.png) :::warning **Wiping a Device is irreversible.** Make sure you're targeting the right Device before confirming, especially with **Protected wipe** — since it survives interruptions, there's no window in which to stop it once it's underway. ::: Wipe is also available from **Settings → Danger Zone** on the Device's detail page, where both types are explained side by side. ### Disenroll Removes the Device from Applivery's management. The Device stops receiving Policies, Apps, and commands, but **keeps its data and installed software**. That's the difference from a wipe: disenrolling is what you want when the Device stays with the user and simply shouldn't be managed anymore. **Navigate to the Device** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), navigate to any of your **Devices** and click the **Action** button 1. **Select Disenroll** From the dropdown menu, select **Disenroll** 2. ![disenroll](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/b11504f9-a7af-48ad-8716-58732435e826.png) Disenroll is also available from **Settings → Danger Zone**. ### Move Segment Moves the Device to a different Segment. **Navigate to the Device** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), navigate to any of your **Devices** and click the **Action** button 1. **Select Move Segment** From the dropdown menu, select **Move Segment** 2 and choose the destination. ![move segment](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/e8930856-1dd6-41c1-ac93-df7702a26149.png) :::info All the commands mentioned above can also be executed from the **Commands** tab or from the **Danger Zone** section within the **Settings** tab. ::: --- ## Device Details Source: https://docs.applivery.com/en/device-management/windows/device-details/ Description: Inspect the raw MDM data Windows reports back for a Device — enrollment, certificates, hardware and applied configurations — and manage its Smart Attributes. TL;DR: Open a Windows Device and go to Details to see the raw MDM data it reports, split into eight categories. Everything is read-only except Smart attributes. Key topics: Raw MDM data, Configuration Service Providers, Smart Attributes, Device troubleshooting, Applivery, Windows, Microsoft The **Overview** tab of a Device gives you a curated summary — the things you check most often, presented for reading. The **Details** tab is the opposite: a direct window into the raw data Windows itself reports back over MDM, with no interpretation on top. It's the tab you open when the summary isn't enough: when you need to confirm what was actually delivered to a Device, or why something isn't applying. ![device details](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/c9a5a569-0e53-41ec-afd3-81e5d894b92a.png) :::info Most of what you'll see here maps directly to a named Windows **Configuration Service Provider (CSP)** — the standard building blocks Windows uses to report and configure settings over MDM. Where a category maps to one, it links to Microsoft's own reference. ::: ### Finding your way around Open a Windows Device and go to its **Details** tab. A list of categories on the left filters what's shown on the right, and a search box at the top filters within the selected category. **Export CSV**, top right, downloads the data for whichever category you're currently looking at. :::warning **Everything here is read-only except Smart attributes.** The rest is telemetry reported by the Device — you're reading what Windows sent, not configuring anything. ::: ### Smart attributes The one category that isn't telemetry. This is where you view and manage the Device's [Smart Attributes](https://docs.applivery.com/en/device-management/general-settings/smart-attributes/), scoped by Segment, with an **Include from parents** toggle and **\+ Add smart attribute** to create new ones. ### Device Info Baseline identity data about the Device and its MDM session: `Dev Id` (its unique MDM identifier), `DmV` (the DM protocol version it speaks), `Lang`, and vendor and model information. This is the [DevInfo CSP](https://learn.microsoft.com/en-us/windows/client-management/mdm/devinfo-csp) — the very first thing a Device reports when it talks to an MDM server. ### Device Settings and status that apply **machine-wide**. In Windows MDM terms this is the `./Device/Vendor/MSFT/...` side of the CSP tree. Among others, it includes: - **Enrollment and renewal health** — `Error Code`, `Last Renewal Attempt Time`, `Renew Period`, `Retry Interval`, the enrollment `Server URL` and `Status`, and the `ROOT` certificate hash confirming the trust chain to Applivery. From the [DMClient CSP](https://learn.microsoft.com/en-us/windows/client-management/mdm/dmclient-csp), which every enrolled Device uses to manage its connection to the server. - **Disk encryption** — BitLocker status, Device Encryption Status and Removable Drives Encryption Status, from the [BitLocker CSP](https://learn.microsoft.com/en-us/windows/client-management/mdm/bitlocker-csp). - **Certificate stores** — Root CA Trusted Certificates, Trusted People, Trusted Publisher and Untrusted Certificates, from the [CertificateStore CSP](https://learn.microsoft.com/en-us/windows/client-management/mdm/certificatestore-csp). - **App management** — Enterprise Desktop App Management for classic Win32 and MSI installs, and Enterprise Modern App Management for Store and MSIX apps and their licenses, from the [EnterpriseModernAppManagement CSP](https://learn.microsoft.com/en-us/windows/client-management/mdm/enterprisemodernappmanagement-csp). - **Language settings**, and the result of any applied [Custom ADMX Configuration](https://docs.applivery.com/en/device-management/windows/policies/admx-configs/). :::info This category also lists **every policy area the Device supports**. That's worth checking before you spend time troubleshooting why a setting isn't applying — if the area isn't in the list, the Device simply doesn't support it, and no amount of policy tuning will change that. ::: ### User The same kind of data as **Device**, but scoped to the **currently logged-in user** — the `./User/Vendor/MSFT/...` side of the tree. Many Windows CSPs exist in both a Device and a User instance, because some settings only make sense per person rather than machine-wide. - **Personal Data Encryption** — whether it's enabled and which known folders (Desktop, Documents and so on) are protected, from the [Personal Data Encryption CSP](https://learn.microsoft.com/en-us/windows/client-management/mdm/personaldataencryption-csp). - **Installed per-user apps** — the AppX package family names installed for that user, such as Teams, Edge or Outlook. - **User-scoped enrollment and certificates** — ActiveSync, Accounts, and the user instance of Client Certificate Install for PFX and SCEP, from the [ClientCertificateInstall CSP](https://learn.microsoft.com/en-us/windows/client-management/mdm/clientcertificateinstall-csp), plus the user-scoped DM Client provider information. ### Vendor Broader health, security and licensing telemetry that isn't split between Device and User — several CSPs reported under one category: - **Security and health** — antivirus signature status from the [Defender CSP](https://learn.microsoft.com/en-us/windows/client-management/mdm/defender-csp), battery estimates, cellular identities, encryption compliance and Device Guard. - **Network security** — firewall rules, profiles and dynamic keyword addresses, from the [Firewall CSP](https://learn.microsoft.com/en-us/windows/client-management/mdm/firewall-csp). - **Windows licensing** — Device Licensing Service status, License Type, Edition, License Key Type and Subscriptions. - **Miscellaneous device-wide settings** — network settings such as credentials and password encryption, Secure Assessment, and Autopilot or device provisioning status. ### Device Detail Hardware and OS-level facts: software version (`Sw V`), OEM, `DNS Computer Name` and `Device Name`, `Free Storage`, `Local Time` and similar low-level attributes. Mostly from the [DevDetail CSP](https://learn.microsoft.com/en-us/windows/client-management/mdm/devdetail-csp). ### Custom Configuration The actual configuration payloads pushed to the Device — including, for a [Custom ADMX Configuration](https://docs.applivery.com/en/device-management/windows/policies/admx-configs/), the raw ADMX XML definition delivered to it, under `Config Operations`, `ADMX Install` and `Policy`. This is the most direct way to confirm exactly what was sent to a Device, byte for byte. When a setting isn't behaving as expected, comparing what you configured against what actually arrived here usually settles the question. ### Summary A compliance-oriented rollup: `Serial Number`, `Compliance` and `Is Compliance`, `Last Sync Error` and `Last Sync Error Message`, and counts for `Applications`, `Books` and `Profiles`. It's the fastest place to check whether a Device is currently in a healthy state — and `Last Sync Error Message` is often the single most useful field on the whole tab when something has stopped working. --- ## Enrollment Source: https://docs.applivery.com/en/device-management/windows/enrollment/ Description: Windows Enrollment in Applivery — enroll, configure, and control Windows Devices at scale with Smart Enrollments and Policies. TL;DR: Applivery simplifies Windows device management by providing a centralized dashboard to enroll, configure, and control devices at scale. Key topics: Windows device management, Applivery, Security policies, Kiosk mode, OEM configuration Enrolling a Windows Device in Applivery registers it with the MDM platform and applies your organization's Policies, Apps, and configuration automatically. Applivery supports multiple Windows enrollment methods to cover both corporate-owned and Azure AD-joined scenarios. Choose the right enrollment method for Windows for your deployment: manual enrollment, Azure AD join, or Autopilot. --- ## Auto-Discovery: CNAME Setup Source: https://docs.applivery.com/en/device-management/windows/enrollment/auto-discovery-domain/ Description: Configure a CNAME DNS record so Windows devices automatically discover the Applivery MDM server during enrollment — no manual URLs or tokens required. TL;DR: Configure a CNAME DNS record (`enterpriseenrollment` to `domains.applivery.io`) and set your domain in Applivery to enable automatic MDM server discovery for Windows device enrollment. Key topics: Windows MDM auto-discovery configuration, CNAME DNS record setup, Applivery MDM enrollment, DNS propagation, Windows, Applivery, MDM, DNS, CNAME, Applivery Dashboard The **Windows Auto-Discovery Domain** allows corporate Windows devices to automatically locate the Applivery MDM server during the enrollment process — no manual server URLs or enrollment tokens required. Users simply enter their corporate email address, and Windows queries your company's public DNS records to discover the path to Applivery. **Define the domain in Applivery** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), navigate to the **Settings** section 1 and select **Windows Setup** 2 in the left-hand menu. Locate the **Windows Auto-Discovery Domain** section 3 and find the text input field next to `enterpriseenrollment.`. Enter your organization's root corporate domain — for example, if your domain is `applivery.com`, the resulting string will read `enterpriseenrollment.applivery.com`. ![cname](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/05a04a0a-869d-4492-ae77-2f81f54935c9.png) **Create the CNAME record in your DNS provider** A network administrator must create a **CNAME** record in the management panel of your public DNS hosting provider. Use these exact values:

Parameter

Required Value

Type

CNAME

Name / Host

enterpriseenrollment (or enterpriseenrollment.yourdomain.com depending on your provider's UI)

Value / Target

domains.applivery.io

TTL

3600 (or your provider's default value)

**Save and wait for propagation** Once the record is saved in your DNS provider, go back to the [**Applivery Dashboard**](https://dashboard.applivery.io/) and click **Save**. :::info DNS changes are often nearly instantaneous, but full validation by Windows client devices can take **up to 24 hours** to take effect worldwide. ::: --- ## Enrollment Methods Source: https://docs.applivery.com/en/device-management/windows/enrollment/enrollment-methods/ Description: Windows enrollment methods in Applivery — Manual Enrollment, Microsoft Entra ID, Autopilot, Domain Join and Direct Provisioning for Windows devices. TL;DR: Enroll Windows Devices through Manual Enrollment, Microsoft Entra ID automatic enrollment, Windows Autopilot zero-touch provisioning, Direct Provisioning packages, or Domain Join for on-premises Active Directory environments. Key topics: Windows enrollment methods, Windows Autopilot, Identity sources, Automation levels, Provisioning packages, Applivery, Microsoft Entra ID, Active Directory, Windows Once your [Windows Enterprise](https://docs.applivery.com/en/device-management/windows/get-started/) is activated, you can start enrolling your Windows Devices in Applivery. Let's take a look at the available enrollment methods. :::info If you need to onboard several people at the same time, you can invite them all in one go with a [Bulk Enrollment](https://docs.applivery.com/en/device-management/general-settings/bulk-enrollment/). ::: ### Enrollment options Windows provides multiple ways to enroll Devices depending on your identity infrastructure (cloud-only, hybrid or on-premises), the level of automation you need, and whether Devices are enrolled one at a time or in bulk. All enrollment methods result in the Device being managed by Applivery, but they differ in two key aspects: - **Automation level**: Some methods require the end user to manually add a work account from the Settings app, while others enroll the Device automatically the moment it joins your identity provider — with no user interaction required. - **Identity source**: Windows Devices can be tied to **Microsoft Entra ID** (cloud identity), an **on-premises Active Directory domain**, or enrolled as **standalone Devices** with no identity join at all, using a provisioning package. Regardless of the method, every Windows Device must reach the [Windows Enterprise activation](https://docs.applivery.com/en/device-management/windows/get-started/) step before it can be enrolled, and every enrollment can be layered with a [Smart Enrollment](https://docs.applivery.com/en/device-management/windows/enrollment/smart-enrollment/) to conditionally assign Policies based on user or Device data. #### Manual Enrollment The **classic manual enrollment method**, done from the Device itself via **Settings > Accounts > Access work or school**. The user enters their corporate email address, and Windows automatically discovers the Applivery MDM server using your organization's Auto-Discovery Domain — a CNAME DNS record that avoids the need for manual server URLs or enrollment tokens. It works independently of Entra ID and is well suited for one-off enrollments or Devices that are not managed through a directory service. You can learn more about it [here](https://docs.applivery.com/en/device-management/windows/enrollment/manual-enrollment/). #### Microsoft Entra ID Enrollment Ties Device enrollment directly to your corporate identity system. Once the integration is configured, any Device that joins Microsoft Entra ID **automatically enrolls into Applivery**, with no separate enrollment step required. This is the recommended method for corporate-owned, cloud-managed fleets, since it also enables Single Sign-On and automated Policy assignment based on user and group identity. You can learn more about it [here](https://docs.applivery.com/en/device-management/windows/enrollment/entra-id-enrollment/). :::info Devices that were **already joined to Entra ID before** the integration was configured need an extra recovery step, since they hold a security token issued before Applivery existed. See [Enroll Devices Already Joined to Entra ID](https://docs.applivery.com/en/device-management/windows/enrollment/entra-id-joined-devices-enrollment/) to bring them in without unjoining or resetting them. ::: #### Windows Autopilot Microsoft's **zero-touch provisioning** technology. A brand-new Device configures itself the first time it's turned on, with no manual imaging or setup: during the out-of-box experience it is redirected to Applivery, so the Agent, your Policies and your Apps are installed automatically the moment the user signs in. It requires an **active Entra ID integration**, since the redirection is configured through the MDM handover in Entra. It's the method for shipping Devices straight from the vendor to the employee. You can learn more about it [here](https://docs.applivery.com/en/device-management/windows/enrollment/windows-autopilot/). #### Domain Join For environments running an **on-premises Active Directory**. The Device enrolls automatically when it joins the domain, with no user interaction, which makes it the on-premises counterpart to Entra ID enrollment. It's the natural choice for corporate-owned Devices in on-premises or hybrid setups, where identity already lives in your own directory rather than in the cloud. #### Direct Provisioning Allows generating a **provisioning package** tied to an Enrollment Template, which bundles enrollment credentials (including an auto-generated secret) so Devices can be enrolled **without any user interaction or directory join**, typically applied during first boot or via USB. This method is best suited for bulk, offline or kiosk-style deployments, and it's the only one that works when the Device isn't tied to any identity provider. You can learn more about it [here](https://docs.applivery.com/en/device-management/windows/enrollment/provisioning-package-enrollment/). ### Enrollment methods | Enrollment Method | Identity Source | Automation Level | User Interaction | Typical Use Case | | --- | --- | --- | --- | --- | | **Manual Enrollment** | None (email-based discovery) | Manual | Required (enter work email) | One-off enrollments, no directory service | | **Microsoft Entra ID Enrollment** | Microsoft Entra ID (cloud) | Automatic on join | None (after Entra ID join) | Corporate-owned, cloud-managed fleets | | **Windows Autopilot** | Microsoft Entra ID (cloud) | Zero-touch, automatic at first boot | None (user just signs in) | New Devices shipped straight to the employee | | **Domain Join** | On-premises Active Directory | Automatic on join | None (after domain join) | Corporate-owned, on-premises or hybrid environments | | **Direct Provisioning** | None (standalone) | Automatic (package-based) | None | Bulk, offline or kiosk-style deployments | --- ## Entra ID Enrollment Source: https://docs.applivery.com/en/device-management/windows/enrollment/entra-id-enrollment/ Description: Enroll Windows Devices in Applivery MDM through Microsoft Entra ID — streamline provisioning and centralize Device Management. TL;DR: Integrate Microsoft Entra ID with Applivery to streamline device enrollment, enhance security, and centralize control through SSO and automated provisioning. Key topics: Microsoft Entra ID integration, Applivery device enrollment, Single Sign-On (SSO), Automated provisioning, Enhanced security, Microsoft Entra ID, Azure Active Directory, Applivery, MDM, MFA Integrating **Microsoft Entra ID** (formerly Azure Active Directory) with Applivery allows organizations to tie device enrollment directly to their corporate identity system. By leveraging Entra ID, users can enroll Devices using their existing credentials while IT teams maintain centralized control over access, security, and policy assignment. This integration connects identity and device management, reducing manual work, improving security posture, and ensuring that Devices are always associated with the correct users and groups. ### Why use Entra ID for enrollment? Using Microsoft Entra ID as part of your enrollment strategy provides several key benefits: - **Single Sign-On (SSO)**: Users enroll Devices with their standard corporate credentials, eliminating the need for additional usernames or passwords. - **Automated provisioning**: Users and groups are synchronized automatically, ensuring that the appropriate Policies and configurations are applied based on identity. - **Enhanced security**: Support for Multi-Factor Authentication (MFA) and immediate access revocation when a user leaves the organization strengthens overall security. **Access the Entra ID configuration** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), head to **Automation** 1, select **Smart Enrollments** 2, choose **Windows** 3 from the left-hand menu, and then locate the enrollment profile you want to configure. Click the **three-dot (⋮) menu** 4 on the right side of the profile and select **Microsoft Entra ID setup** 5. A modal window will open, displaying the required configuration details, including your unique Azure configuration URLs and the fields needed to complete the integration. ![entra id](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/e1745a8b-34b1-4112-b538-178f240d0da3.png) **Complete the integration setup** With the Applivery configuration modal open, you can now link Applivery with your Microsoft Entra ID tenant. Copy the **MDM Terms of Use URL** and **MDM Discovery URL** 6 provided in Applivery and use them to configure the Mobility (MDM and MAM) application in the Microsoft Entra ID / Azure Portal. Then, enter the required credentials—**Client ID**, **Tenant ID**, and **Client Secret** 7—into the corresponding fields in Applivery. Once all values have been added, click Save Configuration to finalize the connection between Applivery and Entra ID. ![entra id configuration](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/d09a0ef6-21ef-4828-ac8b-c76cfdda0d53.png) :::info Detailed, step-by-step instructions for generating the Client ID, Tenant ID, and Client Secret in the Microsoft Entra ID (Azure) portal are available in the final section of the Applivery configuration modal (**Step-by-step setup guide** 8). ::: By integrating Microsoft Entra ID with Applivery, organizations can enable a secure, identity-driven enrollment flow that simplifies onboarding, enforces access controls, and ensures Devices are always managed according to corporate identity and security Policies. :::info Were some of your PCs **already joined to Entra ID before** you configured Applivery? Those Devices won't enroll on their own, because they use a security token issued before the integration existed. See [Enroll Devices Already Joined to Entra ID](https://docs.applivery.com/en/device-management/windows/enrollment/entra-id-joined-devices-enrollment/) to bring them in without unjoining or resetting them. ::: :::info Want brand-new Devices to enroll into Applivery on their own, straight out of the box? With your Entra ID integration in place, you can now set up [Windows Autopilot](https://docs.applivery.com/en/device-management/windows/enrollment/windows-autopilot/) for a zero-touch provisioning experience. ::: --- ## Enroll Devices Already Joined to Entra ID Source: https://docs.applivery.com/en/device-management/windows/enrollment/entra-id-joined-devices-enrollment/ Description: Enroll Windows PCs that were joined to Microsoft Entra ID before Applivery was configured — no unjoin or reset needed, using dsregcmd /forcerecovery. TL;DR: Devices joined to Entra ID before Applivery was configured don't enroll on their own. Run `dsregcmd /forcerecovery`, have the user sign in, and Windows refreshes its token and enrolls the device automatically. Key topics: Entra ID-joined device enrollment, dsregcmd forcerecovery, Windows MDM enrollment, Applivery scripts, Security token refresh, Microsoft Entra ID, Applivery, Windows, MDM, dsregcmd When you set up the [Microsoft Entra ID integration](https://docs.applivery.com/en/device-management/windows/enrollment/entra-id-enrollment/), any device joined to Entra ID from that point on enrolls into Applivery automatically. But devices that were **already joined to Entra ID before** you configured Applivery behave differently: they never show up for enrollment. The reason is timing. These PCs are using a security token that was issued _before_ the Applivery integration existed, so as far as the device knows, Applivery isn't there. The device isn't broken and nothing is misconfigured — it simply needs to refresh its token so it can discover the new MDM. Microsoft provides a command for exactly this situation. Running `dsregcmd /forcerecovery` refreshes the device's registration with Entra ID **without unjoining the machine or wiping any data**. Once the token is refreshed, the device sees Applivery and enrolls on its own. :::info This procedure assumes the [Entra ID integration](https://docs.applivery.com/en/device-management/windows/enrollment/entra-id-enrollment/) is already configured in your tenant. If it isn't, set that up first — otherwise the refreshed token still won't find Applivery. ::: **Run the recovery command** You can trigger the token refresh in two ways. Choose whichever fits how you reach the affected devices. **Option A — Remotely, with an Applivery script** If the devices are already reachable in your Applivery Dashboard, push the command as a script. Go to **Resources > Scripts**, create a new PowerShell script with the line below, and assign it to the affected devices. See [Scripts](https://docs.applivery.com/en/device-management/windows/policies/scripts/) for the full flow. ```powershell dsregcmd /forcerecovery ``` **Option B — Manually, on the device** On the PC, open a Command Prompt or PowerShell **as administrator** and run: ```powershell dsregcmd /forcerecovery ``` **Sign in when prompted** When the command runs, the user sees a **native Microsoft sign-in prompt**. Have them sign in with their corporate Entra ID account. This is the step that refreshes the device's security token — once the user signs in, Windows updates the token behind the scenes. **Let enrollment complete** After sign-in, Windows discovers Applivery as the MDM and **automatically enrolls the device in the background**. There's nothing else the user needs to do. Once enrollment finishes, the device appears under **Devices** in the [Applivery Dashboard](https://dashboard.applivery.io/) with your organization's policies and apps applied. --- ## Manual Enrollment Source: https://docs.applivery.com/en/device-management/windows/enrollment/manual-enrollment/ Description: Manually enroll Windows 10 and 11 Devices in Applivery MDM — connect to the management server and apply Policies automatically. TL;DR: Enroll your Windows 10/11 devices into Applivery MDM by creating an employee, generating an enrollment, and using the enrollment site or direct link. Key topics: Windows MDM Enrollment, Applivery MDM, Device Enrollment Process, Windows 10, Windows 11, Applivery, MDM Once you have your [Windows Enterprise](https://docs.applivery.com/en/device-management/windows/get-started/) configured, you can start enrolling your Windows Devices. Let’s take a look at it. :::info Before you start enrolling Windows Devices, it’s important to make sure the following requirements are met to enable full device management: - A Device running **Windows 10 or 11 Pro/Enterprise**. - **Local administrator rights** on the Device. ::: **Create a new enrollment** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), head to **Devices**, and click the **\+ Enroll device** button. Fill out the form as follows: - **Platform:** Choose Windows. - **Employee:** User who owns the Device. You can create a new employee by introducing the email address. - **Policy:** Choose the Policy to apply to the Device. You can do so under Device Management > Policies if you haven’t created it yet. Alternatively, you can create a new Policy here and configure it later. - **Display name (optional):** A friendly name to easily identify the Device among the others. - **Expire after:** The expiration time of the enrollment token that will be generated. - **Send instructions email to employee (optional):** Choose whether you want to send a notification to the user, including the enrollment instructions. ![windows enrollment](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/1b7d0132-11e8-4561-b66d-4c84abbcb79e.png) **Enroll the Device** Once the enrollment is created, it will be added to the list of Devices. Click on it to display the enrollment details and instructions. ![enrollment instructions](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/e361a858-765d-4442-abdb-4f4e522d2726.png) You can then decide whether you want to use the **Enrollment Site** or a **Direct Link** for the enrollment process. - The **Enrollment Site** is a secure Applivery portal that walks users through the enrollment process step by step. - Alternatively, the **Direct Link** provides a URL that takes users straight to the enrollment profile—no authentication required. **Complete Enrollment** Once you’ve completed the steps described in each option, you’ll need to confirm that the information is correct and click **Next**. Follow the on-screen instructions to complete the enrollment process until you see the message **Setting up your Device.** Then, click **Got it**. ![setting-up-your-device | Applivery](https://www.applivery.com/wp-content/uploads/2025/07/image-1.png "setting-up-your-device | Applivery") At that point, the Device will be enrolled in Applivery, and you’ll be able to view and manage its details from the dashboard. ![windows device](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/d034f201-bb32-479a-89a8-d8ddd02ca3fe.png) --- ## Provisioning Package Enrollment Source: https://docs.applivery.com/en/device-management/windows/enrollment/provisioning-package-enrollment/ Description: Enroll Windows devices at scale using a Provisioning Package generated from a Smart Enrollment in Applivery — no user interaction required. TL;DR: From a Smart Enrollment in Applivery, click the vertical dots, select View instructions, choose Provisioning Package, and click Create provisioning to generate a PPKG file ready to deploy on Windows devices. Key topics: Provisioning Package generation, Windows Smart Enrollment deployment, Bulk Windows MDM enrollment, Windows, Applivery, PPKG, Smart Enrollment, Provisioning Package A **Provisioning Package (PPKG)** is a deployment method that lets you enroll Windows devices automatically using a file generated directly from a [Windows Smart Enrollment](https://docs.applivery.com/en/device-management/windows/enrollment/smart-enrollment/). It is ideal for bulk or zero-touch deployments, since no manual URL entry or user credentials are needed on the device. ### How to generate and deploy a Provisioning Package :::info Before you start, make sure you have a [Windows Smart Enrollment](https://docs.applivery.com/en/device-management/windows/enrollment/smart-enrollment/) already configured. ::: **Open the Smart Enrollment instructions** In the [**Applivery Dashboard**](https://dashboard.applivery.io/), go to the **Automation** section 1 and select **Smart Enrollments** 2. From the left-hand menu, choose **Windows** 3 as the platform. Click the three vertical dots 4 next to the Smart Enrollment you want to use and select **View instructions** 5. ![provisioning package](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/04fddb99-cb0c-4220-b08b-b6b4b483b184.png) **Generate the Provisioning Package** In the side panel, select **Provisioning Package** 6 and click the **\+ Create provisioning** button 7. :::warning Devices enrolled through this package will be initially linked to a single user or department. You can reassign them later using a script. You can create as many Provisioning Packages as you need from the same enrollment. ::: **Apply the package to your devices** Once the package is generated, click **Select** 8. ![create and select ppkg](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/f245477a-0821-4af4-8181-84b872368662.png) The on-screen instructions will guide you through applying the PPKG file to your Windows devices. * * * ### Enrolling during OOBE (Out-of-Box Experience) When you apply a Provisioning Package during the Windows **OOBE** — the initial setup wizard that runs on a brand-new or freshly reset device — enrollment needs an extra step to stick. During OOBE, Windows runs under a temporary session (`defaultuser0`) that is **not persistent**. If you enroll straight from that stage, the Applivery enrollment gets tied to that temporary session and is silently removed once the session is cleaned up — leaving the device unenrolled. To avoid this, you split the process into two stages: - **OOBE stage**: the user account and everything unrelated to Applivery enrollment is set up on the device. - **After the first Windows login**: the actual Applivery enrollment runs, attached to a **persistent** user, so it survives reboots. :::info This procedure is only required when the PPKG is applied from the **OOBE wizard**. For devices that are already activated (past the initial setup), you only need the single `Enroll.ppkg` described in the section above. ::: **Create the Smart Enrollment and export Enroll.ppkg** In the [**Applivery Dashboard**](https://dashboard.applivery.io/), create a **Windows Smart Enrollment**, select **Anonymous login**, and add a policy. ![Anonymous](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/e3ed0e2a-a89e-4415-b5ee-93c1e9801e1a.png) Generate a Provisioning Package following the dashboard instructions (as in the section above), including **only the Workplace configuration to enroll**. Export it as `Enroll.ppkg` to your desktop. Note that a `.cat` catalog file with the same name is created alongside it. ![configure windows configuration designer](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/316fa9e3-81c7-4633-a7de-13bb2cb3f51b.png) **Build the wrapper package in Windows Configuration Designer** Create a **new provisioning package project** in **Windows Configuration Designer** and set up the following. **a) Create the user account** Create a user account and make sure it belongs to the local **Administrators** group. If it is a standard user, enrollment after RunOnce will fail due to permissions. ![admin user](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/af549dab-c8f3-45d3-ad10-7c1cdfda3fac.png) **b) Add Enroll.ppkg to the delivered files** Scroll down to the **Folders** node under **Runtime settings** and expand it. Files added here are delivered to `C:\Users\Public\Documents` on the target device. Add the `Enroll.ppkg` and its `.cat` catalog file, then click **Add**. They will appear inside the **Runtime** tree. ![folders](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/7f5464e1-4106-4c31-9485-c5c4a7fb1b0b.png) **c) Configure OOBE** Scroll down to the **OOBE** node and configure it as shown. ![node configuration](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/1fa609fa-753e-48e6-a746-c92a0c8d4601.png) **d) Add the RunOnce provisioning command** This is the key step. Scroll down to **Provisioning Commands** and expand it. Click **Device Context** and select the **CommandLine** field from the left tree. Add the following one-liner command: ``` reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce" /v "AppliveryOOBEEnroll" /t REG_SZ /d "powershell.exe -ExecutionPolicy Bypass -Command \"Install-ProvisioningPackage -PackagePath C:\Users\Public\Documents\Enroll.ppkg -QuietInstall -ForceInstall\"" /f ``` **Export and deploy** Export the PPKG, and you are good to go. The command injects a **RunOnce** entry into the Windows Registry that runs silently right after the user's first login following the OOBE provisioning. This attaches the Applivery enrollment to the persistent user who has just logged in. To confirm, go to **Settings > Accounts > Access work or school** — the **Applivery** account will already be listed. From that point, enrollment persists across reboots. --- ## Smart Enrollments Source: https://docs.applivery.com/en/device-management/windows/enrollment/smart-enrollment/ Description: Automate Windows Device Enrollment using Smart Enrollments in Applivery — define rules, assign Policies, and streamline Device Management. TL;DR: Smart enrollments automate Windows device enrollment by using rules and conditions to assign policies and streamline device management. Key topics: Smart enrollment configuration, Auxiliary fields, Applying conditions and rules, Deploying Smart enrollments, Windows, Applivery, SSO, IMEI, Serial Number, Entra ID If you have ever dreamed of automating 100% of the Device enrollment process and conditional policy assignment based on user data (name, email, User Groups) or the Device data (IMEI, Serial Number, etc), **Smart Enrollments** are the tool you were looking for. #### Introduction Smart Enrollments are the most efficient way to manage device enrollments in an unattended manner since they will allow you to **define a set of rules and conditions that must be met for a Device to be enrolled** and, in addition, will allow you to **conditionally assign Policies** based on these rule sets. Smart Enrollments are useful for: - Limit device enrollment: - Based on user authentication through [SSO integrations](https://docs.applivery.com/en/platform/authentication/sso/) (User Groups or email patterns). - Based on device information (IMEI, Serial Number). - Conditionally assign different Policies based on rules. - Automate Android enrollments to enable unattended Zero-touch experiences. ### Smart Enrollment configuration Let’s get started configuring your first Smart Enrollment. First, go to **Automation** 1, select **Smart Enrollments** 2, and choose **Windows** 3 as the platform from the left-hand menu. Then click the **\+ Create Smart Enrollment** 4 button. ![Smart Enrollment](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/514a8ed0-1052-4c32-a9b2-cfcb187137f8.png) **Configure Smart Enrollment** 1. **Name:** Choose a friendly name for your new Smart Enrollment. 2. **Description:** Choose a friendly description for your new Smart Enrollment. 3. **Management mode**: Specify the Device management method to be applied during this Smart Enrollment process. 4. **Login providers**: The SSO providers configured at the Workspace level will be displayed. However, you can also configure the specific integration at the Smart Enrollment level by clicking **Override**. 5. **Policy:** Choose the Policy that will be applied to the Device from the Policies library. If you still don’t have any pre-defined Policies, just type a name, and a new empty policy will be created. 6. **Target segment**: Choose the [Segment](https://docs.applivery.com/en/device-management/general-settings/segments/) that enrolled Devices will be assigned to. 7. **Tags**: Used for filtering and grouping. :::info When the login provider is configured as **Anonymous**, you can enable the **Auto-continue** option, which allows Devices to continue enrollment automatically when no user interaction is required. ::: ![Smart Enrollment form](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/3a28a704-4299-4d70-8a7d-c8664d871748.png) **Configure Auxiliary Fields** 8. **Auxiliary fields**: By filling out this form, you will be able to configure device tags during enrollment. ![auxiliary fields](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/1fceaef5-1bc0-4ade-b700-94ebbd416ca9.png) **Configure Display Name Pattern** 9. **Display name pattern**: Assign a display name by combining device properties. ![interpolation tags](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ea33f0ed-ea8e-40bc-acce-9ea60a927278.png) If you click **Save** at this point, you will have finished setting up your basic Smart Enrollment and will be able to start enrolling Devices. **Auxiliary fields** By using Auxiliary fields, you can define a **flexible enrollment structure** that adapts to the organizational characteristics of your company. This allows users to enroll their Devices **according to specific requirements**, while enabling administrators to apply different configurations based on these selections. These Auxiliary fields can be used to generate device tags during enrollment, which function as conditional parameters. You can create as many fields as needed and later associate them with the corresponding Policies for each scenario. After continuing, the user will be presented with the dropdown menus defined in the Auxiliary fields, based on the organization’s requirements. Once the required fields are selected, the user will authenticate using the method enabled by the organization, and the appropriate Policies will be applied according to the assigned tags. The Device will then complete the enrollment and apply the configurations in the background. **Applying conditions and rules** Now that you have your basic Smart Enrollment configured, you can add **Conditions** 5 and **Rules** 6 that will make it smarter. ![conditions and rules](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/63afb755-bc2b-4adc-85f2-7e7ad39c6283.png) Use the **Add condition** option to enable enrollment limits based on user information (such as email patterns or groups) and device information (IMEI, Serial number, and auxiliary fields). You can use conditional operators to make it as complex as you need. ![conditions](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/2b5656eb-509a-4afd-a93c-6877b1851707.png) You can also use the **Add additional rule** option to create groups of conditions, each of them with a target policy. As you will see, each group of conditions will also have as many **Conditions** as you need. ![rules](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/d11df520-b632-4b67-8ab4-218ed719cd3a.png) Once done, click **Save**. **Deploying Smart Enrollments** To complete the process, you will need to assign Smart Enrollments to your Windows Devices. Simply click on the vertical dots next to any of your Smart Enrollments and select **View instructions** 7. This action will grant you access to the instructions side panel, where you can easily follow the provided steps. ![view instructions](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/b2fb8152-8213-4f55-84d5-8379d1aab051.png) --- ## Windows Autopilot Source: https://docs.applivery.com/en/device-management/windows/enrollment/windows-autopilot/ Description: Enroll Windows Devices with Applivery through Windows Autopilot — configure the MDM handover, deployment profile, and hardware registration for zero-touch provisioning. TL;DR: Configure Windows Autopilot with Applivery by setting the MDM handover in Entra, creating a deployment profile, registering device hardware hashes, and letting devices provision automatically on first boot. Key topics: Windows Autopilot, MDM handover, Deployment profile, Hardware registration, Zero-touch provisioning, Microsoft Entra ID, Microsoft Intune, Applivery, MDM **Windows Autopilot** is Microsoft's zero-touch provisioning technology: it lets a brand-new Windows Device configure itself the first time it's turned on, with no manual imaging or setup. When you combine Autopilot with Applivery, the device is redirected to Applivery during the out-of-box experience (OOBE) — so the Applivery Agent, your Policies, and your Apps are installed automatically the moment the user signs in. :::warning Before starting this configuration, make sure you have completed the [Microsoft Entra ID setup](https://docs.applivery.com/en/device-management/windows/enrollment/entra-id-enrollment/). Autopilot requires an **active Entra ID integration** to redirect devices to Applivery during enrollment. ::: ### 1\. Configure the MDM Handover This is the most critical step. It tells Microsoft Entra: _"Do not manage this device yourself; send it to Applivery."_ **Log in to the Azure Portal** Sign in to the [**Azure Portal**](https://portal.azure.com/) with an account that has permission to manage Mobility settings. **Open the Mobility (MDM and WIP) settings** Navigate to **Manage** > **Mobility (MDM and WIP)**. **Select your Applivery application** Click on your **Applivery** application. It should already appear listed in the mobility applications panel — if it isn't there, add it first. ![mobility mdm and wip](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/7d01e64a-8cac-4039-a2f0-0546df5b1373.png) **Set the MDM User Scope and verify the Discovery URL** Set the **MDM User Scope** to **All**, or target a specific security group by choosing **Some**. Then verify that the **MDM Discovery URL** points to the **Applivery Enrollment Endpoint**. This URL is what redirects the device away from Intune and toward Applivery — it should have been configured during the [Entra ID setup](https://docs.applivery.com/en/device-management/windows/enrollment/entra-id-enrollment/). ![mdm user scope](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/95a42853-ac3b-45bb-87b6-cb405eaae406.png) ### 2\. Create the Deployment Profile The deployment profile controls the **Out-of-Box Experience (OOBE)** — what the user sees when they turn on the computer. **Open Deployment Profiles in Intune** In the [**Microsoft Intune Admin Center**](https://intune.microsoft.com/#home), go to **Devices** > **Windows**, then to **Enrollment** > **Deployment Profiles**. :::info Creating a deployment profile requires one of these licenses: **Microsoft 365 E3**, **Microsoft 365 E5**, **Microsoft 365 F1**, **Microsoft 365 F3**, or **Microsoft 365 Business Premium**. ::: **Create a new profile** Click **\+ Create profile** > **Windows PC**. **Name your profile** Use a descriptive name that identifies its purpose, for example: `Applivery-Standard-Setup`. **Configure the OOBE settings** Configure the out-of-box experience with the following settings: - **Deployment mode**: select `User-driven`. - **Join to Microsoft Entra ID as**: select `Microsoft Entra ID joined`. - **Hide privacy settings**: set to `Hide` for a smoother experience. - **User account type**: select `Standard user` (recommended for security). **Save and assign the profile** **Save** the profile and assign it to an Entra ID group containing your target devices. The profile will be applied automatically to all devices registered in that group. ### 3\. Hardware Registration The device needs to be _"known"_ by Microsoft before it can be managed by Autopilot. **Get the hardware hash for each device** The hardware hash is a unique identifier used to register the device in Autopilot. You can obtain it by either: - Requesting the `.csv` file directly from your hardware vendor. - Running the `Get-WindowsAutopilotInfo.ps1` PowerShell script on the devices. **Open the Devices import screen in Intune** In the [**Microsoft Intune Admin Center**](https://intune.microsoft.com/#home), go to **Devices** > **Windows**, then to **Enrollment** > **Devices**. **Import the CSV file** Click **Import** and upload your `.csv` file. **Wait for the import to complete** The status will change from **Pending** to **Assigned** once the deployment profile from Phase 2 is applied. This may take a few minutes. ### 4\. Verification & Handover Once a registered device is turned on, the automatic provisioning flow begins. **Connect the device to Wi-Fi** As soon as the device connects to the internet, it recognizes its Autopilot profile automatically. **Sign in with Microsoft Entra credentials** The user is prompted to enter their corporate Microsoft account credentials during the OOBE setup. **Entra ID redirects the device to Applivery** After authentication, Entra ID verifies the user and uses the **MDM Discovery URL** configured in Phase 1 to redirect enrollment to Applivery instead of Intune. **Automatic provisioning begins** The Applivery Agent is installed automatically, and the device starts downloading your configured Policies and Apps. ![provisioning](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/afea5756-39df-4eb5-86f3-3375fe99329f.png) With Autopilot configured, every new device your organization powers on enrolls into Applivery on its own — no manual imaging, no technician touch, and your Policies and Apps applied from the very first boot. --- ## Get Started Source: https://docs.applivery.com/en/device-management/windows/get-started/ Description: Activate Windows Enterprise in Applivery to enable Windows Device Management and create Smart Enrollments for your Devices. TL;DR: Activate Windows Enterprise in Applivery to enable Windows Device Management and smart enrollments. Key topics: Windows Enterprise Activation, Applivery Dashboard, Smart Enrollment, Applivery, Windows Enterprise, Windows Device Management Before using Applivery Windows Device Management, you must enable your Workspace to interact with Windows services and register your Windows Enterprise organization. #### Activate Windows Enterprise Sign in to the [**Applivery Dashboard**](https://dashboard.applivery.io/) and navigate to the Setting section. Locate the Windows Setup section on the left-hand menu. Besides Step 1, click the **Activate** button. ![windows enterprise](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/a0290b71-fdd3-456a-a609-a17baf7c3584.png) :::tip Make sure you have the necessary permissions to activate Windows Enterprise within your Applivery account. ::: You will now be able to customize the domain to enroll Devices and start creating [Smart Enrollments](https://docs.applivery.com/en/device-management/windows/enrollment/smart-enrollment/). --- ## Policies Source: https://docs.applivery.com/en/device-management/windows/policies/ Description: Windows Policies in Applivery — configure security settings, compliance rules, and Device restrictions at scale. TL;DR: Applivery simplifies Windows device management by providing a centralized dashboard to enroll, configure, and control devices at scale. Key topics: Windows device management, Applivery, Security policies, Kiosk mode, OEM configuration Windows Policies in Applivery let you enforce security standards and configuration requirements across your managed Windows Devices. You can control system settings, enforce BitLocker encryption, configure the Firewall, manage local users, restrict features, and deploy scripts. Windows Policy settings are organized by category, with step-by-step guidance for the most common configurations. --- ## Custom ADMX Configurations Source: https://docs.applivery.com/en/device-management/windows/policies/admx-configs/ Description: Import custom ADMX and ADML templates into Applivery to manage third-party application policies on Windows Devices, beyond the built-in categories. TL;DR: Import a vendor's ADMX template into a Windows Policy from Custom Policies > Import ADMX, and manage its Group Policy settings from the Dashboard like any other configuration. Key topics: ADMX and ADML templates, Third-party application policies, Custom Policies categories, Workspace template library, Applivery, Windows, Group Policy, Google Chrome Enterprise Applivery ships with a set of built-in **Custom Policies** categories for Windows — Application Control, Assigned Access, BitLocker, Device Manageability and more — that cover the most common Group Policy settings out of the box. But plenty of what you need to manage doesn't live in those categories. Third-party applications like Google Chrome Enterprise, Adobe or Zoom publish their own **ADMX** templates, the same Group Policy file format used on-premises. For those, you can import the vendor's template directly into a Policy: Applivery reads it and turns every setting it defines into a manageable configuration, with its description, registry path and possible values, exactly like a native Applivery category. ### When to use this Import a Custom ADMX Configuration when: - You need to manage an application or component that **isn't one of the built-in Custom Policies categories**. - The vendor of that application publishes an official **ADMX** template, and optionally an **ADML** file with localized names and descriptions. - You want those settings manageable from the Dashboard, instead of resorting to [scripts](https://docs.applivery.com/en/device-management/windows/policies/scripts/) or raw registry keys. ### Importing a template **Open the Custom Policies category** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), open **Policies** 1 and choose the Windows Policy where you want to add the configuration. From the left-side menu, select **\+ Add configuration** 2, where you will find the **Custom Policies** 3 configuration. Alongside the built-in categories, you'll find an **Import ADMX** 4 search bar at the top. ![admx](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/49c4b081-75d6-42a3-84b0-3e0987fc5221.png) **Choose or upload the template** Click **Import ADMX** to open the import dialog. From here you can either: - **Select an existing ADMX configuration** — pick from templates your organization has already imported. They appear under **Recently used**, each showing its setting type and how many properties it contains, split by **device**, **user,** and **both** scopes. - **Upload new configuration** — upload a new `.admx` file, and optionally its `.adml` file for localized setting names and descriptions. :::info The ADML file is optional, but worth uploading when the vendor provides it. Without it, settings appear with their raw internal names — which makes a template of several hundred entries considerably harder to work through. ::: **Decide on user-scoped settings** Check **Apply to User Scope** if you also want the template's user-scoped settings, the ones under `HKCU`. Left unchecked, only the device-scoped `HKLM` settings are imported. **Import** Click **Import**. Applivery parses the template and adds it under **Custom Policies** as a new configuration entry, which then appears in the left side menu. ### Configuring the imported settings Open the new configuration from the left side menu. Every setting defined in the template is listed individually with: - Its display name and description, exactly as published by the vendor. - The registry path it maps to — for example `Software\\Policies\\Google\\Chrome\\LiveCaptionEnabled`. - A toggle to mark it as **Configured**, along with the value or values to set. :::info **You only configure what you care about.** Leaving a setting untouched means Applivery doesn't enforce a value for it at all — importing a template with hundreds of settings doesn't mean you're now managing hundreds of settings. ::: If the same vendor publishes more than one template — separate files for different setting groups, for instance — repeat the import under the same category with **\+ Add configuration**, without leaving the Policy. When you're done, click **Save** at the top of the Policy to push the changes to the assigned Devices. ### Your ADMX library Imported templates are stored at **Workspace level**, not per Policy. That's why they show up under **Recently used** the next time you import one into a different Policy: you upload a vendor's template once and reuse it wherever you need it. From the import dialog, **Manage** 5 opens the full list of templates uploaded to your Workspace, where you can review which ones are currently assigned to a Policy and remove the ones you no longer need. ![manage admx](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/77dd1737-075d-4ab6-be5a-761814537d7b.png) :::warning Check what a template is assigned to before deleting it. Since templates are shared across the Workspace, removing one affects every Policy currently using it — not just the one you happen to have open. ::: --- ## Agent Source: https://docs.applivery.com/en/device-management/windows/policies/agent/ Description: The Applivery Windows MDM Agent extends native Windows MDM with Self-Service options, advanced control, and improved Device Management. TL;DR: The Applivery Windows MDM Agent enhances Windows MDM by adding self-service features and advanced management capabilities. Key topics: Windows MDM Agent, Self-Service Portal, Application Catalog, Script Execution, Applivery Policies, Applivery, Windows MDM, Microsoft The **Applivery Windows MDM Agent** is an optional software component that can be installed on managed Windows Devices to extend Applivery’s management capabilities beyond the limitations of the native Windows MDM protocol. By complementing standard MDM APIs, the agent unlocks advanced functionalities that are not otherwise available through Microsoft’s built-in management framework. Before deploying the Windows Agent, it is important to understand and comply with Microsoft’s guidelines and requirements to ensure proper operation, system stability, and security alignment within enterprise environments. By using the Windows Agent, organizations gain access to deeper customization options and more comprehensive control over their Windows device fleet. This enables IT teams to implement advanced workflows, improve automation, and manage Devices more effectively, while still maintaining compliance with corporate Policies. The agent provides added value for both end users and administrators: users benefit from self-service capabilities that reduce dependency on IT, while administrators gain enhanced visibility, control, and operational efficiency. ### Self-Service One of the core features of the Windows Agent is **Self-Service**, designed to reduce IT workload by allowing users to resolve common requests independently. Through seamless integration with managed Devices, Applivery deploys a dedicated self-service environment where users can access approved resources and actions without administrator intervention. This approach improves productivity, shortens response times, and enables IT teams to focus on higher-value tasks. ![self-service-app-catalog | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/77351313-0afd-4f4e-9a0b-d8c8a13ada80.png) #### App Catalog Administrators can define a catalog of approved applications that end users are allowed to install on demand. This ensures software consistency while giving users flexibility. Detailed instructions for managing applications are available in the following [documentation](https://docs.applivery.com/en/device-management/windows/app-management/manage-apps/). #### Actions Self-Service also allows users to execute predefined scripts to assist with common tasks or resolve device-related issues. Script execution results are automatically reported back to the Applivery portal, giving administrators visibility into actions performed on Devices. Scripts can be selectively assigned to Self-Service to ensure users only have access to safe and approved operations. You can find out how to assign a script to Self Service [here](https://docs.applivery.com/en/device-management/windows/policies/scripts/). ### Enabling Windows Agent App Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), go to any of your **Policies** 1. From the left side menu, go to **Agent** 2 and **enable** it 3. ![windows agent](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/abd4250d-506e-4397-8f6a-4ac14a9f98e0.png) Once enabled and deployed, the agent will begin extending Device Management capabilities according to the selected Policy configuration. :::info All features for tracking device activity will be **coming soon**! ::: --- ## Block Websites on Edge & IE Source: https://docs.applivery.com/en/device-management/windows/policies/block-websites-edge-ie/ Description: Block specific websites on Internet Explorer and Microsoft Edge using Applivery Windows Device Management Policies. TL;DR: Block websites on Internet Explorer and Microsoft Edge using Applivery's custom policies to control web access on managed devices. Key topics: Web Filtering, Device Management Policies, OMA-URI Configuration, Internet Explorer, Microsoft Edge, Applivery, Windows, OMA-URI Blocking URLs in Internet Explorer and Microsoft Edge is a useful way to control web access on managed Devices. Whether to improve productivity, limit distractions, or enhance security, restricting access to particular websites can help organizations enforce browsing Policies effectively. With Applivery, administrators can centrally configure these restrictions to ensure that users only access approved content, creating a safer and more controlled browsing environment. ### Controlling Web Access Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), head to **Policies** 1. Choose the Policy where you want to add this configuration. **Navigate to Custom Policies** In the left-hand menu, select **\+ Add configuration** 2, search for **Custom Policies** 3, and then click **\+ Add Value** to create the new configuration. ![custom Policies](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/0e35e04b-4f94-4c3e-8a7b-5066d2f3a91f.png) Remember to select the correct policy before adding the custom configuration. Use the following OMA-URI to block websites: - **OMA-URI**: `./Vendor/MSFT/Policy/Config/InternetExplorer/DisallowRunOnSites`. - **Format**: String (chr). - **Value**: Configure a list of blocked URLs separated by semicolons. ![block websites](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/960c9127-6db1-49c8-9bac-a2827d88afe4.png) --- ## Create Local Admin Users Source: https://docs.applivery.com/en/device-management/windows/policies/create-local-admin-users/ Description: Create local administrator accounts on Windows Devices using Applivery custom Policies — automate User creation and simplify Device Management. TL;DR: Create local admin accounts on Windows devices using Applivery's custom policies and OMA-URI for streamlined device management. Key topics: Local Admin Account Creation, Applivery Custom Policies, OMA-URI Configuration, Windows Device Management, Applivery, Windows, Accounts CSP, OMA-URI Managing user permissions is a critical aspect of device security and control in enterprise environments. In certain scenarios, it’s necessary to create local administrator accounts on Windows Devices—for example, to allow IT staff to perform maintenance, deploy software, or troubleshoot issues without relying on domain credentials. With Applivery, you can automate the creation of local admin users across your fleet through policy configuration. This ensures consistent access control, simplifies device management, and reduces the risk of manual errors. Using the **Accounts CSP** through Applivery’s **Custom Policies** configuration, you can deploy OMA-URI–based Policies to create a local user and assign them administrator rights. **User creation** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), head to **Policies** 1. Choose the Policy where you want to create an admin user. Next, in the left-hand menu, select **\+ Add configuration** 2, search for **Custom Policies** 3, and then click + Add Value to create the new configuration. ![custom Policies](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/beb5c7a9-44ca-41c1-91ad-aa66ead38dbd.png) Use the following OMA-URI to create a new local user account: - **OMA-URI**: `./Device/Vendor/MSFT/Accounts/Users//Password`. `` represents the local username—replace it with the desired name for the new user account. - **Format**: String (chr). - **Value**: This value sets the password for the local account—replace it with the password you want to assign. **Make the user administrator** To make the newly created user a local administrator, apply this OMA-URI: - **OMA-URI**: `./Device/Vendor/MSFT/Accounts/Users//LocalUserGroup`. - **Format**: Integer (int). - **Value**: 2 (this value describes the local administrators group). :::warning If you already manage the local administrators group memberships through the “Local Users and Groups” configuration template, you must add the newly created account in the XML config; otherwise, the newly created account might lose its local admin permissions. ::: --- ## Delete Inactive User Profiles Source: https://docs.applivery.com/en/device-management/windows/policies/delete-inactive-user-profiles/ Description: Automatically delete inactive User profiles on Windows Devices with Applivery to improve system performance and reduce storage consumption. TL;DR: Automatically delete inactive Windows user profiles to optimize system performance and storage using Applivery's device management policies. Key topics: Windows User Profile Management, Automatic Profile Deletion, Applivery Device Management, Storage Optimization, System Performance, Windows, Applivery, User Profile Service Windows **User Profile Management** includes a setting that allows admins to automatically **delete user profiles** that have been inactive for a specified number of days upon system restart. This feature helps organizations maintain cleaner systems by removing old, unused profiles, which can reduce storage consumption and improve overall system performance. When enabled, the **User Profile Service** will check all profiles on the Device during the next restart and delete those that have not been accessed within the configured time frame, measured in 24-hour periods since their last use. This automatic cleanup ensures that only active users maintain profiles on the system, reducing clutter and potential security risks associated with stale profiles. If this Policy is disabled or not configured, user profiles will remain unchanged, meaning all profiles, regardless of activity, will persist on the system. In managed environments, this Policy can be centrally configured and deployed across Windows Devices, enabling IT teams to enforce consistent user profile maintenance and optimize device health and storage management effectively. ### Automatic deletion of inactive profiles Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), head to **Policies** 1. Choose the Policy where you want to add this configuration. Next, in the left-hand menu, select **\+ Add configuration** 2, and search for **User Profiles** 3. ![user profiles](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/830de90e-fe34-4a70-9b18-97a5de1e9376.png) Locate the **Delete user profiles older than a specified number of days on system restart > Cleanup Profiles** setting, and specify the number of days after which inactive user profiles will be deleted automatically on system restart. ![delete user profiles](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/191c5af9-fe1d-405f-be53-989afe6ab97c.png) --- ## Deploy BitLocker Source: https://docs.applivery.com/en/device-management/windows/policies/deploy-bitlocker/ Description: Turn on BitLocker encryption from a Policy and escrow the recovery key directly to Applivery — no Entra ID or Active Directory join required. TL;DR: Encrypt a Windows Device from a Policy through the Applivery Windows Agent and read the recovery key straight from the Dashboard. No directory join required. Key topics: Agent-managed BitLocker, Encryption method and type, Recovery key retrieval, Conflicts with native BitLocker, Applivery, BitLocker, Windows, Entra ID, Active Directory, TPM Applivery deploys BitLocker through the Applivery Windows Agent, which handles encryption and recovery-key escrow itself, with no need to join the Device to **Entra ID** or **Active Directory**. You encrypt the volume from a Policy, and the recovery key lands in the Applivery Dashboard where you can read it whenever you need it. ### Prerequisites BitLocker synchronization here is carried out by the [Windows Agent](https://docs.applivery.com/en/device-management/windows/policies/agent/). :::warning **Without the Agent installed on the Device, BitLocker cannot be used** through this configuration. Make sure the Agent is enabled for the Device's Segment before you configure anything. ::: A TPM (Trusted Platform Module) is recommended, though not strictly required, for stronger key protection and secure device startup. ### Enabling BitLocker **Open the Policy** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), head to **Policies** 1 and choose the **BitLocker** 2 configuration. ![bitlocker](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/52e2fc22-0d0b-4935-b08b-0e74aab2001d.png) **Choose the encryption state** Set **BitLocker encryption** to one of these:

Option

Effect

Not configured

No action taken. Leaves the Device's current encryption state unchanged.

Encrypted

Activates BitLocker encryption and securely backs up the recovery key to Applivery.

Unencrypted

Decrypts the Device — the opposite of Encrypted.

![encryption](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/2972fd42-d155-4733-b5d9-d745d273d29d.png) **Set the encryption method and type** When you set it to **Encrypted**, two more settings appear: - **Encryption method**: the algorithm BitLocker uses to encrypt the drives — `AES-CBC 128-bit`, `AES-CBC 256-bit`, `XTS-AES 128-bit`, or `XTS-AES 256-bit`, which is the recommended option and the default. - **Encryption type**: whether to encrypt the **full drive** or **used space only**, which is the recommended option and the default. **Save** Click **Save changes**. ### Retrieving the recovery key Once a Device reports back as encrypted, open that Device's **Settings** tab and select **BitLocker** from the left-hand menu. - **State**: a status badge (`Encrypted`) plus the raw protector status line, which distinguishes a `PERMANENT` protector from a `ONETIME` one, and when it was last updated. - **Recovery keys**: the permanent recovery key for the Device, with a one-click copy button. - **Temporary recovery keys**: a separate, one-time recovery key, also copyable. There is no dependency on Entra ID or Active Directory to look any of this up. It is stored and retrieved directly through Applivery. ### Avoiding conflicts with native BitLocker settings If the same Policy — or another one affecting the same Device — also configures BitLocker natively, Applivery warns you right in the configuration screen. That includes a Custom ADMX Configuration and the built-in native **Bit Locker** CSP category. :::warning **Also configured natively** — The "Encryption" section configures 1 native BitLocker properties that Windows enforces on its own. Settings that contradict the ones below make the Device report an encryption mismatch — keep them aligned or manage BitLocker from only one of the two places. ::: In practice: pick **one** method per Device, agent-managed BitLocker or the native CSP-based one, rather than configuring both. That is what keeps the Device from reporting an encryption mismatch. --- ## Disable Manual Unenrollment Source: https://docs.applivery.com/en/device-management/windows/policies/disable-manual-unenrollment/ Description: Prevent Users from manually unenrolling Windows Devices from Applivery MDM — enforce persistent management with a Policy. TL;DR: Disable manual MDM unenrollment on Windows devices via Applivery policy to maintain control and security compliance. Key topics: MDM, Windows, Applivery, Device Management, Security Policy By default, Windows allows users to manually disconnect their Device from a Mobile Device Management (MDM) provider. In managed environments, this can pose a risk, as it enables end users to bypass security or compliance configurations. To maintain control and ensure persistent management, you can disable this option by configuring a Policy. ### Disabling manual MDM removal **Navigate to Policies** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), head to **Policies** 1. Choose the Policy where you want to add this configuration. **Add Configuration** In the left-hand menu, select **\+ Add configuration** 2, and search for **Experience** 3. ![experience](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/f631bcc5-3b7d-4a73-82ad-c9f4bc04d5a1.png) **Disable Manual Unenrollment** Locate the **Allow Manual MDM Unenrollment** setting and set its value to **0**. This will prevent users from manually unenrolling the Device from Applivery. ![disallow user unenrollment](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/e52b44b2-6dc1-4186-9b40-b9b14e2eb8c5.png) --- ## Disable Microsoft Consumer Experiences Source: https://docs.applivery.com/en/device-management/windows/policies/disable-microsoft-consumer-experiences/ Description: Disable Microsoft Consumer Experiences on Windows Devices with Applivery to prevent unwanted App installations and improve corporate management. TL;DR: Disable Microsoft Consumer Experiences on Windows to prevent unwanted app installations and improve corporate device management. Key topics: Microsoft Consumer Experiences, Windows configuration, Device management policies, Microsoft, Windows, Applivery, Microsoft Store Microsoft Consumer Experiences is a feature built into Windows that delivers app recommendations, notifications, and offers to users, often including automatic installation of suggested Apps from the Microsoft Store. While designed to enhance user experience by providing personalized content, it can lead to unwanted Apps appearing on corporate Devices, causing distractions and potential security concerns. Disabling Microsoft Consumer Experiences allows IT administrators to prevent these auto-installations and tailored suggestions, ensuring a cleaner, more controlled environment on Windows Devices. This feature limits the use of diagnostic data for personalized experiences, reducing data sent to Microsoft for these purposes and helping organizations enforce stricter privacy and security Policies. By turning off these consumer features, organizations can better manage corporate Devices, avoid unapproved software installations, and maintain a more focused IT environment. ### Disabling Microsoft Consumer Experiences **Navigate to Device Management and Policies** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), head to **Policies** 1. Choose the Policy where you want to add this configuration. **Add Configuration and Search for Experience** Next, in the left-hand menu, select **\+ Add configuration** 2, and search for **Experience** 3. ![experience](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/3c3da182-fbd4-457d-b8c9-60a1ed45c5ec.png) **Disable Windows Tips** Locate the **Do not show Windows tips** setting and set its value to **0**. This will disable Windows tips for all users. ![do not show windows tips](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/40b5e078-f4bc-416d-a9f7-bcdef0876f7b.png) --- ## Disable Mobile Data Source: https://docs.applivery.com/en/device-management/windows/policies/disable-mobile-data/ Description: Disable mobile data on Windows Devices using Applivery Policies — control data usage, enhance security, and enforce network restrictions. TL;DR: Learn how to disable mobile data on Windows devices using Applivery to control data usage and enhance security. Key topics: Mobile data management, Windows device policies, Applivery configuration, Network security, Data usage control, Windows, Applivery, Device Management, Cellular Data Disabling mobile data on Windows Devices is an essential step for organizations aiming to optimize connectivity, control data usage costs, and enforce network security Policies. With growing reliance on Windows laptops, tablets, and hybrid Devices that support cellular connections, managing mobile data access remotely is crucial to prevent unauthorized usage and reduce unexpected charges. Windows provides built-in settings and policy controls to allow IT administrators to disable or restrict mobile data usage across corporate Devices. By leveraging these capabilities through Applivery, organizations can centrally configure mobile data restrictions, ensuring Devices adhere to corporate Policies while minimizing disruption to user workflows. Disabling mobile data enhances security by limiting Devices to approved networks, reducing risks associated with unsecured cellular connections. It also supports compliance requirements by preventing data leaks and controlling network traffic. Furthermore, managing mobile data effectively helps extend battery life and ensures predictable network performance. ### Disabling mobile data Policies"> Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), head to **Policies** 1. Choose the Policy where you want to add this configuration. **Add Connectivity Configuration** In the left-hand menu, select **\+ Add configuration** 2, and search for **Connectivity** 3. ![connectivity](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/59220abb-6cff-47de-be1d-8666d0728d5c.png) **Configure Cellular Data** Locate the **Allow cellular data** setting and set its value according to your specific requirements. ![disallow celular data](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/cfeb7d10-37b7-4c33-8f35-e2e341a2734c.png) --- ## Manage Clipboard History Source: https://docs.applivery.com/en/device-management/windows/policies/manage-clipboard-history/ Description: Manage Windows Clipboard History with Applivery Policies — control data storage and sharing to balance User productivity and security. TL;DR: Manage Windows Clipboard History via Applivery to balance user productivity with enterprise data security. Key topics: Windows Clipboard History, Device Management Policies, Security Configuration, Applivery Dashboard, Windows, Microsoft, Applivery, Clipboard History Windows **Clipboard History** is a powerful productivity feature that allows users to store multiple copied items—such as text, images, and links—in a history accessible via a simple keyboard shortcut. This feature supports pinning frequently used items for quick access and syncing clipboard data across Devices through Microsoft accounts, enabling seamless workflows on multiple Windows Devices. From an IT management perspective, controlling Clipboard History centrally is essential to balance user productivity with security. Administrators can enable or disable this feature to prevent sensitive data from being stored or shared unintentionally. Understanding and managing Windows Clipboard History empowers organizations to enhance user efficiency while safeguarding information, making it a key component in enterprise device management. ### Configuring your Policy **Navigate to Device Management** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), head to **Policies** 1. Choose the Policy where you want to add this configuration. **Add Configuration** In the left-hand menu, select **\+ Add configuration** 2, and search for **Experience** 3. ![experience](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/b5946fdf-5443-46e9-894a-f2c3235c0d9d.png) **Configure Clipboard History** Locate the **Allow Clipboard History** setting to determine whether the history of Clipboard contents can be stored in memory. ![allow clipboard history](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/aa1f7db7-aa61-4486-b707-022ab2d47f78.png) --- ## Manage Local Administrators Source: https://docs.applivery.com/en/device-management/windows/policies/manage-local-admins/ Description: Centrally manage the Local Administrators group on Windows Devices using Applivery — add or remove Users and groups via Policies. TL;DR: Centrally manage the Local Administrators group on Windows devices with Applivery using policy configurations to add or remove users and groups. Key topics: Local Administrators group management, Applivery device management, Group Policy configuration, XML configuration for user management, Windows security, Applivery, Windows, Local Administrators group, XML, Administrator, SID Managing the Local Administrators group is essential for maintaining security and operational control over Windows Devices. Granting administrative access only to trusted users or service accounts helps prevent unauthorized changes, limits the attack surface, and ensures compliance with organizational Policies. With Applivery, you can centrally manage the Local Administrators group on all enrolled Windows Devices by applying a Policy configuration. This allows IT administrators to add or remove specific users or groups from the local administrators group across the entire device fleet—automatically and consistently. :::info This group policy can manage various local groups; the steps below configure the Local Administrators group. ::: ### Local Users and Groups Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), head to **Policies** 1. Choose the Policy where you want to create an admin user. Next, in the left-hand menu, select **\+ Add configuration** 2, and search for **Local Users And Groups** 3.  ![local users and groups ](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/d6480006-6df0-4a45-85db-5430f31ef94e.png) We will use the following template: ```xml ``` Here's a breakdown of the XML elements: - ``: Encloses the entire group management configuration. - ``: Defines the local group you want to manage (e.g., Administrators). - ``: Specifies how the group membership should be managed: - **U** = Update: Modifies the group by adding or removing only the specified members. Existing members not mentioned will remain unchanged. - **R** = Replace: Clears all current members and replaces them with the ones defined. Use **only** `` with this action. - ``: Adds a user or group to the specified access group. - ``: Removes a user or group from the specified access group. :::warning This configuration does not create new users or groups; it only manages those that already exist on the Device. ::: #### Administrator group management example In this example, our goal is to **replace all current members** of the local **Administrators** group with only the users explicitly defined in the XML configuration. **Current group state** The existing Administrators group contains three users. ![](https://www.applivery.com/wp-content/uploads/2025/07/image-3.png "members | Applivery") **Target group** We define the group we want to manage—in this case, the **Administrators** group. This can be identified in two ways: - **By name**: Use **Administrators** if all your Devices share the same OS language. - **By SID**: Use the well-known **SID S-1-5-32-544** to avoid localization issues, since the group name varies depending on the operating system’s language. **Group action – Replace** We use the **R (Replace)** action in the `` node. This will remove all current members of the group and replace them with those defined in the XML. **Define members** Use `` to specify the users or groups you want to include. In this case, we want only **Administrator** and **Applivery** to remain in the group. ![configure group](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/3cea4f53-2104-4d38-bb43-c190b3989f96.png) **Outcome** Once deployed, the **Administrators** group will contain **only** the users defined in the XML. All others will be removed. ![](https://www.applivery.com/wp-content/uploads/2025/07/image-4.png "final-admins-group | Applivery") :::info If you’re managing the built-in **Administrator account**, remember that its name also varies based on the OS language. To avoid inconsistencies, you can rename it across all Devices using the **Accounts Rename Administrator Account** setting under the **Local Policies Security Options** group policy. ::: ![rename account](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/da2736ce-9407-4372-a136-45c5879806f7.png) #### Downgrading users from Administrator to standard A common compliance scenario — for example, to meet ISO 27001 requirements — is moving users from the Administrators group to the standard Users group. When Windows downgrades a user from Administrator to standard, it does not automatically add them to the Users group, leaving the user without any group membership and unable to access the device. To handle both actions at once, configure a single XML with two blocks — one to remove the user from Administrators (`S-1-5-32-544`) and another to add them to Users (`S-1-5-32-545`): ```xml ``` Replace `ExactUsername` with the username exactly as it appears on the device, and `BackupAdminName` with your organization’s backup administrator account. :::warning The built-in Windows Administrator account cannot be removed from the Administrators group — this is enforced at the OS level. Always include at least one named administrator in the `` line of the Administrators block to avoid this error. ::: :::info You can use `member="*"` to target the currently logged-in user instead of a specific username. If `*` does not produce the expected result, replace it with the exact username as it appears on the device. ::: :::warning Only one Local Users and Groups XML configuration can be active per device. If you need to manage multiple groups, include all `` blocks within the same `` element — never apply two separate policies to the same device. ::: * * * ### Troubleshooting #### Verifying that the policy was applied correctly To check whether the configuration was applied on a device, open **Event Viewer** (`eventvwr.exe`), navigate to **Applications and Services Logs → Microsoft → Windows → DeviceManagement-Enterprise-Diagnostics-Provider → Admin**, and search for `LocalUsersAndGroups`. #### `PutOrAddCommandFailedBecauseTargetAlreadyExists` :::warning This error does not necessarily mean the policy failed. It appears when Windows attempts to add a user who is already considered a member of that group — either directly or through implicit inheritance. For example, members of the Administrators group inherit Users group permissions at the OS level, so Windows may report this error even though the user is not explicitly listed in the Users group. ::: To confirm whether the configuration has been applied correctly, verify the group membership directly on the device via **Computer Management → Local Users and Groups → Groups**. --- ## Multi-App Kiosk Mode Source: https://docs.applivery.com/en/device-management/windows/policies/multi-app-kiosk-mode/ Description: Configure Windows Multi-App Kiosk Mode in Applivery — restrict Device access to specific Apps using OMA-URI and XML configuration. TL;DR: Configure Windows Multi-App Kiosk mode to run multiple approved applications under strict control using OMA-URI settings and XML configuration. Key topics: Windows Kiosk Mode, OMA-URI Configuration, Assigned Access, Shared PC Mode, Microsoft, Windows, Applivery, OMA-URI, PowerShell, Command Prompt Windows Kiosk in Multi-App mode is designed for scenarios where a Device must run more than one approved application under strict control. Unlike traditional single-app kiosks, this configuration supports multiple Apps while enforcing restrictions that prevent unauthorized use. Administrators can define the App set and manage user access consistently across Devices. This ensures a locked-down environment that is secure and aligned with organizational requirements. ### Configuration for a multi-app kiosk Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), head to **Policies** 1 and select the Policy you want to configure for a multi-app kiosk. Next, in the left-hand menu, select **\+ Add configuration** 2, search for **Custom Policies** 3, and then click **\+ Add Value** to create the new configuration. ![custom Policies](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/0eb84727-8321-4553-af4c-a3300066ec3e.png) **Create a kiosk user** Use the following OMA-URI to create a kiosk user: - **OMA-URI**: `./Device/Vendor/MSFT/Accounts/Users/$USERNAME/Password`. Replace the `$USERNAME` variable in the OMA-URI with the desired username. - **Format**: String (chr). - **Value**: This value sets the **password** for the kiosk user. **Enable Shared PC Mode** Use the following OMA-URI to enable Shared PC Mode: - **OMA-URI**: `./Vendor/MSFT/SharedPC/EnableSharedPCMode`. - **Format**: Boolean (bool). - **Value**: `true`. Enables Shared PC Mode, optimizing the Device for multiple users with restricted access. **Define the account model in Shared PC Mode** Defines the account model in Shared PC Mode: - **OMA-URI**: `./Vendor/MSFT/SharedPC/AccountModel`. - **Format**: Integer (int). - **Value**: `2` (this indicates a mode with disposable or restricted accounts). **Configure Assigned Access Mode** Defines the account model in Shared PC Mode: - **OMA-URI**: `./Vendor/MSFT/AssignedAccess/Configuration`. - **Format**: String (chr). - **Value**: ```xml _[App]_ _[App]_ _[App]_ _[App]_ _[App]_ _[App]_ _[App]_ _[App]_ _[Taskbar]_ _[AutoLogonAccount]_ _[DefaultProfile]_ ``` :::note The **Profiles Section** defines a profile with a unique ID (`{9A2A490F-10F6-4764-974A-43B19E722C23}`) and specifies a whitelist of allowed applications under ``. This includes UWP Apps such as Microsoft Calculator, Photos, and Bing Weather, as well as desktop Apps like Command Prompt, PowerShell, and File Explorer. **File Explorer restrictions** (`rs5:FileExplorerNamespaceRestrictions`) are applied to allow access to the Downloads folder only, while still permitting the use of removable drives. The **Start Menu** pinned Apps (`v5:StartPins`) section defines which applications appear pinned to the Start Menu, corresponding to the allowed Apps. **Taskbar** configuration is enabled (`_[Taskbar]_`), ensuring the taskbar is visible in kiosk mode. In the **Configs Section**, **Auto Logon** automatically signs in the user, with `$USERNAME` replaced by the actual username for the kiosk. Profile assignment sets the defined profile as the default. Ensure you replace `$USERNAME` in the `` element with the username of the previously created user intended for this kiosk mode. ::: :::warning **Installing the App and allowing it are two separate things.** The App Policy installs the application on the machine; the Assigned Access XML decides what the kiosk user can actually launch. An App that installed perfectly stays unreachable in kiosk mode if it is missing from ``. This differs from Android, where the Apps in the Policy are allowed in kiosk mode automatically. On Windows the list is maintained separately, so every new App has to be added in both places. ::: --- ## Password Policies Source: https://docs.applivery.com/en/device-management/windows/policies/password-policy/ Description: Enforce a password or PIN policy and automatic screen lock on Windows Devices with the Passcode configuration in Applivery. TL;DR: Turn on Device Password Enabled in the Passcode configuration, then set length, complexity, expiration, history and screen lock for local accounts on Windows. Key topics: Passcode configuration, Password length, complexity and expiration, Password history and screen lock, Reviewing OMA URIs, Applivery, Windows, Microsoft Entra ID, BitLocker, OMA URI, CSP Enforce a password or PIN policy and automatic screen lock on your Windows Devices with the **Passcode** configuration. ### Requirements - Windows 10 1507 or later, or Windows 11, in any edition. - The rules apply to **local accounts**. Microsoft Entra ID and domain accounts follow the password policy of their own directory. ### Configure the password policy **Create or open the Windows Policy** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), head to **Policies** 1. Choose the Policy where you want to add this configuration. In the left-hand menu, select **\+ Add configuration** 2, and search for **Passcode** 3. ![passcode](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/d8c14a62-d92e-4360-9df4-78d9fa8a5f25.png) **Turn on the password requirement** In **Basic requirements**: 1. Set **Device Password Enabled** to **0 Enabled**. This is the main switch: while it stays on **1 Disabled**, which is the default, every other rule in the form is ignored. 2. Set **Allow Simple Device Password** to **0 Not allowed** to block trivial PINs like 1111 or 1234, and picture passwords on desktop. ![basic requirements](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/e38b011b-5252-4842-a96a-444697054bce.png) **Define length, complexity and expiration** 1. **Alphanumeric Device Password Required**: **0 Password or Alphanumeric PIN required**. 2. **Min Device Password Length**: 12. The default value is 4. 3. **Min Device Password Complex Characters**: **2 Digits and lowercase letters are required**. 4. **Device Password Expiration**: 90 days. Leave it empty so the password never expires. ![other configs](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/65b9dd3c-ed3d-41d1-a5e7-6608e15ddecd.png) The complexity dropdown shows which values Windows accepts on desktop. Values **3** and **4** are marked in the list itself as not supported for desktop accounts, so stick to **1** or **2** on PCs. **Set password history and screen lock** Scroll to the end of **Basic requirements** and configure **Lock and unlock**: 1. **Device Password History**: 5. Users can't reuse their last five passwords. 2. **Max Inactivity Time Device Lock**: 5 minutes. The Device locks and asks for the password after that much inactivity. 3. **Max Device Password Failed Attempts**: 10. On desktop, this does **not** wipe the Device: it sends it to BitLocker recovery, and it only works if [BitLocker](https://docs.applivery.com/en/device-management/windows/policies/deploy-bitlocker/) is turned on. ![lock and unlock](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/941ea8eb-164e-4799-8aaf-f2e8d312deb0.png) **Review, save and assign** 1. Open **Summary** and set **View summary as** **OMA URIs** to check the exact nodes and values that will be sent to the Device. 2. Click **Save changes**. Nothing reaches the Devices until you save. If you leave the page before saving, Applivery asks whether you want to discard the draft. 3. Assign the Policy to a Device from **Assigned devices** by clicking **+ Assign to device**, or to a group or Segment. ### What the user experiences If the user's current password doesn't meet the Policy, Windows asks them to change it at their next sign-in. ### Notes - Microsoft only documents **Allow Idle Return Without Password** for HoloLens. - There is no CSP to unlock a locked local account remotely. This Policy only prevents and limits failed attempts. --- ## Enable Remote Desktop Source: https://docs.applivery.com/en/device-management/windows/policies/remote-desktop/ Description: Enable or disable Remote Desktop on Windows Devices using Applivery Policies for secure and controlled remote access management. TL;DR: Enable or disable Remote Desktop on Windows devices using Windows policies through the Applivery platform for secure remote access management. Key topics: Remote Desktop Services, Windows Policies, Applivery Device Management, Remote Desktop, Windows, Applivery Configuring Remote Desktop through Windows Policies empowers administrators to provide secure, controlled remote access to managed Devices. Leveraging **Remote Desktop Services**, organizations can enable remote connections for users within the Remote Desktop Users group, ensuring authorized personnel can access corporate resources efficiently. Applivery further simplifies centralized deployment and management of these configurations across Windows device fleets, allowing IT teams to maintain robust security, enforce company Policies, and streamline remote troubleshooting. ### Enable Remote Desktop Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), head to **Policies** 1. Choose the Policy where you want to add this configuration. Next, in the left-hand menu, select **\+ Add configuration** 2, and search for **Remote Desktop Services** 3. ![remote desktop services](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/bee093e8-549d-4494-9916-86859c6f66ac.png) Locate the **Allow users to connect remotely by using Remote Desktop Services** setting and choose either to enable or disable it, as needed. ![allow users to connect remotely by using remote desktop services](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/d29d7ce7-92ae-4887-a1de-53a9052d7a28.png) --- ## Restrict External Device Access Source: https://docs.applivery.com/en/device-management/windows/policies/restrict-external-device-access/ Description: Secure your Windows devices by restricting external hardware access. Learn how to block USB drives, control device installations, and protect company data. TL;DR: Learn how to restrict external device access on Windows devices using Applivery to enhance security and protect sensitive data. Key topics: Blocking removable storage, Controlling device installations, Using Class GUIDs, Applivery policy configuration, Applivery, Windows, USB drives, Class GUIDs, Device Manager External Devices such as USB drives, external hard disks, and portable media can pose serious security risks in enterprise environments. They can be used to transfer sensitive data, introduce malware, or bypass corporate access controls. For organizations that manage Windows Devices at scale, restricting external device usage is a critical step in maintaining compliance and protecting company data. Applivery enables IT administrators to enforce these restrictions easily through policy configuration. By using the appropriate group policy settings, you can block or limit access to specific types of external Devices across your entire device fleet—without relying on manual intervention. ### Blocking Removable Storage Devices **Navigate to Policies** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), head to **Policies** 1. Choose the Policy where you want to add the configuration. **Add Removable Storage Configuration** In the left-hand menu, select **\+ Add configuration** 2 and search for **Removable Storage 3**. ![removable storage](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/daccba2d-3933-4acb-aece-0805f1dc4218.png) **Deny all access** Locate the configuration and enter **All Removable Storage classes: Deny all access**. When enabled, it blocks read, write, and execute access to all removable storage Devices. ![deny all access](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/17a43dac-4f3d-4668-a476-7476f31a35f0.png) ### Block External Device Installations :::info If the Device was connected before the Policy was applied, it won’t be blocked—its driver is already installed. This approach is more complex and best suited for advanced scenarios. If your goal is simply to block removable storage, we recommend using the configuration described earlier. ::: Another way to block external Devices is by allowing only specific types of Devices to be installed. **Add Device Installation Configuration** In the left-hand menu, select **\+ Add configuration** 4 and search for **Device Installation** 5. ![device installation](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/2575d003-d600-475c-911d-8c91aab7efb4.png) **Enable Device Installation Settings** Locate the relevant configuration and enable the following two settings: \- **Prevent installation of Devices not described by other policy settings**. \- **Allow installation of Devices using drivers that match these device setup classes**. This combination blocks all device installations except those explicitly allowed. To allow specific Devices, you’ll need to define their **Device Setup Classes**, also known as **Class GUIDs**. You can find these in **Device Manager** on a Windows machine by opening the Device’s properties and navigating to the **Details** tab. ![](https://www.applivery.com/wp-content/uploads/2025/07/image-2.png "class-guids | Applivery") #### Common Class GUIDs | Device type | Class GUID | | --- | --- | | Mice and keyboards | `{4d36e96f-e325-11ce-bfc1-08002be10318}` | | Audio endpoint | `{c166523c-fe0c-4a94-a586-f1a80cfbbf3e}` | | Camera | `{ca3e7ab9-b4c3-4ae6-8251-579ef933890f}` | | Monitor | `{4d36e96e-e325-11ce-bfc1-08002be10318}` | | Media (audio and video) | `{4d36e96c-e325-11ce-bfc1-08002be10318}` | ### Other Methods to Control Device Installation Controlling device installation isn’t limited to Class GUIDs. Applivery also provides other configuration templates to give you more granular control: - Block specific **Device IDs** (Hardware IDs). - Allow only specific **Device IDs**. - Block entire **Device Setup Classes** (Class GUIDs) - Allow entire **Device Setup Classes**. - Use **Device Instance IDs**. - And more… --- ## Scripts Source: https://docs.applivery.com/en/device-management/windows/policies/scripts/ Description: Create and assign Scripts to Windows Devices using Applivery for automated task management and IT process efficiency. TL;DR: Learn to automate device management tasks by creating and assigning scripts using Applivery, enhancing efficiency and reducing manual effort. Key topics: Script creation, Script assignment, Automation methods, Applivery Dashboard, Device management, Applivery, Windows, AI Assistant, Public Script Repository A computer script is essentially a sequence of instructions (commands) that the computer executes, making it an excellent tool for automating repetitive tasks. Scripts are highly scalable and versatile. Because scripts can be deployed to user Devices through device management solutions (such as Applivery), they are invaluable for IT teams. They enable you to perform complex tasks quickly, accurately, and effortlessly: - **Quickly**: By using scripts alongside mobile device management, you can automate tedious processes. For example, you can access a computer program on 100 company Devices with zero clicks instead of doing it manually 100 times. - **Accurately**: A well-written script will consistently execute the same defined action every time, reducing the risk of errors that might occur if a human administrator were to perform the task manually, which can lead to inconsistencies and confusion. - **Easily**: You can achieve complex and detailed tasks by breaking them down into smaller, manageable scripts, making the overall process much simpler. **Create your first script** Go to the [**Applivery Dashboard**](https://dashboard.applivery.io/) and navigate to **Resources** 1, then navigate to the **Scripts** 2 section and click on **\+ Create Script** 2. ![scripts](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/734eb61d-eb12-4337-8276-0ff556f5aa0e.png) A code editor will appear on the screen. Within the editor, you can either create a new script or upload an existing one from your Device, allowing you to easily tailor scripts to your needs. To create a new script, use the editor interface and start typing. First, select the desired language—**PowerShell** 4 in this case. To upload an existing script, click **Load from file** 5, select your script, and it will be ready to use. Finally, provide a **Name** 6 (and optionally a description), then click **Create** 7. ![create script](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/2df9cb03-5e86-4876-a7b3-a9f006ffced9.png) :::info If you need help creating a script, you can also use our **AI Assistant**. Just click the corresponding button, and a dialog box will appear where you can describe the script you need. Our assistant will then generate it for you. ::: :::warning Note that the AI Assistant is a premium feature that might not be available in your current plan. Check the availability on our [pricing page](https://www.applivery.com/device-management-pricing/). ::: **Assign Scripts to your Devices** Now, navigate to the **Devices** 8 section, choose the Device to which you want to assign a script, go to the **Scripts** 9 tab, and click on the **\+ Assign Script** 10 button. ![assign script](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/2c307f86-abc3-4bbc-9161-99defc7d8e21.png) A modal view will appear, allowing you to choose a script from the script section or upload it from your Device. You will also have the option to select the execution method and add the script’s arguments: - **Once**: The script will run once per device. You will also have the option to repeat the execution, even if it has already been executed. - **Loop**: The script will run cyclically at the chosen time interval. - **On-demand**: The script will never be run automatically and will only be offered as an optional item from Self-Service. ![script form](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/7dab607d-f8e2-45f2-8d51-66fd4af7777b.png) By clicking the **Execution history** 11 button, you can view the execution history of all your scripts. You can also access the execution history of a specific script by clicking on the script itself or the three vertical dots at the end of the script. Clicking these dots will also display additional actions: - **Edit**: Edit the script. - **Unassign**: Unassign the script from the Device. - **View**: View the original script in the asset section. :::warning For scripts with the **Once** execution method, you will also see the **Repeat execution** option. In addition to allowing a script to be retried after a failure, this option also determines whether a script with the same ID can be executed again on a Device where it has already run, even if that execution took place in the past. This ensures that the script will be sent again, regardless of its prior execution history on that Device. ::: ![script options](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/411511ef-8a8d-4b00-a323-e10420b6f97f.png) **Assign Scripts to your Policies** Scripts don't have to be assigned Device by Device. Assigning one to a Policy covers every Device that Policy applies to, which is the practical route for anything meant to run across a fleet rather than on a single machine. From any of your **Policies** 12, go to the **Scripts** 13 section in the left-side menu and click **\+ Add Script** 14. The same modal described in the previous step appears, with the same execution methods and arguments. ![assign to policy](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/6d671e51-70d5-43e4-ab44-4e8087c6a3a7.png) Once you save the changes, the Scripts assigned to that Policy are deployed to every Device carrying it on their next sync. ### Script arguments When assigning a script, the **Arguments** field lets you pass parameters to your script at execution time. Applivery splits the field by whitespace, so every space-separated value is treated as a separate parameter. #### Multi-word parameters If a parameter contains spaces, wrap it in double quotes so Applivery treats it as a single value: ``` --label “My Application” ``` Without the quotes, `My` and `Application` would be passed as two separate parameters instead of one. #### Interpolated variables Applivery supports mustache-style variables that are replaced at execution time with real device or user data. Because a variable can expand to a value that contains spaces, always wrap interpolated variables in double quotes when you need them treated as a single parameter: ``` “{{user.name}}” ``` If `{{user.name}}` resolves to `John Doe`, the quotes ensure it is passed as one parameter instead of two. Without them, `John` and `Doe` would reach your script as separate arguments. The following variables are available:

Variable

Resolves to

{{device.id}}

Unique device identifier

{{device.displayName}}

Device display name

{{device.serialNumber}}

Device serial number

{{device.osVersion}}

Operating system version

{{device.chip}}

Processor/chip type

{{device.hostName}}

Device hostname

{{user.id}}

Unique identifier of the assigned user

{{user.email}}

Email address of the assigned user

{{user.name}}

Full name of the assigned user

#### Escaping special characters To include a special character literally in an argument, prefix it with a backslash (`\`). This is useful when passing values like Windows paths or strings that contain double quotes: ``` C:\\Program Files\\MyApp ``` This passes `C:\Program Files\MyApp` as the argument value. To include a literal double quote inside a quoted parameter: ``` “He said \”hello\”” ``` * * * ### Reviewing what a Script actually did Assigning a Script tells the Device what to run. The **Scripts** tab of that Device tells you what happened when it did. Every assigned Script is listed there with its settings and a running tally of its results:

Column

What it shows

Name

The Script's name and file, for example Restart Device.ps1.

Arguments

The arguments passed to it at execution time, if any.

Execution

Its execution method — Once, Loop with its configured interval, or On-demand.

Scope

Whether it runs as Machine, under the SYSTEM account, or as the logged-in user.

Runs

How many times it has executed on this Device so far.

From

Whether it comes from a Policy or was assigned directly to this Device.

Segment

The Segment the assignment belongs to.

Last Date

When it last ran.

Between **Runs** and **Last Date** you can usually tell at a glance whether something is stuck: a Loop Script whose last run is days old, or a Once Script still showing zero runs, is a Script that never reached the Device. #### Is it a delivery problem or an execution problem? The **Scripts** tab of the Device answers that in one glance, through the **Executions** and **Last date** columns: - **Executions at zero** — the Script never reached the Device. It is a delivery problem, so check the assignment and the Device's sync. - **Executions with an old date** — it did reach the Device and ran, then something stopped it afterwards. Four causes cover most of it: - **Execution method Once** never runs again on a Device that already ran it, unless you turn on **Repeat execution**. - **Execution method On-demand** never runs on its own. It only runs from the Self-Service. - **Scope**: a Script that needs the user's profile fails silently when it runs as Machine (SYSTEM), and the other way round. - **Arguments** are split on spaces, so compound values need double quotes. #### Reading the execution history The **Execution history** button shows every run for the Device. Opening it from a specific Script's **⋮** menu instead scopes it to that Script alone, along with the arguments and scope it ran with. Each entry gives you: - **Status** — a green circle with a check when the run succeeded, an orange triangle when it failed. - **Script** — its name and file. - **Summary** — a snippet of the run's actual console output, taken straight from what the Script printed. - **Created** — how long ago the run happened. The summary is the part worth paying attention to: it's your Script's own output, so anything you print is what you'll read back here. Scripts that log a clear line per phase are far easier to diagnose later than Scripts that run silently. :::info **If a PowerShell Script writes to the error stream, the summary can show CLIXML instead of plain text** — a `#< CLIXML` marker followed by a serialized `` block. That isn't a display problem in Applivery: it's PowerShell's native format for serializing objects sent to the error stream. When you see it, read it as _this run produced error output_, and check the Script for whatever is writing to that stream. ::: #### Changing how a Script runs **Edit**, in the same **⋮** menu, changes how an already-assigned Script runs without unassigning and reassigning it: - **Execution method** — switch between Once, Loop and On-demand. - **Loop time** — when Loop is selected, how often it repeats. - **Arguments** — the same field described in [Script arguments](https://docs.applivery.com/en/device-management/windows/policies/scripts/#script-arguments), interpolated variables included. ### Do It Yourself! To help administrators accelerate common configurations and operational tasks, Applivery provides a [Public Script Repository](https://github.com/applivery/applivery-mdm-scripts) containing ready-to-use Windows scripts. This repository includes useful scripts for quick actions and standard configurations, allowing IT teams to deploy common solutions without having to build scripts from scratch. The goal of this initiative is **not only to provide reusable resources, but also to encourage collaboration**. The community can actively contribute by submitting scripts that address real-world use cases, helping expand and improve the shared library over time. By leveraging the **Public Script Repository**, organizations can reduce implementation time, standardize operational procedures, and benefit from collective expertise. --- ## Sleep Timeout Source: https://docs.applivery.com/en/device-management/windows/policies/sleep-timeout/ Description: Configure automatic sleep timeout settings on Windows Devices using Applivery Policies to enhance security and optimize power management. TL;DR: Configure Windows sleep timeout settings using Applivery to optimize power management and enhance security across managed devices. Key topics: Windows sleep timeout configuration, Applivery device management, Power management policies, Security enhancement, Password prompt on wake, Applivery, Windows, Power configuration group policy Controlling power management settings is essential for optimizing device performance, conserving energy, and enhancing security in enterprise environments. One key setting is the automatic sleep timeout, which determines how long a Windows device should remain idle before transitioning to sleep mode. Using Applivery, administrators can enforce this behavior by applying a Policy that specifies the number of seconds of inactivity allowed before sleep is triggered. This ensures consistency across all managed Devices and prevents users from overriding critical energy or security configurations. ### Configure Sleep Timeout Applivery allows you to manage power settings on Windows Devices using the **Power** configuration group policy. This includes settings like suspension, sleep behavior, and other energy-related controls. **Access Device Management and Policies** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), head to **Policies** 1. Choose the Policy where you want to configure the sleep timeout. **Add Power Configuration** Next, in the left-hand menu, select **\+ Add configuration** and search for **Advanced** 2. ![advanced](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/1a125879-d4e2-46b0-bf83-3f9f46742507.png) Click the **\+ Add section** button and search for the **Power** configuration. ![add section](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/691ecf5a-310e-4e9e-b5a7-590273703273.png) **Specify Unattended Sleep Timeout** Locate the **Specify the unattended sleep timeout (on battery and plugged in)** configuration and enter the desired timeout value in **seconds**. For example, to put the Device to sleep after 5 minutes of inactivity, set the value to **300 seconds**. ![specify sleep timeout](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/43c3cdb3-db88-470a-a14e-21a6e234e44a.png) ### Add Password Prompt on Wake To enhance security when a Device resumes from sleep, you can combine the previous setting with the **Require a password when a computer wakes (on battery and plugged in)** configuration. By enabling this Policy, users will be prompted to enter their password every time the Device wakes from sleep, whether it’s running on battery or plugged in. This ensures that unattended Devices remain secure after going to sleep. ![require password](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/c9a64184-3fdb-440d-8aba-697c204e97d0.png) --- ## Wallpaper Configuration Source: https://docs.applivery.com/en/device-management/windows/policies/wallpaper-configuration/ Description: Configure custom desktop and lock screen wallpapers on Windows Devices using Applivery Policies to reinforce corporate branding. TL;DR: Configure custom Windows wallpapers on company devices using Applivery to reinforce corporate branding by setting image URLs and enabling EDU policies. Key topics: Windows wallpaper configuration, Corporate branding on devices, Applivery device management, EDU policies for wallpaper enforcement, Windows, Applivery, HTTP, HTTPS, JPG, JPEG, PNG Customizing the desktop wallpaper is often seen as a way to reinforce corporate branding on Devices managed by the organization. Windows wallpaper settings allow businesses to ensure that every company-owned device displays the enterprise’s logo or trademark. Administrators can configure the wallpaper with the organization’s logo or any image they choose and apply it to an entire fleet of Devices. This customization also allows them to set wallpapers for all users on a Device and decide if they should be updated periodically. ### Configure a wallpaper **Personalization** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), head to **Policies** 1. Choose the Policy where you want to add this configuration. Next, in the left-hand menu, select **\+ Add configuration** 2, and search for **Personalization** 3. ![personalization](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/c3168606-0bd9-4c16-a9a4-40244e1eda33.png) Locate the **Desktop Image URL** and **Lock Screen Image URL** settings to configure wallpapers for the desktop and lock screen. Add an HTTP or HTTPS URL pointing to a `.jpg`, `.jpeg`, or `.png` image file. ![personalization settings](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/19d42b3c-0143-4454-9dd5-f15cbac32b2f.png) **Logon** Now, in the left-hand menu, select **\+ Add configuration** 4, and search for **Logon** 5. ![logon](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/3c72db9d-d343-454f-b4fa-5bf083d303de.png) Locate the **Always use custom logon background** setting and enable it to ensure the custom desktop and lock screen wallpapers you configure are applied consistently. This setting enforces the use of your specified images, overriding default or user-chosen backgrounds. ![always use custom logon background](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/f0d79eab-268e-487b-8def-fc635b515931.png) **Shared PC** Now, in the left-hand menu, select **\+ Add configuration** 6, and search for **Shared PC** 7. ![shared pc](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/c02a4dc6-177b-4b30-aaa8-a922f5e51398.png) To ensure custom desktop and lock screen wallpapers are properly enforced on Windows Devices, you must enable the **Set EDU Policies** setting. Windows applies wallpaper restrictions through EDU policy controls. If this setting is not enabled, the wallpaper configuration may not be applied consistently or could be overridden by users. ![set edu Policies](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/726130a5-eb70-4ffa-8286-59d2e292931d.png) :::info This configuration is only required for Windows Devices running **Pro licenses**. ::: --- ## Remote Support Source: https://docs.applivery.com/en/device-management/windows/remote-support/ Description: Remote Support for managed Windows Devices in Applivery — connect to a Device through TeamViewer without leaving the Dashboard. TL;DR: Enable TeamViewer Remote in a Windows Policy and connect to any Device in that Policy from its Action menu — no setup on the Device itself. Key topics: Windows Remote Support, TeamViewer integration, Remote sessions, Applivery, Windows, TeamViewer Remote Support lets you connect to a managed Windows Device straight from the Applivery Dashboard — to see what the person in front of it sees, walk them through something, or fix it yourself while nobody is there. On Windows, Remote Support runs on **TeamViewer**. You enable it once in a Policy, Applivery silently installs the TeamViewer Host app on every Device that Policy applies to, and from then on you start sessions from the Device's **Action** menu. There is nothing to set up on the Device itself, and nothing for the person using it to install. :::warning This is a premium feature that may not be available on your current plan. Check availability on the [Applivery pricing page](https://www.applivery.com/device-management-pricing/). ::: --- ## TeamViewer Remote Support Source: https://docs.applivery.com/en/device-management/windows/remote-support/teamviewer-remote-support/ Description: Enable TeamViewer Remote Support for Windows Devices in Applivery — silent install, session types, licensing, and troubleshooting. TL;DR: Enable TeamViewer Remote in a Policy, let Applivery install TeamViewer Host silently, then start sessions from the Device's Action menu. Key topics: Enabling TeamViewer Remote in a Policy, Silent installation of TeamViewer Host, Session types and licensing, Troubleshooting remote sessions, Applivery, TeamViewer, Windows, Windows Agent :::warning This is a premium feature that may not be available on your current plan. Check availability on the [Applivery pricing page](https://www.applivery.com/device-management-pricing/). ::: Enabling **TeamViewer Remote** in a Windows Policy makes Applivery silently install the TeamViewer Host app on every Device that Policy applies to, and register those Devices with TeamViewer. From then on, you start a remote session from the Device's **Action** menu — no setup on the Device itself, and nothing for the person using it to install or accept beforehand. :::info Also available on macOS. Check out [TeamViewer Remote Support for macOS](https://docs.applivery.com/en/device-management/apple/macos/remote-support/teamviewer-remote-support/). ::: ### Before you start TeamViewer Remote depends on the [Windows Agent](https://docs.applivery.com/en/device-management/windows/policies/agent/): the Agent is what installs and registers TeamViewer Host on the Device. Before enabling the Policy, make sure the Device's Segment has the **Windows Agent & Self Service** enabled, **with Scripts enabled** — the TeamViewer Host installation is delivered as a Script that the Agent runs. If either one is missing, the feature won't work even if the Policy itself says **Enabled**. The Policy's own warning links straight to the Agent settings for that Segment, so you can check it without leaving the page. ### Enabling TeamViewer Remote **Open the Policy** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), go to **Policies** 1 and open the Policy you want to enable Remote Support on. **Go to the Remote section** In the left-hand menu, select the **TeamViewer Remote** section and find the **TeamViewer Remote** configuration 2. **Set it to Enabled** Choose **Enabled** and save your changes. Every Device that Policy applies to will now get TeamViewer Host installed automatically. ![enable teamviewer](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/98604492-1eba-4788-abb7-62daec53ab16.png) #### The three configuration states TeamViewer Remote uses the **Not configured / Enabled / Disabled** pattern. This matters because a Device can have [more than one Policy applied to it](https://docs.applivery.com/en/device-management/general-settings/policy-composition/): what actually reaches the Device is the composed result of every Policy in its set, not the value of any single one. So each state is really what *this* Policy contributes to that composition:

State

What this Policy contributes

Enabled

Turns TeamViewer Remote on. TeamViewer Host is installed, the Device is registered with TeamViewer, and it takes a license from your pool

Disabled

Turns TeamViewer Remote off. Any Device that ends up without it active is deregistered from TeamViewer and its license is released back to the pool

Not configured

Contributes nothing. This Policy stays out of the decision, and the result comes from the other Policies in the set

#### Which Policy wins Policies are evaluated **sequentially**, in the order set by their Priority in the composition. The first Policy that actually sets a value decides the outcome — `Not configured` is skipped over, and no later Policy overrides a value that has already been set. Neither `Enabled` nor `Disabled` beats the other, in other words: **order is what decides**. Here it is on a Device with two Policies, where Policy 1 is evaluated first:

Policy 1

Policy 2

Composed result

Not configured

Enabled

Enabled — Policy 1 sets nothing, so Policy 2 decides

Disabled

Enabled

Not active — Policy 1 got there first, and Policy 2 doesn't override it

Enabled

Disabled

Enabled — the same rule the other way round: Policy 1 got there first

Use **Not configured** when a Policy has no business deciding about Remote Support — one that only deploys apps, for example. Use **Disabled** when you want a Policy to actively keep Remote Support off, and check that it is evaluated **before** any Policy that enables it, or it won't have any effect. #### Automatic installation Applivery deploys TeamViewer Host silently — the person using the Device doesn't have to do anything, and won't be asked to approve anything. The Device shows up as **Ready** once the app has fetched its configuration, which usually takes a few minutes. #### How licenses are counted Each Device with TeamViewer Remote active in its composed configuration uses one TeamViewer license from your plan, **whether or not anyone ever actually connects to it**. What counts is the number of Devices with the feature active, not the number of sessions you open. The moment a Device stops having TeamViewer Remote active through its Policies, it is **unregistered from TeamViewer and its license is released** automatically. How the composition changed doesn't matter: setting a Policy to **Disabled**, removing the Policy that was enabling it, or moving the Device elsewhere all have the same effect. ### Starting a remote session **Open the Device** Navigate to any of your Windows **Devices** and click the **Action** button 1. **TeamViewer Remote** 2 is the first option in the menu. ![action button](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/a24909c2-e4a6-402a-9dd8-9272ff9b32fe.png) **Pick how you want to connect** The **TeamViewer Remote Support** modal opens. Choose the **Control Type** and the **Open With** option for this session 3. ![controls](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/82cf4d74-3a88-4f31-858b-02887ff88071.png) **Start the session** Click **Start remote session**. If you chose **TeamViewer client**, the session is handed off to the TeamViewer desktop app on your machine, which connects to the Device. ![connecting](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/d4eed369-134b-4f38-9c7c-4acca27d3eb4.png) You don't fix a session type when enabling the Policy — every option is available every time, and you pick per session:

Setting

Options

Control Type

Unattended — connects without anyone accepting on the Device, for machines with nobody in front of them. Attended — someone at the Device has to accept the incoming session. View only — someone at the Device also has to accept, and you see the screen without any keyboard or mouse input being sent

Open With

New browser tab — runs on TeamViewer's web client, nothing to install on your machine. TeamViewer client — hands the session to the TeamViewer desktop app, with its full set of features

You can change your selection as many times as you like before clicking **Start remote session** — the value showing when you click is the one that gets used. #### What you can do during a session Once connected, TeamViewer gives you clipboard sharing, black screen, file transfer, chat, audio call, augmented reality, remote reboot, screen recording, and the ability to leave notes for the user. On the managed Device itself, TeamViewer Host shows up installed alongside the Applivery Agent — both put there by the automatic installation described above. ![teamviewer next to agent](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/c25a6bcc-3d9a-4899-a30d-5f51d1358ed7.png) ### Troubleshooting The **TeamViewer Remote Support** modal shows a status badge next to the Device, so you can tell at a glance whether a session can start. Hover the ⓘ icon next to the badge for a short explanation. #### Ready TeamViewer Host is installed and configured on the Device. You can start a session. #### Not enabled in policy The Device's assigned Policy doesn't have TeamViewer Remote set to **Enabled**. Go back to [Enabling TeamViewer Remote](#enabling-teamviewer-remote) and confirm you're editing the Policy that Device is actually assigned to. ![not enabled in policy](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/42d327ef-ab9f-4377-bf34-f99df4c40ae9.png) #### App not installed The Policy is enabled, but TeamViewer Host hasn't finished installing on that Device yet — or couldn't. Since the install is silent and can take a few minutes, wait and retry first. If it persists, check that the Device's Segment actually meets the [Agent and Scripts requirement](#before-you-start). This is by far the most common cause, because the install is delivered through a Script run by the Agent. ![app not installed](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/9961af89-b34b-49cb-a708-e04b0ce736f0.png) Starting a session against a Device in this state fails, whichever Control Type or Open With option you pick. #### The Device goes offline mid-session If the Device disconnects right after you click **Start remote session**, the remote session window closes on its own. Wait for the Device to come back online and start a new session. #### Nothing seems to happen when I click Start remote session Give it a moment before clicking again — double-clicking **Start remote session** won't open two sessions, so a second click doesn't speed anything up. --- ## Troubleshooting Source: https://docs.applivery.com/en/device-management/windows/troubleshooting/ Description: Troubleshoot common Windows Device Management issues in Applivery — resolve Enrollment problems, configuration issues, and security concerns. TL;DR: Applivery simplifies Android device management by providing a centralized dashboard to enroll, configure, and control devices at scale. Key topics: Android device management, Applivery, Security policies, Kiosk mode, OEM configuration, Android Diagnose and resolve common issues with Windows Device Management in Applivery — including enrollment failures, Policy sync errors, App deployment problems, and configuration conflicts. Each article explains the likely cause and the steps to resolve it, so you can get Devices back under management without escalating to support. --- ## android-enterprise Source: https://docs.applivery.com/en/glossary/android-enterprise/ Description: Android Enterprise offers multiple deployment modes including work profiles, fully managed devices, and dedicated devices to support diverse business needs. TL;DR: Android Enterprise explained for enterprise app distribution and device management use cases. Android Enterprise replaced Android for Work in 2017, introducing zero-touch enrollment and enhanced security features for enterprise deployments. --- ## aosp Source: https://docs.applivery.com/en/glossary/aosp/ Description: In enterprise mobility, AOSP management enables policy and app control on Google-less Android devices used in rugged, kiosk, and industrial scenarios. TL;DR: AOSP devices can be managed in enterprise fleets even when Google services are not available. AOSP is especially relevant for logistics, retail, and field operations where rugged devices prioritize control, durability, and offline-friendly management over consumer Google services. --- ## app-analytics Source: https://docs.applivery.com/en/glossary/app-analytics/ Description: App analytics provide actionable insights into user behavior for data-driven decisions on App quality, user experience, and distribution. TL;DR: App Analytics explained for enterprise app distribution and device management use cases. Integration with analytics platforms enables tracking of distribution metrics, adoption rates, and correlation between deployment methods and user engagement. --- ## app-catalog Source: https://docs.applivery.com/en/glossary/app-catalog/ Description: App catalogs streamline App discovery and deployment, giving Users access to vetted, compliant Apps while maintaining security and governance. TL;DR: App Catalog explained for enterprise app distribution and device management use cases. Enterprise app catalogs reduce IT workload by empowering users to install approved applications on-demand while maintaining centralized control and tracking. --- ## app-distribution Source: https://docs.applivery.com/en/glossary/app-distribution/ Description: App distribution encompasses the entire lifecycle from build upload to user installation, including testing, staging, and production deployments. TL;DR: App Distribution explained for enterprise app distribution and device management use cases. Effective app distribution strategies balance security, accessibility, and user experience, offering multiple channels to reach different audiences and use cases. --- ## app-wrapping Source: https://docs.applivery.com/en/glossary/app-wrapping/ Description: App wrapping enables organizations to add security controls, data loss prevention, and compliance features to third-party or legacy applications. TL;DR: App Wrapping explained for enterprise app distribution and device management use cases. App wrapping is particularly useful for extending MDM capabilities to apps that don't natively support enterprise management APIs. --- ## automation-rules Source: https://docs.applivery.com/en/glossary/automation-rules/ Description: Automation rules reduce manual operations by linking device states and audience conditions to predefined response actions. TL;DR: Automation rules trigger management actions automatically based on conditions. Automation rules are key to maintaining consistency across large fleets where manual execution of repetitive management tasks is not sustainable. --- ## beta-testing Source: https://docs.applivery.com/en/glossary/beta-testing/ Description: Beta testing programs enable controlled distribution to specific user groups, providing valuable insights that improve app quality and user experience. TL;DR: Beta Testing explained for enterprise app distribution and device management use cases. Successful beta testing combines targeted user selection, clear feedback mechanisms, and iterative release cycles to refine applications before production launch. --- ## byod Source: https://docs.applivery.com/en/glossary/byod/ Description: BYOD programs balance user flexibility with corporate security through containerization, selective wipe capabilities, and policy enforcement. TL;DR: BYOD (Bring Your Own Device) explained for enterprise app distribution and device management use cases. Effective BYOD implementations use work profiles or containers to isolate corporate data while respecting employee privacy on personal devices. --- ## certificate-management Source: https://docs.applivery.com/en/glossary/certificate-management/ Description: Proper certificate management ensures apps can be distributed and trusted, devices can authenticate securely, and communications remain encrypted and verified. TL;DR: Certificate Management explained for enterprise app distribution and device management use cases. Enterprise certificate management includes provisioning profiles for iOS, signing keys for Android, and SSL/TLS certificates for secure communications. --- ## ci-cd Source: https://docs.applivery.com/en/glossary/ci-cd/ Description: CI/CD pipelines automate building, testing, and deploying applications, ensuring rapid iteration cycles and consistent quality across releases. TL;DR: CI/CD (Continuous Integration/Continuous Deployment) explained for enterprise app distribution and device management use cases. Modern CI/CD workflows integrate with app distribution platforms to automatically deploy builds to beta testers and production users upon passing quality checks. --- ## deep-linking Source: https://docs.applivery.com/en/glossary/deep-linking/ Description: Deep links enhance user experience by enabling direct navigation to app content from external sources like emails, websites, or push notifications. TL;DR: Deep Linking explained for enterprise app distribution and device management use cases. Deep linking is essential for install attribution, re-engagement campaigns, and creating seamless user journeys across web and mobile platforms. --- ## device-audiences Source: https://docs.applivery.com/en/glossary/device-audiences/ Description: Device audiences let administrators automate management at scale by applying configurations and workflows to matching devices. TL;DR: Device audiences automate policy targeting by grouping devices through rules. Device audiences reduce manual administration and improve consistency by ensuring policies and actions are automatically aligned with current device state and attributes. --- ## device-compliance Source: https://docs.applivery.com/en/glossary/device-compliance/ Description: Compliance monitoring ensures devices maintain required security postures, automatically restricting access to corporate resources when violations are detected. TL;DR: Device Compliance explained for enterprise app distribution and device management use cases. Non-compliant devices can be automatically quarantined or wiped remotely, protecting organizational data from compromised endpoints. --- ## Understanding Device Enrollment: Secure Connection Source: https://docs.applivery.com/en/glossary/device-enrollment/ Description: Device Enrollment establishes a secure connection between a Device and management infrastructure, enabling remote configuration and Policies. TL;DR: Device enrollment creates a secure connection between a device and management infrastructure for remote configuration and policy enforcement. Key topics: Device Enrollment, Secure Connection, Remote Configuration, Policy Enforcement, MDM Device enrollment establishes a secure connection between a device and the management infrastructure, enabling remote configuration and policy enforcement. --- ## enrollment-token Source: https://docs.applivery.com/en/glossary/enrollment-token/ Description: Enrollment tokens simplify provisioning workflows while controlling who can enroll devices and under what conditions. TL;DR: Enrollment tokens secure and streamline device onboarding workflows. Enrollment tokens help organizations standardize onboarding while reducing the risk of unauthorized enrollment events. --- ## filevault Source: https://docs.applivery.com/en/glossary/filevault/ Description: FileVault helps organizations enforce endpoint data protection and compliance by preventing unauthorized offline access to device data. TL;DR: FileVault encrypts macOS storage to protect sensitive enterprise data. FileVault is a baseline control in many security frameworks because it significantly lowers exposure risk from lost or stolen devices. --- ## identity-provider Source: https://docs.applivery.com/en/glossary/identity-provider/ Description: Identity providers power SSO and federation by centralizing authentication, access policies, and user lifecycle controls. TL;DR: Identity providers centralize sign-in and access policy enforcement across applications. Identity providers improve security posture by consolidating sign-in, reducing local credential sprawl, and enabling consistent policy enforcement across integrated platforms. --- ## kiosk-mode Source: https://docs.applivery.com/en/glossary/kiosk-mode/ Description: Kiosk mode is ideal for dedicated-use devices like point-of-sale terminals, digital signage, inventory scanners, or customer-facing tablets. TL;DR: Kiosk Mode explained for enterprise app distribution and device management use cases. Kiosk configurations can range from single-app mode to multi-app mode with controlled app switching, depending on business requirements. --- ## ldap Source: https://docs.applivery.com/en/glossary/ldap/ Description: LDAP integration enables organizations to reuse directory credentials and groups for sign-in, access control, and user synchronization. TL;DR: LDAP centralizes identity access and is commonly integrated into enterprise authentication flows. LDAP is often used alongside SSO and role mapping to enforce consistent user access and group-based permissions across enterprise apps. --- ## mam Source: https://docs.applivery.com/en/glossary/mam/ Description: MAM enables granular control over individual Apps — data access, sharing permissions, and authentication — without full Device management. TL;DR: Mobile Application Management (MAM) explained for enterprise app distribution and device management use cases. MAM is particularly valuable for BYOD scenarios where users want corporate apps on personal devices without surrendering full device control to IT. --- ## managed-google-play Source: https://docs.applivery.com/en/glossary/managed-google-play/ Description: Managed Google Play integrates with Android Enterprise and EMM/UEM platforms to provide secure, policy-driven app deployment. TL;DR: Managed Google Play is the controlled enterprise path for Android app distribution. Managed Google Play is a core component of Android enterprise mobility because it combines app availability, version control, and policy enforcement in a single managed channel. --- ## mdm Source: https://docs.applivery.com/en/glossary/mdm/ Description: MDM provides centralized control over Device configurations, Policies, and Apps — ensuring compliance and security across an organization's fleet. TL;DR: Mobile Device Management (MDM) explained for enterprise app distribution and device management use cases. Mobile Device Management (MDM) is a proven methodology and toolset used to provide a workforce with mobile productivity tools and applications while keeping corporate data secure. --- ## oemconfig Source: https://docs.applivery.com/en/glossary/oemconfig/ Description: OEMConfig standardizes advanced vendor controls, so admins can configure manufacturer features without custom EMM integrations. TL;DR: OEMConfig exposes advanced device-maker settings in a scalable way for Android enterprise management. OEMConfig is critical for rugged and specialized Android deployments where enterprise teams need granular hardware controls beyond baseline Android management policies. --- ## ota Source: https://docs.applivery.com/en/glossary/ota/ Description: OTA updates enable seamless deployment of app versions and system updates, improving adoption rates and reducing friction in the update process. TL;DR: Over-the-Air (OTA) explained for enterprise app distribution and device management use cases. OTA technology is fundamental to modern mobile device management, enabling rapid deployment of critical updates and security patches across distributed device fleets. --- ## otp Source: https://docs.applivery.com/en/glossary/otp/ Description: OTP-based access provides controlled, temporary authentication without requiring permanent user accounts, often used for external collaborators or secure short-term access flows. TL;DR: OTP enables temporary, single-use authentication for secure and controlled access. OTP authentication is useful when organizations need to grant secure access to users who do not have full accounts, while still maintaining expiration controls and auditability. --- ## pppc Source: https://docs.applivery.com/en/glossary/pppc/ Description: PPPC profiles allow administrators to pre-approve or deny privacy permissions to reduce prompts and enforce security policy at scale. TL;DR: PPPC profiles control sensitive app permissions across managed macOS devices. PPPC is widely used in enterprise macOS deployments to keep security controls strict while preventing excessive user permission prompts. --- ## provisioning Source: https://docs.applivery.com/en/glossary/provisioning/ Description: Provisioning automates the setup of devices and applications, ensuring consistent configuration across the organization and reducing manual IT workload. TL;DR: Provisioning explained for enterprise app distribution and device management use cases. Modern provisioning solutions enable zero-touch deployment, where devices can be automatically configured upon first boot without manual IT intervention. --- ## push-notifications Source: https://docs.applivery.com/en/glossary/push-notifications/ Description: Push notifications enable real-time communication with Users and Devices — user-facing messages and silent background Commands for management. TL;DR: Push Notifications explained for enterprise app distribution and device management use cases. MDM systems leverage push notifications to trigger immediate policy updates, initiate remote wipe commands, or notify users of compliance violations. --- ## remote-wipe Source: https://docs.applivery.com/en/glossary/remote-wipe/ Description: Remote wipe is a security feature that prevents data breaches by removing corporate information from compromised or decommissioned Devices. TL;DR: Remote Wipe explained for enterprise app distribution and device management use cases. Modern MDM solutions offer selective wipe to remove only corporate data and apps while preserving personal information on BYOD devices. --- ## saml Source: https://docs.applivery.com/en/glossary/saml/ Description: SAML enables enterprise Single Sign-On by delegating authentication to a trusted identity system and passing signed identity assertions to apps. TL;DR: SAML enables federated sign-in by passing signed identity assertions between identity and application platforms. SAML is commonly used in enterprise identity architectures to centralize authentication and reduce password sprawl while preserving secure, policy-based access control. --- ## scim Source: https://docs.applivery.com/en/glossary/scim/ Description: SCIM keeps account data synchronized across systems by creating, updating, and deactivating users automatically, reducing manual identity administration. TL;DR: SCIM automates user and group provisioning across identity and application platforms. SCIM is commonly paired with SSO to deliver both authentication and automated account lifecycle management, ensuring users and groups stay aligned across identity providers and downstream apps. --- ## segments Source: https://docs.applivery.com/en/glossary/segments/ Description: In device management, segments help delegate administration and isolate devices, policies, and permissions by organizational boundaries. TL;DR: Segments split management scope to improve delegation, control, and security. Segments are especially useful in multi-team organizations where security and operational ownership must be separated without duplicating infrastructure. --- ## service-accounts Source: https://docs.applivery.com/en/glossary/service-accounts/ Description: Service accounts support CI/CD and integration workflows by providing scoped, revocable credentials separate from personal user accounts. TL;DR: Service accounts provide secure machine-to-machine authentication for automated workflows. Using service accounts instead of user credentials improves security, traceability, and operational continuity for integration and deployment workflows. --- ## sideloading Source: https://docs.applivery.com/en/glossary/sideloading/ Description: Sideloading enables enterprise app deployment, beta testing, and development workflows without requiring public app store approval. TL;DR: Sideloading explained for enterprise app distribution and device management use cases. While sideloading is essential for enterprise mobility, it requires proper certificate management and security measures to prevent unauthorized app installations. --- ## smart-attributes Source: https://docs.applivery.com/en/glossary/smart-attributes/ Description: Smart attributes enrich raw device inventory data with actionable context, enabling precise targeting and policy orchestration. TL;DR: Smart attributes improve targeting precision by adding dynamic context to device data. Smart attributes are foundational for advanced automation because they allow policies and workflows to react to real device context instead of static grouping. --- ## sso Source: https://docs.applivery.com/en/glossary/sso/ Description: SSO centralizes authentication and reduces password fatigue while improving security, access governance, and user onboarding across enterprise systems. TL;DR: SSO lets users sign in once and securely access multiple enterprise apps. Single Sign-On (SSO) improves user experience and strengthens security by routing authentication through a central identity provider, enabling consistent policy enforcement and simpler access management. --- ## testflight Source: https://docs.applivery.com/en/glossary/testflight/ Description: TestFlight provides a streamlined way to gather feedback, track crashes, and validate app functionality before submitting to the App Store. TL;DR: TestFlight explained for enterprise app distribution and device management use cases. TestFlight integrates with App Store Connect and supports up to 10,000 external testers per app, making it essential for iOS app development workflows. --- ## two-factor-authentication Source: https://docs.applivery.com/en/glossary/two-factor-authentication/ Description: 2FA reduces account compromise risk by adding a second proof beyond passwords, such as OTP codes, authenticator apps, or hardware keys. TL;DR: 2FA adds a second verification layer to reduce unauthorized account access. Two-factor authentication is an essential control in enterprise environments to mitigate credential theft and reduce the impact of password reuse. --- ## uem Source: https://docs.applivery.com/en/glossary/uem/ Description: UEM centralizes policy, security, app delivery, and lifecycle operations across diverse operating systems and device types. TL;DR: UEM consolidates endpoint administration across mobile, desktop, and specialized devices. UEM expands beyond traditional mobile management by combining endpoint security, policy governance, and operational tooling under one enterprise management strategy. --- ## user-audiences Source: https://docs.applivery.com/en/glossary/user-audiences/ Description: User audiences support automated distribution and access control by assigning publications and permissions to users who match defined criteria. TL;DR: User audiences automate user-level targeting for app access and distribution. User audiences are valuable in large organizations where user attributes change frequently and manual group curation cannot keep pace. --- ## webhooks Source: https://docs.applivery.com/en/glossary/webhooks/ Description: Webhooks enable automation and integrations by pushing event payloads to external services without polling. TL;DR: Webhooks send real-time event payloads to external endpoints for automated actions. Webhooks are commonly used to connect release events, device lifecycle updates, and security notifications to ticketing, chat, and monitoring systems. --- ## zero-touch-enrollment Source: https://docs.applivery.com/en/glossary/zero-touch-enrollment/ Description: Zero-Touch Enrollment eliminates manual provisioning, enabling seamless Device deployment at scale with security and compliance from first boot. TL;DR: Zero-Touch Enrollment explained for enterprise app distribution and device management use cases. Apple's Automated Device Enrollment (formerly DEP) and Android's zero-touch enrollment enable true out-of-box enterprise deployment for iOS and Android devices. --- ## Intelligence Source: https://docs.applivery.com/en/intelligence/ Description: Applivery Intelligence — ask questions about your fleet in plain language, get live answers from your Workspace, build dashboards, automate what happens next and let agents watch your Devices for you. TL;DR: Ask about your fleet in plain language and get answers from live Applivery data. The Workspace Owner buys and assigns seats; you open it from the ✨ button in the dashboard top bar. Key topics: What Applivery Intelligence is, The four surfaces, Seats and access, Permissions and approvals, Applivery, Applivery Intelligence, Applivery MCP, Endpoint Manager ## Intelligence Finding something in a fleet normally means opening a list, filtering it, and reading it. **Applivery Intelligence** replaces that with a question: > Which Macs have not checked in for 30 days? > Show me every Device that is missing disk encryption, grouped by Policy. > Lock the laptop David lost yesterday. It answers from **live** Applivery data — the same API the dashboard uses, never a cached copy — renders the result as an interactive table, chart, map or Device card, and asks you to confirm before it changes anything. :::info **Generally Available — and actively evolving.** Applivery Intelligence is generally available and supported. It is also an AI product under continuous research and improvement: answers are generated, capabilities change between releases, and mistakes are possible. Read what it produces before acting on it. ::: ### The four surfaces | Surface | What it is | Plan required | | --- | --- | --- | | **Chat** | Ask questions, get interactive answers, run actions | Free, Pro, Max, Ultra | | **Insights** | Dashboards of live widgets, refreshed on a schedule, with alerts | Max, Ultra | | **Workflows** | Visual automations triggered by an alert, a schedule, a webhook or a click | Max, Ultra | | **Cowork** | Agents that examine the fleet in the background and bring you what they find | Max, Ultra | ### Getting in Applivery Intelligence is licensed **per person, by seat**. The Applivery organization Owner buys seats and assigns them; anyone with a seat opens Intelligence from the **✨ button** in the Applivery dashboard top bar. There is nothing to install, no API key to generate and no second login — it reuses your active Applivery session and starts on the Workspace you are already looking at. :::warning Intelligence acts **as you**. Your Applivery role is the ceiling: if you cannot wipe a Device in the Applivery dashboard, you cannot wipe it by asking Intelligence either. ::: ### Bringing your own assistant If you would rather work from Claude, ChatGPT or your own tooling, [Applivery MCP](https://docs.applivery.com/en/intelligence/applivery-mcp/) exposes the same fleet through the Model Context Protocol. Same capabilities, same permissions, different assistant. --- ## Applivery MCP Source: https://docs.applivery.com/en/intelligence/applivery-mcp/ Description: The Applivery MCP server lets any MCP-compatible AI assistant work with your Applivery Workspace — how to connect it, what it can do, and what guards it. The **Model Context Protocol (MCP)** is an open standard for giving an AI assistant a set of well-defined, permission-aware actions against a real system. The **Applivery MCP server** is Applivery's implementation of it — one endpoint that brings your fleet into Claude, ChatGPT or your own tooling. :::info **Generally Available — and actively evolving.** The Applivery MCP server is generally available and supported. It is also an AI-facing product under continuous research and improvement: the tool catalogue, the directory listings and the client integrations change between releases. Assistants can misread results, so review anything consequential before approving it. ::: ### How it relates to Applivery Intelligence | | **Applivery Intelligence** | **Applivery MCP** | | --- | --- | --- | | What it is | A complete product: chat, dashboards, workflows, proactive monitoring | A connector — one endpoint an assistant talks to | | Where you use it | Inside the Applivery dashboard | Inside Claude, ChatGPT, or your own tooling | | Who chooses the model | Applivery | You | | Licensed by | Seats — see [Plans, seats and billing](https://docs.applivery.com/en/intelligence/plans-and-billing/) | Your Applivery plan, plus whatever your AI provider charges you | They are not alternatives so much as two doors onto the same fleet. Applivery Intelligence itself consumes the same MCP catalogue internally — what you get in Claude is the same set of capabilities, driven by a different assistant. :::tip Use **Intelligence** when you want dashboards, automation and monitoring that keep working when you close the tab. Use **MCP** when you want your fleet available inside a conversation you are already having, alongside your other tools. ::: ### What you can do with it | Area | Examples | | --- | --- | | **Device inventory** | Search the fleet, inspect a Device, review installed apps, storage, OS version, encryption state | | **Device actions** | Lock, restart, rename, wipe, enable Lost Mode, clear a passcode, disenroll | | **Policies** | List and inspect Policies, see what a Device has applied, review sync status, create and update | | **Segments and Audiences** | Explore the Segment tree, review membership rules, preview who a change would affect | | **Users and enrollment** | Look up people, review Enrollment Templates and tokens | | **App distribution** | Review published Apps, builds, stores, and who downloaded what | | **Inventory and assets** | Track non-managed assets and link them to enrolled Devices | | **Scripts** | Review scripts, their assignments and their execution logs | | **Audit** | Query the audit trail — who did what, when, on which entity | The catalogue currently exposes around 146 individual actions. Which of them your assistant sees depends on your platform mix, your Applivery plan, your permissions, and which of them Applivery publishes on the channel you are using. ### Requirements - **An Applivery account** with access to at least one Workspace. The connector never creates accounts or Workspaces. - **Applivery Endpoint Manager (UEM/MDM)** or **App Distribution**, depending on which actions you want. A Workspace with only App Distribution returns no device-management results. - **Permissions in Applivery.** The connector acts as you. - **An AI assistant on a plan that supports connectors.** Availability is controlled by Anthropic, OpenAI or your own tooling — not by Applivery. There is nothing to install, no agent, no network change and no API key to generate. You sign in with your Applivery account through a standard OAuth consent screen. ### How it works ```text You → Claude / ChatGPT → mcp.applivery.ai → api.applivery.io → your Workspace ``` 1. You ask the assistant something about your fleet. 2. The assistant picks one of the connector's actions and calls the Applivery MCP server. 3. The server validates your access token, resolves which Applivery Workspace it belongs to, and calls the Applivery API with your credentials. 4. The result comes back into the conversation. Every hop is HTTPS. The assistant never holds a long-lived copy of your Applivery credentials — authorisation is an OAuth session you can revoke at any time. ### Connect to Claude **Connector URL:** `https://mcp.applivery.ai/mcp/anthropic` **From the connector directory** 1. In Claude, open **Settings > Connectors**. 2. Find **Applivery** and select **Connect**. 3. Sign in with your Applivery account in the window that opens. 4. Review the consent screen — it names the Workspace the connector will act on — and select **Authorize**. 5. You are returned to Claude with the connector enabled. **As a custom connector** Use this if your organization prefers to add it manually. 1. Open **Settings > Connectors > Add custom connector**. 2. Enter **Name** `Applivery` and **Remote MCP server URL** `https://mcp.applivery.ai/mcp/anthropic`. 3. Select **Add**, then **Connect**, and complete the Applivery sign-in. :::tip In Team and Enterprise organizations an owner or admin can add the connector once for everybody. Each member still authorises individually and still acts with their own Applivery permissions. ::: ### Connect to ChatGPT **Connector URL:** `https://mcp.applivery.ai/mcp/openai` **From the directory** 1. In ChatGPT, open **Settings > Apps & Connectors**. 2. Find **Applivery** and select **Connect**. 3. Sign in with your Applivery account, review the consent screen, and **Authorize**. **As a custom connector** 1. Open **Settings > Apps & Connectors > Advanced > Developer mode** and enable it. Availability depends on your ChatGPT plan. 2. Select **Create** and enter **Name** `Applivery`, **MCP server URL** `https://mcp.applivery.ai/mcp/openai`, **Authentication** OAuth. 3. Save, select **Connect**, and complete the Applivery sign-in. Depending on the surface you may need to bring the app into the conversation explicitly — type `@` and pick **Applivery**, or name it in the request: > Using Applivery, list the Android Devices that have not checked in for 30 days. ### Other MCP clients Any client that speaks MCP over Streamable HTTP with OAuth 2.1 can connect. Point it at `https://mcp.applivery.ai/mcp/anthropic` (the Anthropic-shaped catalogue) or ask your Applivery contact which channel suits your client. Authorisation is OAuth 2.1 with PKCE; there is no static API key to paste. ### Choosing a Workspace If your Applivery account reaches more than one Workspace, the connector starts on your default one. To move between them inside a conversation, just ask: > Which Applivery workspaces can I access? > Switch to the Acme Corp workspace. The switch applies to the rest of that conversation, and does not change your default Workspace in the Applivery dashboard. Data from one Workspace is never mixed into a request against another. ### Verifying it works Ask something read-only first: > How many Devices are enrolled in my Applivery workspace? The assistant should call the connector and answer with a real count. If it answers from general knowledge, or says it has no access, confirm Applivery shows as connected in the assistant's settings and start a fresh conversation. ### Permissions and safety **It acts as you, never above you.** Authorisation is your own Applivery account. Your Applivery role is the ceiling — there is no shared service account, no elevated mode, no escalation path. **Every action is purpose-built.** There is no generic "call the API" action. Each capability is a separate action with a fixed endpoint, a validated input schema and a documented behaviour. Reads and writes are always separate actions — never one action with a `method` parameter. **Read and write are labelled for the assistant.** Every action publishes machine-readable hints: | Hint | Meaning | Effect in Claude or ChatGPT | | --- | --- | --- | | Read-only | Only reads data | May run without asking each time | | Destructive | Changes or deletes existing data | **Always** asks for confirmation | | Closed-world | Operates only inside your Applivery tenant | Signals a predictable domain | Applivery deliberately over-labels rather than under-labels: anything that modifies state is marked destructive, including updates, remote Device commands (lock, restart, shutdown, clear passcode, Lost Mode), Segment moves and notifications that reach end users. The only action that reaches outside your tenant is the public app-store search. **Confirmation before anything irreversible.** For a destructive action the assistant shows what it is about to do, on which Device, and waits. :::warning For wipe, disenroll and delete: ask for the list first, read it yourself, and only then ask to act on it. Approving a batch you have not read is the one reliable way to get a bad outcome from a good tool. ::: **Rate limiting.** Limits apply per client and per authenticated identity, so a runaway loop in an assistant cannot hammer your Workspace. When a limit is hit the assistant receives a clear error and stops rather than retrying blindly. **Transport.** HTTPS only, with no plaintext fallback. OAuth 2.1 with PKCE. Tokens issued to the assistant are opaque and short-lived; the upstream Applivery tokens behind them are encrypted at rest. ### What Applivery controls Applivery decides which capabilities are published at all, **per channel** — Claude, ChatGPT, and direct or internal integrations: - The set of actions available in Claude can differ from the set available in ChatGPT, and both can be narrower than what internal integrations use. - An action published to no channel is served to nobody. - A read-only rollout is a supported configuration: publish only the read actions on the relevant channel and no assistant on it can change anything. An action that is not published on a channel does not exist for clients on that channel — it is filtered out before the assistant is ever told about it, not merely hidden. Applivery operates a dedicated console for the connector, covering published tools, rate limits, usage statistics, request logs and per-call traces. It is not a customer-facing surface; if you need a read-only rollout, a narrower catalogue or a usage report, ask your Applivery contact. ### Privacy and data handling **What is sent to Applivery:** the action to run and its parameters — a Device identifier, a search term, a date range — plus your access token. Applivery does **not** receive your conversation, your prompt history, your files, or the assistant's memory. **What comes back:** the result of that action, trimmed to what the request needs. That result becomes part of the conversation and is then subject to your AI provider's data handling, not Applivery's. **What Applivery records:** operational logs for support, debugging, abuse prevention and service quality — which action ran, with which parameters, a summary of the response, whether it failed, how long it took, which Workspace and user it was for, which assistant it came from, and the IP address and user agent. :::warning Action parameters and response summaries can include Device names, user names and email addresses from your fleet, and these are retained in Applivery's operational logs. If your organization has rules about which fleet data may leave your systems, apply them at the point of deciding **who** you grant the connector to. ::: See the [Applivery privacy policy](https://www.applivery.com/legal/privacy-policy/) for the authoritative statement. ### Disconnecting - **Claude:** **Settings > Connectors > Applivery > Disconnect**. - **ChatGPT:** **Settings > Apps & Connectors > Applivery > Disconnect**. - **From Applivery:** revoke the authorisation in your Applivery account settings. All three paths invalidate the same OAuth session immediately. Reconnecting requires signing in again. ### Troubleshooting | Symptom | What it means | | --- | --- | | The assistant answers without calling Applivery | The connector is not enabled for that conversation. Confirm it is connected and start a new chat; on ChatGPT, name the app explicitly. | | `403 — insufficient permissions` | Your Applivery role does not allow that action. It is not a connector fault. | | An action you expected is missing | It is not published on that channel. Ask your Applivery contact. | | Results from the wrong Workspace | Ask the assistant to switch Workspace explicitly. | | Repeated rate-limit errors | Too many calls in a short window — usually an assistant looping. Start a fresh conversation. | --- ## What Applivery Intelligence Can Do Source: https://docs.applivery.com/en/intelligence/capabilities/ Description: Chat, Insights, Workflows and Cowork — the four surfaces of Applivery Intelligence, the specialist agents behind them, and how each one works. Applivery Intelligence is made of four surfaces. **Chat** answers questions and takes actions. **Insights** turns answers into live dashboards. **Workflows** automates what happens next. **Cowork** watches the fleet without being asked.

Surface

Plan required

Chat

Free, Pro, Max, Ultra

Insights

Max, Ultra

Workflows

Max, Ultra

Cowork

Max, Ultra

:::info **Generally Available — and actively evolving.** Applivery Intelligence is generally available and supported. It is also an AI product under continuous research and improvement: answers are generated, capabilities change between releases, and mistakes are possible. Review what it produces before acting on it — particularly anything that changes a Device. ::: ### Chat Chat is the front door. You ask in plain language; it answers from live Applivery data. #### How an answer is produced A single message is not handled by a single model. Intelligence runs a **coordinator** that reads what you are asking for and routes it to one or more **Agentic Specialists** — each with its own brief, its own instructions and its own restricted set of Applivery tools. The coordinator itself has no access to your Devices at all: every answer that carries data came from a specialist that had to go and fetch it.

Specialist

Owns

Compliance Agent

Posture, audits, who is compliant or drifting, violations

Security Agent

Device actions — move, rename, lock, wipe, install — and risk triage

Impact Agent

Read-only "what if": before/after, simulated Policy composition

Policy Agent

Policy design, comparison, priority tuning, Segment permissions

Insights Agent

Fleet analytics — trends, distributions, charted reports

Knowledge Agent

Product and REST API documentation, answered with cited links

Policy Architect

Designs and creates ready-to-apply Policies for Apple, Android, AOSP and Windows

Scripts Engineer

Authors, creates and assigns macOS Bash and Windows PowerShell scripts

Vulnerability Agent

Known CVEs for an OS or app version, with severity, KEV and exploit likelihood

When a request spans domains — "which Devices are non-compliant, and what would fixing the Policy break?" — the coordinator delegates to several specialists in parallel and then writes one answer. The badge on each reply tells you which specialist produced it. #### Artifacts — answers you can work with When an answer contains structure, it is rendered as an **artifact** in the side panel rather than as a wall of text: a sortable Device table, a Policy comparison, a map, a chart, a CVE breakdown. Artifacts are interactive. Depending on the type you can: - **Sort and filter** columns, and click a row to drill into that Device or Policy. - **Download the data as CSV**, from the table's own download button. - **Add it to a dashboard** with **Add to dashboard**, which turns the answer into a live widget that refreshes on its own. - **Copy the raw JSON** behind it. Types include Device lists and Device detail cards, Device maps, Policy lists, Policy detail, Policy composition and Policy comparison, app-usage and data-usage reports, multi-chart data reports, generic data tables, cited documentation, REST endpoint references, and the three vulnerability views. ![List of devices](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/041b09c1-5020-4153-a1cf-c067ac627344.png) #### Referencing objects with `@` Type `@` in the message box to search and insert a specific object instead of describing it. You can mention **Devices, Policies, MDM Users, Segments, Device Audiences, Automation Rules** and **Enrollment Templates**. The reference carries the object's identity, so the assistant does not have to guess which "MacBook Pro" you meant. #### Permissions and approvals This is the part worth reading twice. **Intelligence acts as you.** It calls the Applivery API with your own Workspace credentials, under your identity. Your Applivery role is the ceiling — there is no service account, no elevated mode and no way for the assistant to escalate. Actions appear in the Applivery audit log under your name. **Reads and writes are separated by design.** Anything that only reads (`get`, `list`, `search`, `preview`) is classified as a read; everything else is classified as a write, including capabilities that did not exist when the rule was written. The read list is an allowlist rather than a list of things to watch out for, so a new capability with an unfamiliar verb is treated as a write until somebody decides otherwise. This classification is what the platform's own safety rules run on — it is not the same thing as your approval settings below, which you control per capability. **Some actions always ask, and cannot be set not to.** Wiping a Device, locking a Device, and anything that deletes are permanently gated behind a confirmation, regardless of your saved preferences. When one is proposed you see exactly which action, on which Device, with which parameters — and nothing runs until you approve. **You tune the rest yourself.** Open the gear icon in the top bar and go to **Integrations > Applivery MDM > Tool Permissions**. Every capability is listed with what it does, and can be set to:

Setting

Effect

Always allow

Runs without asking you

Needs approval

Asks you every time

Blocked

Never runs — the assistant is told the capability is unavailable

Two things follow from where this setting lives: - **It is yours, not the Workspace's.** It applies to your own conversations only. Relaxing a capability for yourself does not stop a colleague being asked about it, and blocking one does not take it away from them. There is no Workspace-wide tool policy — the shared backstop is your Applivery role. - **Everything starts on "Needs approval"**, reads included. A brand-new seat is asked about every single call until you go through the list and allow the ones you are comfortable with. That is deliberately noisy on day one; ten minutes on this page is the fix. Permanently-gated actions show a **Locked** badge and cannot be moved off _Needs approval_, no matter what you save. The **History** tab next to it lists the calls made from your own chat sessions — the capability, its input, the response, latency and time — over the last 7 days, 30 days or 3 months. ![approval required](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/d6daac18-bbf7-45e9-b003-3c71e45cf0bc.png) :::warning For anything irreversible — wipe, disenroll, delete — ask for the list first, read it yourself, and only then ask to act on it. Approving a batch you have not read is the one reliable way to get a bad outcome from a good tool. ::: #### Guardrails Chat is scoped to device management. A few protections run on every message: - **Prompt-injection filtering** — attempts to override the assistant's instructions or extract its configuration are refused. - **Scope filtering** — the assistant declines requests unrelated to your fleet. - **Message length and rate limits**, set per Workspace by Applivery. - **A hard block on answering without data.** If the Workspace exposes no Applivery tools — a misconfigured Workspace, a role with no permissions — chat refuses to answer rather than inventing a plausible fleet. - **Anti-fabrication rules.** The assistant may not claim it produced a file, chart or table it did not actually render, and may not claim an action succeeded unless the tool confirmed it in that same turn. #### Managing conversations Your conversations are **yours**. They are saved against your own account, listed in the left panel, titled automatically from the first question, and can be renamed, archived or deleted there. Colleagues with a seat in the same Workspace do not see them — what is shared at Workspace level is dashboards, workflows and Cowork findings, not chat. Switching Workspace switches the list: a conversation belongs to the Workspace it was started in as well as to you. Each answer is followed by suggested next questions, grounded in what Applivery can actually do rather than generic prompts. ### Insights **Insights** turns answers into a monitored view. Available on Max and Ultra. #### Dashboards and widgets A dashboard is a grid of widgets you arrange by dragging and resizing. Widgets are created in two ways: - **By promoting a chat artifact** — ask a question, get a table or chart, click **Add to dashboard**. The widget keeps the query behind the artifact and re-runs it on its own from then on. - **By adding one directly** to an existing dashboard. ![insights dashboard](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/3cf793d7-224d-4423-ad4c-f9a7215c4eed.png) Widget formats are **KPI** (a single number with a trend), **line**, **bar**, **donut**, **table**, **map** and **card**. Which formats are available depends on what the underlying data is — a Device list can be a table or a KPI; a location query can be a map. :::tip The fastest way to build a dashboard is to have the conversation first. Ask the four or five questions you would ask on a Monday morning, and pin each answer. ::: #### Refreshing Each dashboard is either **manual** or **scheduled**. Scheduled dashboards refresh on a cron expression with full time-zone support, from every 5 minutes to daily. The header shows the last refresh, the next one, and warns you when a refresh is overdue rather than quietly showing stale numbers. **Refresh all** re-runs every widget on demand. A single widget can also be refreshed on its own, and its underlying query can be edited from the widget menu — **Edit query** renders a form from the real parameter schema, so you can change a filter without going back to chat. ![refresh schedule](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/d4b9e8da-7487-4bab-9761-a8f563c2abbc.png) #### Alerts Any widget can carry alert rules, evaluated on every refresh — scheduled or manual.

Condition

Fires when

Threshold

A number crosses a boundary (>, >=, <, <=, ==, !=)

Change

The value moves by more than N %, or N in absolute terms, up or down

Absence

The widget has not refreshed within a time window

Two independent gates sit between "condition met" and "you are notified": - **Notify mode** — _on change_ (the default) fires only on the transition from healthy to triggered, and stays quiet while the condition remains true. _Every_ fires on each evaluation. - **Cooldown** — a minimum number of minutes between notifications, regardless of mode. Every fire is recorded in the widget's alert history with the value that caused it. A fired alert can also start a Workflow. ### Workflows **Workflows** are visual automations: a canvas of nodes joined by edges, run in order, with branching, loops, human approval and AI steps. Available on Max and Ultra. #### Triggers Every workflow has exactly one trigger:

Trigger

Fires when

Alert

A dashboard alert rule fires. One alert can start several workflows.

Schedule

A cron expression, in the time zone you choose

Webhook

A third-party system posts to a private URL (Jira, PagerDuty, a script)

Manual

Somebody presses Run

A workflow can also be invoked by another workflow as a sub-workflow, synchronously or in the background. #### What a node can do

Group

Nodes

Actions

Call any Applivery capability; send an HTTP request; run another workflow

AI

Ask a model to classify, summarise or draft, and use the result downstream

Notifications

Email, Slack, Google Chat, generic webhook

Logic

Conditional, switch, filter, transform, aggregate, merge

Loops

For-each over a list; retry with exponential backoff

Human

Approval gate — pauses the run and waits for a person

Utility

Delay, expression evaluation

Values flow between nodes as `{{templates}}` — `Device {{trigger.deviceName}} — battery {{trigger.battery}}%`. ![workflow](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/4520b400-e5c6-4176-8e88-57ea7ecaaa10.png) #### The approval gate An **approval** node pauses the run and sends a link. The recipient approves or rejects, and the workflow continues down the matching branch. If nobody answers within the timeout, the run takes the **rejected** branch and records that it timed out — it does not sit paused forever, and it does not proceed by default. This is the node to put in front of anything that touches Devices in bulk. #### The AI Workflow Builder Rather than drawing the graph yourself, describe it: > Create a Slack alert when a Device goes non-compliant. > Every Monday at 9 a.m., send a Google Chat summary of total Devices by platform. The builder proposes a concrete set of changes and **waits for you to approve them** before touching the canvas. Applied turns can be reverted one at a time. #### Integrations Notification and AI nodes need credentials, configured once per Workspace under the gear icon > **Integrations**: API keys for Anthropic, OpenAI or Google, a Resend key for email, and Incoming Webhook URLs for Slack and Google Chat. Each entry carries setup instructions with links to the right page on the provider's side. They are encrypted at rest, belong to the Workspace rather than to you, and are separate from the credentials chat uses. #### History Every run is recorded with its trigger, its duration, its outcome and the input and output of each node, so a failure can be read rather than guessed at. Node-level history is kept for 30 days; run status is kept indefinitely. ### Cowork **Cowork** inverts the initiative. Instead of waiting to be asked, Applivery Intelligence's **Agentic Specialists** run in the background, examining the fleet on a schedule and producing **findings** — inbox items you acknowledge, accept, discuss or approve for execution. Available on Max and Ultra. #### Monitors, checks and findings A **check** is a fixed thing to look for, shipped by Applivery. A **monitor** is your Workspace's instance of that check: enabled or disabled, on a cadence, with a scope, thresholds and a minimum severity. Two Agentic Specialists run them. The **Posture Auditor** takes the hygiene, access, inventory and configuration checks, and may propose a remediation from a fixed catalogue of actions. The **Threat Analyst** takes the anomaly checks and never proposes a write at all — its job ends at telling you what changed. You configure monitors. You do not write checks — and that is the point. Detection is deterministic code, not a specialist deciding what looks wrong. The specialist receives what the check already found, along with the evidence, and its job is to triage it, write it up clearly, and where the check allows it, propose a remediation. A number in a finding was computed, not generated, and it is recomputed afterwards to confirm it. #### What the catalogue covers - **Posture and hygiene** — stale check-in, compliance drift, unassigned Policies, obsolete OS versions, low battery, empty Audiences, inert Automation Rules. - **Access and people** — over-broad grants, conflicting roles, Collaborators without MDM access, privileged accounts without 2FA, dormant privileged accounts, never-activated accounts, grants that reach nobody, redundant app roles. - **Inventory** — assets linked to deleted Devices, duplicate serials, asset type contradicting the hardware, managed Devices with no asset record. - **Effective configuration** — Policy composition conflicts, kiosk hardening gaps, trivial secrets in an applied configuration, Policies that compose to nothing. - **Usage and anomalies** — idle managed assets, data-usage spikes, app-usage spikes, enrolment-rate spikes, changes to privileged grants. Anomaly checks compare a Device only against **its own** history, so a heavy user is not flagged for being a heavy user. #### Reading the inbox Findings arrive as a **list** or a **board**, filterable by monitor. Every card names the check that produced it, its severity, and the Devices or people it covers. ![cowork list](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/53420cbf-fb65-44b4-a934-de49a8163906.png) ![cowork detail](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/a6a18bd1-e13e-4c60-8f0b-33d70b134bc4.png) The status of a run matters as much as its result. Cowork distinguishes "the check ran and found nothing" from "the check could not run" — a credential problem, an empty population, a budget stop. An empty inbox only shows the green _Nothing to review_ state when there is positive evidence that the fleet was actually examined. For each finding you can: - **Discuss it** in a side chat with the specialist that produced it, which still has the evidence. - **Accept** it — it stays detected and recorded, but stops asking. Accepted findings are listed separately and acceptances can be reviewed and undone. - **Dismiss** it. - **Approve** the proposed remediation, where the check offers one. #### Approve, execute, revert When you approve a remediation: - It runs a **fixed, versioned template** shipped by Applivery, not a plan the model composed. Cowork can name a remediation; it cannot invent one. - It targets **only** the subjects in the finding that survived re-verification. The model is structurally prevented from naming a target of its own. - It runs under **your** Applivery credentials, so Applivery's own permissions are the real backstop and the audit log names the right person. - **Revert** undoes only the steps that actually succeeded, and only the exact changes that execution made, per Device. Reverting does not re-open the finding: the problem is back exactly as it was. #### Limits and stopping it Cowork is the only surface that spends without a human waiting on it, so it is bounded separately: its own daily token budget, a cap on runs per Workspace per day, and caps per run on iterations, tool calls, findings emitted and actions executed. Your own controls are per monitor, on **Cowork > Monitors**: enable a check or disable it, change its cadence, narrow its scope, move its thresholds, raise its severity floor. A disabled check does not run and reports nothing, and the page says so on the card rather than leaving it looking healthy. To stop Cowork entirely in a Workspace, disable every enabled monitor. Applivery also operates platform-level switches that can suspend Cowork detection, delivery or execution across the service — for an incident, or at your request. Those are not in your dashboard; ask your Applivery contact. --- ## Applivery Intelligence FAQ Source: https://docs.applivery.com/en/intelligence/faq/ Description: Answers to the most common questions about Applivery Intelligence — access and seats, what it can do, approvals and safety, usage limits, guardrails and data handling. :::info **Generally Available — and actively evolving.** Applivery Intelligence is generally available and supported. It is also an AI product under continuous research and improvement: answers are generated, capabilities change between releases, and mistakes are possible. Review what it produces before acting on it. ::: ### Access and seats **How do I get access?** Your Applivery organization Owner buys a seat and assigns it to you. Then open Intelligence from the ✨ button in the Applivery dashboard top bar. There is nothing to install or configure. See [Getting started](https://docs.applivery.com/en/intelligence/get-started/). **Do I need to enter an API key or connect my Applivery account?** No. Intelligence runs embedded in the Applivery dashboard and reuses your active session. If you can see the dashboard, you are already authenticated. **Who can buy seats?** Only the Applivery organization **Owner**. The role is read live from the Applivery directory, so it always matches who is Owner right now. **Why is Insights, Workflows or Cowork missing from my navigation?** Those three require a **Max** or **Ultra** seat. Chat is available on every tier. **I have several Workspaces. Do I need a seat in each?** Yes — a seat is granted in one Workspace. Conversations, dashboards, workflows and monitors are scoped to a Workspace too, so switching Workspace switches all of them. **What happens to my work if my seat is unassigned?** Nothing is deleted. Dashboards, workflows and monitors belong to the Workspace, and keep running. ### What it can and cannot do **Where does it get its data?** From your live Applivery Workspace, through the same API the dashboard uses. There is no separate copy of your fleet and no cached snapshot it answers from. **Can it change things, or only read?** Both. It can lock, rename, restart, wipe, move, disenroll, install and uninstall; create and update Policies; author and assign scripts; manage Segments and Audiences. Every one of those asks you first. **Can it do things I cannot do?** No. It acts as you, with your Applivery role. If the dashboard would refuse you, so will Intelligence. **Will it answer questions that are not about my fleet?** No. Requests unrelated to device management are declined. It is scoped deliberately. **Can it answer questions about the Applivery product itself?** Yes. The Knowledge Agent answers from the public Applivery documentation and REST API reference, with links to the pages it used. **Why did it say it created a CSV, a report or a Policy, and nothing appeared?** It should not, and there are explicit rules against exactly that. If you see it, treat the claim as false — check the Applivery audit log or the artifact panel for what actually happened, and report it. CSV, specifically, is not a separate action: any table artifact carries its own download button. **Why did it give me a different answer to the same question?** Answers are generated, and the fleet moves underneath them. For anything you need to be reproducible, pin it as an Insights widget — a widget re-runs a fixed query rather than re-deciding how to answer. ### Approvals and safety **What needs my approval before it runs?** Out of the box, everything — reads included. Every capability starts on **Needs approval**, so a new seat is asked about each call until you relax the ones you trust. You do that in **Settings > Integrations > Applivery MDM > Tool Permissions**. **Where do I change that?** The gear icon in the top bar, then **Integrations > Applivery MDM > Tool Permissions**. Each capability can be set to *Always allow*, *Needs approval* or *Blocked*. A sensible starting point is allowing the reads you use constantly — list Devices, get a Device, get Device apps — and leaving everything that changes something on *Needs approval*. **Is that setting mine or the Workspace's?** Yours. It applies to your own conversations only. Relaxing a capability does not stop a colleague being asked about it, and blocking one does not take it away from them. There is no Workspace-wide tool policy in Intelligence — the shared backstop is your Applivery role, which no setting here can widen. **Which actions always ask, no matter what?** **Wiping** a Device, **locking** a Device, and **anything that deletes**. These cannot be set to *Always allow* by anybody, including Applivery. They show a **Locked** badge in the list. **Can I see what has actually been called?** Yes — the **History** tab beside Tool Permissions lists the calls from your own chat sessions with their input, response, latency and time, over the last 7 days, 30 days or 3 months. **What does an approval prompt show me?** The exact capability being called, on which object, with which parameters — before anything happens. **What if I ignore an approval prompt?** It expires and the action does not run. Nothing proceeds by default. **Do Workflows have the same protection?** Workflows run under the identity of the person or schedule that started them, with the same Applivery permissions. For bulk operations, put an **approval node** in front of the destructive step — the run pauses and waits for a person, and if nobody answers within the timeout it takes the rejected branch. **Can Cowork change my fleet on its own?** No. Cowork proposes; a person approves. When you approve, the remediation is a fixed template shipped by Applivery, restricted to the objects in that finding, executed under **your** credentials. It can be reverted, and the revert only undoes what the execution actually changed. **Is there an emergency stop?** For Cowork: disable the monitors on **Cowork > Monitors**. A disabled check does not run and reports nothing, and disabling all of them stops Cowork in that Workspace. For chat: set the capability to *Blocked* in your own Tool Permissions, which stops it for you, or narrow the person's Applivery role, which stops it everywhere including the Applivery dashboard itself. Applivery additionally operates platform-level switches that can suspend Cowork across the service — ask your Applivery contact if you need that. **Will the actions show up in the Applivery audit log?** Yes, under the name of the person who ran or approved them. ### Limits and usage **How is usage counted?** In credits, against your seat's allowance for the billing period. Reading Devices, reasoning about them and rendering results all consume some. **Is there an hourly or daily cap?** No. The only limit is the one for the whole billing period. **What happens when I run out?** Your plan allowance goes first, then the Workspace's purchased credits if your seat is allowed to draw on them. If neither is available, chat pauses until the reset date. Nothing is lost. **Does my allowance roll over?** No. It refills in full on the reset date. **Do scheduled workflows and Cowork monitors eat my personal allowance?** No, deliberately. Background work spends from a separate shared pool funded by Max and Ultra seats, so a job running overnight cannot leave you with no chat in the morning. **Why does my Workspace have no automation pool?** Because no seat in it is Max or Ultra. Free and Pro seats fund nothing. **Is there a limit on how many dashboards, workflows or monitors I can create?** No numeric limit. Those objects belong to the Workspace, not to a person, so capping them per seat would produce nonsense. **How long is history kept?** Workflow node-level history 30 days; alert history and dashboard refresh history 60 days; usage records 90 days. Workflow run status is kept indefinitely. Conversations, dashboards, artifacts, workflows and findings are kept until you delete them. ### Guardrails **What is filtered before the assistant sees my message?** Attempts to override its instructions or extract its configuration, requests outside device management, and messages over the configured length limit. The scope and the limits are set per Workspace by Applivery, not from your dashboard — ask your Applivery contact if the defaults do not suit you. **Can somebody get it to leak another customer's data?** Every request is resolved to one Workspace, and credentials are resolved per Workspace on each call. There is no shared account and no cross-Workspace query path. **What stops it inventing a fleet when it cannot reach one?** If the Workspace exposes no Applivery capabilities — a misconfigured Workspace, or a role with no permissions — chat refuses to answer at all rather than answering from general knowledge. You get an explicit banner instead of a plausible fiction. **What stops a Cowork monitor from spamming the inbox?** Per-run caps on findings, tool calls and iterations; a daily cap on runs per Workspace; a daily cap on executed actions; and its own token budget separate from chat's. **Does an empty Cowork inbox mean everything is fine?** Only when it says so. Cowork distinguishes "ran and found nothing" from "could not run", and only shows the all-clear on evidence that the fleet was examined. ### Data and privacy **Is my fleet data used to train models?** No. Your data is used to answer your request. **What is stored?** Your conversations and the artifacts they produced, your dashboards and their last refreshed data, your workflows and their run history, your Cowork monitors and findings, and operational records of usage for billing and support. **Where does it run?** On Applivery's infrastructure, over HTTPS end to end. The Applivery credentials it uses are held encrypted and resolved per Workspace at call time. **Can I delete a conversation?** Yes, from the conversation menu. Dashboards, workflows and findings are deletable too. **Who in my organization can see what?** Conversations are yours alone — they are listed against your own account and colleagues in the same Workspace do not see them. Your Tool Permissions are yours too. Dashboards, workflows, Cowork findings and the Workspace's integration credentials are Workspace-level and shared with everyone who holds a seat. ### Troubleshooting **"Connect Applivery" appears instead of the chat.** The embedded session has not been handed over. Reload the Applivery dashboard and reopen Intelligence. **"Session expired".** Your Applivery session ended. Sign in to the dashboard again. **It answers, but never reads real data.** Usually a Workspace without Endpoint Manager, or an Applivery role without Device permissions. Confirm both in the Applivery dashboard. **A widget shows "Overdue — refresh may not be running".** The dashboard's schedule has not fired within its expected window. Try **Refresh all**; if it keeps happening, check that the Workspace still has an automation pool — that is, Max or Ultra seats. **An alert never fires.** Check the notify mode — *on change* stays silent while the condition remains continuously true. Also check the cooldown, and confirm the widget is actually refreshing. **A monitor produces nothing.** Open the run status. `skipped` and `credential error` are distinct from "found nothing", and the inbox tells you which one it was. **A long answer stops mid-way.** The turn ran out of output budget. Ask for a narrower slice — one platform, one Segment, one page — rather than the whole fleet at once. --- ## Getting Started with Applivery Intelligence Source: https://docs.applivery.com/en/intelligence/get-started/ Description: Turn on Applivery Intelligence for your organization — buy and assign seats, open it from the Applivery dashboard, and ask your first question about your fleet. TL;DR: The Workspace Owner buys seats and assigns them. Anyone with a seat opens Intelligence from the ✨ button in the Applivery dashboard top bar — no credentials, no setup, no separate login. Key topics: Requirements, Buying seats, Assigning seats, Opening Intelligence, Asking the first question, Applivery, Applivery Intelligence, Endpoint Manager, Workspace Owner **Applivery Intelligence** is a conversational layer over your Applivery Workspace. Instead of navigating to a list, filtering it and reading it, you ask: > Which Macs have not checked in for 30 days? > Show me every Device that is missing disk encryption, grouped by Policy. > Lock the laptop David lost yesterday. It answers from **live** Applivery data, renders the result as an interactive table, chart, map or Device card, and — when you ask it to change something — asks you to confirm before it does. :::info **Generally Available — and actively evolving.** Applivery Intelligence is generally available and supported. It is also an AI product under continuous research and improvement: answers are generated, capabilities change between releases, and mistakes are possible. Read what it produces before acting on it, and read [Permissions and approvals](https://docs.applivery.com/en/intelligence/capabilities/) before you relax the approval prompts on anything that writes to real Devices. ::: ### Requirements Before anyone can use it, you need: - **An Applivery account** with access to at least one Workspace. Intelligence never creates accounts or Workspaces. - **Applivery Endpoint Manager (UEM/MDM)** in that Workspace. Intelligence reads and acts through the same Applivery API the dashboard uses, so a Workspace with only App Distribution returns very little. - **A seat**, assigned by the Workspace Owner. See [Plans, seats and billing](https://docs.applivery.com/en/intelligence/plans-and-billing/). - **Nothing else.** There is no agent to install, no API key to generate, no network change and no separate password. Intelligence reuses your existing Applivery session. :::warning Intelligence acts **as you**. Your Applivery role is the ceiling: if you cannot wipe a Device in the Applivery dashboard, you cannot wipe it by asking Intelligence either — the API returns the same permission error it always would. ::: **Buy the seats** Applivery Intelligence is licensed **per person, by seat**. The organization Owner buys a quantity of seats at a given tier; nobody else buys anything. 1. Open Intelligence and go to **Plan & billing > Seats & billing**. 2. Pick a **Tier** — Pro, Max or Ultra — and enter the **total** number of seats the Workspace should end up with. 3. Confirm. The organization's card on file is charged straight away, prorated for the rest of the current period. Only the Applivery organization **Owner** sees the purchase controls. The role is resolved live from the Applivery directory every time, so promoting somebody to Owner in Applivery gives them the controls without any action in Intelligence. Tiers, prices and what each one includes are in [Plans, seats and billing](https://docs.applivery.com/en/intelligence/plans-and-billing/). **Assign the seats** A bought seat does nothing until it is given to somebody. 1. Go to **Plan & billing > Seats & billing > Who has a seat**. 2. Find the person and assign them a seat of the tier you want them on. 3. Optionally set their **Extra credits cap** — how much of the Workspace's shared credit balance that person may spend once their own plan allowance runs out. Leave it empty for no cap; set it to `0` to stop them drawing on the shared balance at all. Unassigning a seat frees it **immediately**, so it can be given to someone else the same day. It is not refunded — the seat stays paid until the period ends. :::tip You cannot reduce the number of seats below the number currently assigned. Unassign first, then lower the quantity. ::: **Open Intelligence** Anyone with a seat opens Intelligence from the **Applivery dashboard**, using the **✨ button** in the top navigation bar, next to the search icon. ![intelligence](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/74884cd7-e28a-4e7f-941a-ee7e52a345be.png) Intelligence opens **embedded inside the dashboard**, on the Workspace you are already looking at. That is the whole setup: - **No credentials to configure.** It reuses your active Applivery session. - **No second login.** Signing out of Applivery signs you out of Intelligence. - **No workspace picker to get wrong.** It starts on the Workspace the dashboard is on. If your account reaches several Workspaces, switch from the Workspace selector in the Intelligence top bar. Each Workspace has its own conversations, dashboards, workflows, monitors and seats. **Ask something** Start read-only. A good first question proves the connection end to end: > How many Devices are enrolled in this workspace? Then try something that produces an artifact — an interactive result you can sort, drill into, download as CSV, or pin to a dashboard: > Show me all Android Devices with their OS version and last check-in. > Which Devices are below macOS 26.3? Group them by employee. > Where are my lost-mode Devices right now? ### Three things worth knowing on day one - **Type** `@` **to reference a specific object.** You can mention a Device, Policy, MDM User, Segment, Device Audience, Automation Rule or Enrollment Template by name instead of describing it. - **Suggestions appear under each answer.** They are grounded in what Applivery can actually do, so they are a fast way to learn the surface. - **It asks before it acts — at first, before everything.** Every capability starts on _Needs approval_, reads included, so your first few questions will each raise a prompt. Go to the gear icon > **Integrations > Applivery MDM > Tool Permissions** and set the reads you use constantly to _Always allow_. Wipe, lock and delete stay gated whatever you choose. ### What you will not have on every plan Chat is available on every tier, including Free. **Insights, Workflows, Cowork and the AI Workflow Builder require a Max or Ultra seat.** If the navigation shows a surface you cannot open, the seat tier is why — see [Plans, seats and billing](https://docs.applivery.com/en/intelligence/plans-and-billing/). ### If something does not work

Symptom

Most likely cause

"Connect Applivery" instead of the chat

The embedded session has not been handed over yet. Reload the Applivery dashboard.

"Session expired"

Your Applivery session ended. Sign in to the dashboard again.

Intelligence answers but never reads real data

The Workspace exposes no MDM tools — usually a Workspace without Endpoint Manager, or an Applivery role with no Device permissions.

A surface is missing from the navigation

Your seat tier does not include it.

"No seat assigned" on Plan & billing

Ask your Owner to assign you one.

--- ## Plans, Seats and Billing Source: https://docs.applivery.com/en/intelligence/plans-and-billing/ Description: How Applivery Intelligence is licensed — the four tiers, how seats are bought and assigned, how usage allowances and shared credits work, and who pays for background automation. Applivery Intelligence is licensed **per person**. The Applivery organization **Owner** buys a quantity of seats at a tier and assigns them to named people. Nobody else buys anything, and nobody subscribes individually. :::info **Generally Available — and actively evolving.** Applivery Intelligence is generally available and supported. It is also an AI product under continuous research and improvement: capabilities, allowances and pricing may change between releases. What follows describes how the system works today. ::: ### Seats, not subscriptions Three rules govern seats, and all three are deliberate: 1. **You cannot assign more seats than you bought.** The check happens inside the assignment itself, so two Owners acting at the same moment cannot both take the last seat. 2. **Unassigning frees a seat immediately, and is not refunded.** The seat stays paid until the end of the period, so it can be handed to someone else the same day. 3. **You cannot reduce the quantity below what is assigned.** Unassign people first, then lower the number. Everything a seat produces — conversations, dashboards, workflows, monitors — belongs to the **Workspace**, not to the person. When somebody leaves, their work stays. ### The tiers | | **Free** | **Pro** | **Max** | **Ultra** | | --- | --- | --- | --- | --- | | Price | — | €29 /seat/mo | €99 /seat/mo | €199 /seat/mo | | Chat | ✅ | ✅ | ✅ | ✅ | | Insights (dashboards & alerts) | — | — | ✅ | ✅ | | Automation Workflows | — | — | ✅ | ✅ | | AI Workflow Builder | — | — | ✅ | ✅ | | Cowork proactive monitoring | — | — | ✅ | ✅ | | Usage per period | A limited taster | Baseline capacity | 5× Pro capacity | 10× Pro capacity | | Funds shared automation credits | — | — | 30,000 /mo | 100,000 /mo | Prices are quoted excluding VAT, which Stripe adds from the organization's billing address. Billing is monthly and recurring. **Max and Ultra have the same features.** The difference between them is headroom, not capability — Ultra exists for people who run out of Max. :::tip Every tier can drive the same models. Tiers differ by **which surfaces you can reach** and **how much you can use them**, never by giving one customer a smarter assistant than another. ::: ### How usage is measured Each seat carries a **usage allowance for the billing period**, expressed in credits. Everything the assistant does on your behalf — reading Devices, reasoning about them, drawing a chart — consumes some of it. - **It refills in full on the reset date, and does not roll over.** Unused capacity is not banked. - **There is no hourly or daily cap.** The only limit is the one for the whole period. - **Background work never touches it.** Scheduled workflows and Cowork monitors spend from the shared pool described below. Your current consumption, the reset date and the breakdown by surface are on **Plan & billing > Usage**. #### What happens when you run out 1. Your plan allowance is spent first. 2. Then the Workspace's purchased **usage credits**, if there are any and if your seat is allowed to draw on them. 3. If neither is available, chat pauses until the reset date. Nothing is deleted and nothing is lost — it resumes on its own. ### Shared usage Two separate shared balances exist, and they solve different problems. #### Shared usage credits (bought) The Owner can buy prepaid credit packs into a balance that belongs to the **whole Workspace**. A seat draws on it only **after** its own allowance runs out. Each assignment carries an **Extra credits cap** — how much of that shared balance that person may spend once their own allowance is gone: | Value | Effect | | --- | --- | | **Empty** | No cap | | **A number** | That many credits, then they stop | | **`0`** | They never draw on the shared balance at all | The cap exists so one heavy user cannot spend the Workspace's balance in an afternoon. It never limits their own plan allowance, which is always theirs in full. **Auto-reload** can buy another pack automatically when the balance drops below a threshold, with a monthly ceiling of its own. It pauses itself after repeated failed charges rather than retrying forever. #### Shared automation credits (derived) This one is **not bought** — it is derived from the seats. Each **Max** seat contributes 30,000 credits a month and each **Ultra** 100,000. Free and Pro contribute nothing. Scheduled workflows, Cowork monitors and batch jobs spend from this pool instead of from anybody's personal allowance. The reason is concrete: a monitor running at 03:00 must not be able to leave someone with no chat in the morning — and it must not die when the person who created it leaves the company. :::warning A Workspace with no Max or Ultra seat funds no automation pool. Scheduled workflows and Cowork monitors have nothing to draw on and will not run. ::: ### Who can buy **Only the Applivery organization Owner.** The role is resolved **live** from the Applivery directory each time the page is opened — not from a cached membership record and not from your login session. Promote somebody to Owner in Applivery and the controls appear for them; demote them and the controls disappear. Everyone else sees their own plan, their own usage and their own credit cap, and nothing else. ### Buying and changing quantity On **Plan & billing > Seats & billing**: 1. Choose the **Tier**. 2. Enter the **total** number of seats the Workspace should end up with — not the number to add. 3. Confirm. The organization's saved card is charged **immediately**, prorated for the remainder of the current period. If there is no saved card, or the bank asks for strong authentication, you are sent to Stripe to complete the payment once; after that, purchases confirm in place. Before charging, the confirmation panel shows exactly who is billed, which card is used, and whether VAT will be added. ### Where the billing details come from The legal name, tax ID, invoice email, billing address and card all come from **your Applivery organization**. Intelligence reads them; it does not own them. To change any of them, go to the Applivery dashboard > **Workspace > Billing**. Changes appear in Intelligence on the next load. Seat charges appear on the organization's normal Applivery invoice. The **Credit purchases** ledger inside Intelligence lists prepaid credit packs only. :::warning If the card on file has expired, renewals fail. A failed payment does not cut you off the same hour — the seat stays live through the payment retry window — but it will lapse if it is not fixed. ::: ### Paying through your Applivery contract Entitlements can be granted outside Stripe for contract customers. Talk to your Applivery contact if you would rather not pay by card. --- ## Inventory Source: https://docs.applivery.com/en/inventory/ Description: Applivery Inventory — track all your organization's assets, including enrolled Devices, hardware, peripherals, and software licenses. TL;DR: Applivery's Inventory module offers a centralized platform to track and manage all organizational assets, including devices, hardware, and software. Key topics: Asset Inventory, Device Management, Hardware Tracking, Software Tracking, Applivery, CSV ## Inventory Applivery's Inventory module gives you a centralized place to track every physical and virtual asset in your organization — not just the Devices enrolled in Device Management, but any hardware or software asset you need to keep a record of. Devices enrolled in Applivery are automatically added to your Inventory. For assets that can't be enrolled — like legacy hardware, third-party equipment, or software licenses — you can add them manually or import them in bulk via CSV. --- ## Asset Management Source: https://docs.applivery.com/en/inventory/asset-management/ Description: Track and manage all your organization’s assets with Applivery Inventory, from devices to software licenses, and streamline lifecycle management. TL;DR: Applivery's Inventory module simplifies asset management by providing a centralized platform to track and manage all your organization's hardware and software assets. Key topics: Asset identification, Asset tracking, Asset lifecycle management, Bulk inventory import, Inventory reporting, Applivery, CSV, Microsoft Excel, Google Sheets Applivery's Inventory module gives you a centralized place to track every physical and virtual asset in your organization — not just the Devices enrolled in Device Management, but any hardware or software asset you want to keep a record of. Think laptops, monitors, servers, networking equipment, smartphones, software licenses, and more. This makes it easy to maintain accurate records of what you have, where it is, who's using it, and what condition it's in — all from the same platform you already use to manage Devices. The Inventory module covers the full asset lifecycle: - **Identification**: Catalog every asset your organization uses, whether enrolled in Applivery or not. - **Tracking**: Store detailed information for each item — device name, model, serial number, location, assigned user, purchase details, and more. - **Monitoring and updates**: Keep records current as Devices are added, moved, upgraded, or retired. - **Lifecycle management**: Track warranties, expected lifespan, and maintenance contracts from procurement through disposal. ### Adding Devices to the Inventory Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), click on the top 9-dot menu and select Inventory. ![inventory](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/5940f5c1-e934-4d5f-a620-c2cd4f12bd00.png) When you enroll a Device in Applivery, it is automatically added to your Inventory. For assets that cannot be enrolled through the platform — such as legacy hardware, third-party equipment, or software licenses — you can add them manually using the **Create inventory item** 1 button, or import multiple entries at once via a CSV file using the **Import** 2 button. ![add inventory item](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/695465ef-a6f2-41bf-a155-0d0f1ed6004a.png) All Inventory entries are fully editable and are organized into the following sections. ### Basic General identification details for the asset: - **Device type**: The category of the item. When importing via CSV, use one of the following values: `accessControl`, `accessPoint`, `barcodeScanner`, `cardReader`, `cameraCctv`, `cameraIp`, `desktopComputer`, `device`, `dockStation`, `externalDevice`, `externalHardDrive`, `firewall`, `hdmiAdapter`, `headphones`, `keyboard`, `laptop`, `microphone`, `monitor`, `mouse`, `posTerminal`, `printer`, `router`, `scanner`, `server`, `smartphone`, `smartwatch`, `softwareLicense`, `speaker`, `switch`, `tablet`, `ups`, `usbFlashDrive`, `videoConference`, `virtualMachine`, `webcam`. - **Display name**: The visible name of the asset. - **Owner**: The person or team responsible for the asset. - **Location**: Physical location of the asset (e.g. Barcelona, Madrid). - **Status**: Reflects the current phase or condition of the asset within its lifecycle. This is independent from the enrollment status shown in the **Hardware** section, which is pulled from the MDM system. You can update this field manually at any time. Accepted values: `active`, `inactive`, `provisioning`, `deleted`, `delete_requested`, `retired`, `lost`, `stolen`, `destroyed`, `sold`, `inStock`, `toBeReturned`, `expired`, `inRepair`, `assigned`, `external`, `available`, `damaged`, `emergency`, `unknown`, `disabled`, `returnedToProvider`, `laptopNotRequired`, `personalLaptop`, `clientLaptop`. - **Classification**: Criticality level — `low`, `medium`, or `high`. - **Description**: A free-text field for any additional context or notes about the asset. - **Associated members**: The user or users assigned to this asset — typically someone within your organization. You can assign one or multiple Device Employees. Users can be selected from existing records in Applivery or created on the fly. ![inventory fields](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/efd74fcd-2a0f-45a1-96a4-a09b717a05d1.png) ### Hardware Technical specifications and enrollment details: - **Manufacturer**: The brand of the Device. - **Model**: The specific model name or number. - **Serial number**: The Device's unique serial number. - **IMEI**: Unique identifier for mobile Devices. - **UDID**: Unique Device Identifier — particularly useful for Apple Devices. - **Foreign ID**: An optional field for any external or third-party identifier. - **OS Name / OS Version**: The name and version of the operating system installed on the Device. - **Enrolled Device**: Shows whether the Device is currently managed by Applivery and its enrollment or provisioning status. Possible values: `active`, `deleted`, `delete_requested`, `provisioning`, `unknown`. This field is retrieved in real time from Applivery Device Management and cannot be edited manually. It also includes a direct link to the Device's record and a thumbnail image. ### Network Network connectivity details: - **Host name**: The network-assigned name of the Device. - **IP address**: The Device's IP address, whether static or dynamic. - **MAC address**: The Device's unique MAC (Media Access Control) address. ### Purchase Purchase and billing information: - **Provider**: The supplier from whom the Device was purchased. - **Order number**: The reference number for the purchase order. - **Part number**: The Device's part or catalog number. - **Price**: Cost of the Device, including currency. - **Order date**: The date of purchase. - **Frequency**: Whether this is a one-time purchase or a recurring cost (monthly, yearly, etc.). ### Lifecycle Asset lifecycle tracking: - **Warranty**: The end date of the asset's warranty. - **Expected useful life**: The estimated lifespan of the asset, expressed in months or years. ### Seats Useful when an asset is shared across multiple licenses: - **Available seats**: The number of seats currently available. - **Total seats**: The total number of seats assigned to this asset. ### Metadata Add custom properties to any Inventory item using key/value pairs or directly in JSON format. This is useful for capturing organization-specific fields that don't fit into the standard sections above. ### Notes A free-text field for observations, known issues, escalation history, or any other additional context. ### Adding Inventory Items in Bulk The bulk import feature lets you add or update multiple assets at once using a CSV file, without having to enter them one by one. This is especially useful when setting up your Inventory for the first time or synchronizing large volumes of devices after a hardware refresh. The key benefits are: - Saves time on large-scale data entry. - Minimizes the risk of manual errors. - Supports both initial uploads and ongoing updates. **Export or download the CSV template** Click the **Import** button and download the CSV template provided. It includes all required fields and the correct format for a successful import. **Prepare your CSV file** Open the template in a spreadsheet editor such as Microsoft Excel or Google Sheets and fill in the details for each asset you want to add. Do not change the column headers or leave empty rows between entries. When you're done, save the file in **CSV format** to ensure compatibility. **Upload the CSV file** Return to the Inventory Import panel in Applivery. Click **Select CSV file**, choose the file you prepared, and upload it. ![select csv file](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/9c0189fd-6a1b-40c5-8042-12ca0a700698.png) **Review and confirm** Once the file is uploaded, Applivery will display a preview of the data. Review the information carefully to confirm everything looks correct, then confirm the import. Applivery will process the file and add or update items accordingly. **Verify the results** After the import completes, go to the **Inventory** section and confirm that all items were added or updated correctly. If any entries were skipped or flagged with errors, correct the CSV file and repeat the process for those items. :::tip Before a bulk import, export your current Inventory as a backup. If you're working with a very large dataset, consider splitting it into multiple CSV files to avoid row limits or timeout issues. Always use the official Applivery template exactly — changing column names or adding extra columns can cause validation errors during import. ::: :::warning If you disenroll a Device from Applivery, it will **not** be automatically removed from the Inventory. Only manually created or CSV-imported items can be deleted. Enrolled Devices remain in the Inventory list even after disenrollment. ::: --- ## Platform & Administration Source: https://docs.applivery.com/en/platform/ Description: Admin settings, roles, billing, and organization management. The Platform section covers the cross-product administration layer of Applivery — the settings and tools that apply across both App Distribution and Device Management. This includes Workspace and organization configuration, user roles and permissions, authentication, billing, and the platform API. Whether you're setting up a new Workspace, configuring SSO, managing Collaborator access, or building integrations with the Applivery API, this is the place to start. --- ## API Source: https://docs.applivery.com/en/platform/api/ Description: Applivery Platform API — manage Service Accounts, authentication, and access control for programmatic integration with your systems. TL;DR: The Platform API allows developers to programmatically interact with the platform through service accounts, authentication, and a complete API reference. Key topics: API, Service Accounts, Authentication, API Reference, Integration The Applivery API lets you interact programmatically with the platform — creating Service Accounts for secure authentication and using the available endpoints to automate tasks across App Distribution and Device Management. Manage Service Accounts and use the full API reference, with endpoint details, request formats, and response examples. --- ## Service Accounts Source: https://docs.applivery.com/en/platform/api/service-accounts/ Description: Applivery Service Accounts for secure, automated API access — roles, permissions, and best practices for token management. TL;DR: Applivery Service Accounts enable secure, automated API access for non-human entities using Bearer tokens and workspace-level permissions. Key topics: Service Account creation, Roles and Permissions, Bearer token usage, Secure token storage, Service Account vs App API Token, Applivery, Workspace API, BrowserStack App Live, GitHub Actions, Azure Pipelines, Bitrise, Jenkins A Service Account is a special type of Applivery account designed for non-human, machine-to-machine authentication. Unlike user accounts, which are tied to a person, a Service Account represents an automated system, integration, or pipeline that needs to interact with the Applivery API on its own behalf. Service Accounts authenticate against the **Workspace API** (Organizations API) using a Bearer token. This gives them Workspace-level access to resources across all Apps and modules in your organization, making them the right credentials for cross-app automation and platform-level integrations. * * * ### Service Accounts vs. App API Tokens Applivery has two distinct authentication mechanisms. Choosing the right one for your use case is important: | | Service Account | App API Token | | --- | --- | --- | | **Scope** | Workspace-wide — all Apps in the organization | Single app only | | **Used for** | Workspace API (Organizations API) | Integrations API (per-app upload, Publications, Builds) | | **Typical use cases** | Cross-app automation, BrowserStack App Live, Workspace-level scripts | CI/CD build uploads, per-app integrations | | **Token format** | Bearer token | App Token string | | **Created in** | Workspace Settings → Service Accounts | App Settings → API Tokens | If you need to upload Builds from a CI/CD pipeline for a single app, use an [App API Token](https://docs.applivery.com/en/app-distribution/api/app-api-token/). If you need to query or manage resources across multiple Apps, or connect a third-party platform like BrowserStack App Live, use a Service Account. * * * ### Roles and Permissions When creating a Service Account, you assign it one of three roles. The role determines what operations the Service Account can perform across the Workspace: | Role | Description | | --- | --- | | **Admin** | Full access to all Workspace resources and settings. Can create, modify, and delete any resource. | | **Developer** | Read and write access to app resources (Builds, Publications, configurations). Cannot manage Workspace settings or other users. | | **Viewer** | Read-only access to Workspace resources. Cannot create or modify any data. | :::tip Follow the principle of least privilege: assign the most restrictive role that still allows the Service Account to perform its intended function. ::: * * * ### Creating a Service Account Service Accounts are managed from your Workspace Settings. Only users with **Admin** permissions can create or delete Service Accounts. Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), go to your **Workspace Settings** 1 from the top dropdown menu, then open **Service Account** 2 in the left-hand menu and click the **\+ Create Service Account** 3 button. ![Service Account](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/7b329256-a6af-40b1-a101-837f11ca1866.png) Enter a descriptive name for the account (e.g., `ci-pipeline`, `browserstack-integration`), and select a **Role**: Admin, Developer, or Viewer. Once you're doine click **Create**. :::warning Don’t forget that you’ll also need to grant permissions to the Service Account depending on the segment where you want it to be used. You can read more about segment-based permission assignment at the following [link](https://docs.applivery.com/en/device-management/general-settings/segments/#how-to-create-segments-and-permissions). ::: The Service Account details will be displayed: | Field | Description | | --- | --- | | **Account** | The Service Account identifier, in the format `{service-account-id}@{organization-id}.iam.applivery.io` | | **Bearer token** | The authentication token used in API requests. | :::warning Copy the Bearer token immediately. For security reasons, Applivery does not display the full token again after you leave this screen. If you lose the token, you will need to delete the Service Account and create a new one. ::: * * * ### Using the Bearer token in API requests Pass the Bearer token in the `Authorization` header of every Workspace API request: ```bash curl 'https://api.applivery.io/v1/organizations/{organizationId}/...' \ -H 'Authorization: Bearer YOUR_SERVICE_ACCOUNT_TOKEN' ``` Replace `YOUR_SERVICE_ACCOUNT_TOKEN` with the token copied during creation, and `{organizationId}` with your organization's identifier. * * * ### Storing the token securely The Bearer token grants Workspace-level access. Treat it like a password: - **Never commit it to source control.** Store it as a secret in your CI/CD platform, secret manager, or environment variable. - **One Service Account per integration.** Create a separate Service Account for each external system (e.g., one for BrowserStack, one for a Workspace automation script). This limits the blast radius if a token is compromised and makes it easy to rotate without affecting other systems. - **Rotate tokens periodically.** Delete and recreate Service Accounts as part of your regular credential rotation policy. **CI/CD platforms — where to store the token:** | Platform | Where to store | | --- | --- | | GitHub Actions | Repository or organization Secret | | Azure Pipelines | Pipeline Variable (secret) | | Bitrise | Secret (Protected toggle enabled) | | Jenkins | Jenkins Credential (Secret text) | * * * ### Managing existing Service Accounts All Service Accounts in your Workspace are listed in the **Service Accounts** section under **Workspace Settings**. From this view, you can: - **View** the account identifier and role for each Service Account. - **Delete** a Service Account to immediately revoke its access. Any system using the deleted account's token will receive `401 Unauthorized` errors on subsequent requests. There is no way to retrieve or regenerate a token for an existing Service Account. If a token needs to be replaced, delete the account and create a new one. * * * ### Where Service Accounts are required The following Applivery features and integrations authenticate using a Service Account Bearer token: | Feature | Reason | | --- | --- | | Workspace API (Organizations API) | All Workspace API endpoints require Service Account authentication. | | BrowserStack App Live integration | App Live connects to your Applivery Workspace using a Service Account Bearer token. | | Cross-app automation scripts | Any script that reads or writes data across multiple Apps needs Workspace-level access. | --- ## Authentication Source: https://docs.applivery.com/en/platform/authentication/ Description: Secure access control in Applivery with SSO (SAML, Okta, Azure AD, Ping Identity), LDAP, and 2FA — centralize User identity management. TL;DR: Authentication secures access control using SSO (SAML, LDAP) and 2FA, centralizing user identity management and enforcing security policies. Key topics: Single Sign-On (SSO), Two-Factor Authentication (2FA), Identity Management, Okta, Azure AD, Ping Identity, SAML, LDAP Authentication controls how Collaborators and store users sign in to Applivery. The platform supports multiple authentication methods: SSO via SAML with providers such as Okta, Azure AD, and Ping Identity; LDAP-based authentication; and two-factor authentication (2FA) for added security. Configure each authentication method for your organization and see how they interact with user provisioning and access control. --- ## Two-Factor Authentication (2FA) Source: https://docs.applivery.com/en/platform/authentication/2fa/ Description: Secure your Applivery account with two-factor authentication (2FA) — enable, configure, and manage 2FA for enhanced access security. TL;DR: Enable two-factor authentication in Applivery to add an extra layer of security to your account using an authenticator app. Key topics: Enabling 2FA, Logging in with 2FA, Disabling 2FA, Authenticator Apps, Applivery, Google Authenticator, Microsoft Authenticator, TOTP, WebAuthn, YubiKey Two-factor authentication adds a second layer of security to your Applivery account. Even if someone gets hold of your password, they can't access your account without also having the one-time code generated on your phone. Once enabled, every login to the Applivery Dashboard or App Store will require both your password and a code from your authenticator app. Applivery uses **TOTP (Time-Based One-Time Password)** — the same standard used by Google, GitHub, and most modern platforms. Any compatible authenticator app will work, including Google Authenticator and Microsoft Authenticator. **Google Authenticator** Available for iOS and Android. **Microsoft Authenticator** Available for iOS and Android. :::tip Once you have TOTP set up, you can also add a hardware security key (fingerprint reader, Windows Hello, or a physical key like YubiKey) as an additional authenticator. This uses [WebAuthn](https://webauthn.io/), the modern standard supported by all major browsers. ::: * * * ### Enabling 2FA Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), go to your **account configuration** from the top dropdown menu, then select **Security** from the left-hand menu. Click **Enable 2FA** to start the setup. Open your authenticator app and scan the QR code shown on screen. If you can't scan the QR code, tap the option to enter a code manually — Applivery will show the alphanumeric key you can type in directly. Your authenticator app will create a new entry called _Applivery:_ [_your@email.com_](mailto:your@email.com) and start generating 6-digit codes that refresh every 30 seconds. Enter the current code from your App into the confirmation field on screen and click **Enable** before the code expires. A confirmation message will appear once 2FA is active on your account. ![enable 2fa](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/451971e7-6b2b-4faf-8c3b-51e744ec240b.png) :::info Applivery sends an email notification whenever a security change is made to your account — including enabling or disabling 2FA. If you receive one of these emails unexpectedly, change your password immediately and contact support at [support@applivery.com](mailto:support@applivery.com). ::: * * * ### Logging in with 2FA After enabling 2FA, every login will have a second step. Once you enter your email and password, Applivery will prompt you for a one-time code. Open your authenticator app, copy the current 6-digit code for the Applivery entry, and enter it before it expires. ![request 2fa](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/cccf0347-02bc-4a1d-a851-09f50896f919.png) * * * ### Disabling 2FA :::warning We strongly recommend keeping 2FA active at all times. Disabling it reduces the security of your account. ::: If you need to disable 2FA, go to your **account configuration** from the top dropdown menu, then select **Security** from the left-hand menu, and click **Disable** next to Two Factor Authentication. For security reasons, Applivery will ask you to confirm your current password before the change takes effect. ![disable 2fa](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/03b7d218-d840-4e70-9f90-1b79b18d2e06.png) --- ## SSO Source: https://docs.applivery.com/en/platform/authentication/sso/ Description: SSO in Applivery — SAML, LDAP, and SCIM for secure, simplified identity management with user data variables for automation. TL;DR: SSO streamlines authentication through your organization's identity provider. Supports SAML, LDAP, and SCIM, plus user data variables for automation. Key topics: SSO, SAML, LDAP, Identity Providers, SCIM, SSO Variables, Authentication, Okta, Azure AD, Ping Identity Single Sign-On (SSO) lets your team authenticate to Applivery using your organization's existing identity provider, eliminating the need for separate credentials. Applivery supports multiple SSO methods to fit different organizational setups and identity infrastructure. ### Supported SSO methods Google Authentication is enabled by default on all Applivery accounts and requires no additional configuration. **SAML 2.0** Integrates with enterprise identity providers like Azure AD, Okta, Ping Identity, and any other SAML 2.0-compatible platform for centralized authentication and automated user provisioning via SCIM. **LDAP** Connects your existing LDAP directory server to Applivery, enabling authentication and user management directly from your corporate directory. ### SSO user data variables When SSO is configured, the identity provider shares user data that you can reference using template variables. These are useful for automating form fields and populating values during device enrollment or account creation workflows. | Variable | Description | |---|---| | `{{sso.firstname}}` | User's first name | | `{{sso.lastname}}` | User's last name | | `{{sso.username}}` | User's username | | `{{sso.email}}` | Full email address | | `{{sso.email.username}}` | Username portion of the email address | Variables can be combined to build dynamic values. For example, `{{sso.firstname}}.{{sso.lastname}}` generates a value like `daniel.garcia` — useful for automated account creation in macOS Device Management scenarios. Configure SSO and SCIM for your identity provider of choice, with step-by-step setup guides and role mapping instructions. --- ## SCIM for Azure AD Source: https://docs.applivery.com/en/platform/authentication/sso/azure-ad-scim/ Description: Configure SCIM with Applivery and Microsoft Entra ID for automated User and group provisioning and centralized identity management. TL;DR: Automate user and group provisioning in Applivery with SCIM and Microsoft Entra ID for streamlined identity management. Key topics: SCIM Configuration, Microsoft Entra ID Integration, User Provisioning Automation, Role Mapping, Applivery Portals, SCIM, Applivery, Microsoft Entra ID, SAML :::warning This is a premium feature that may not be available on your current plan. Check availability on the [Applivery pricing page](https://www.applivery.com/pricing/). ::: **System for Cross-domain Identity Management (SCIM)** is an open standard that automates user and group provisioning across cloud services. Rather than managing users manually inside Applivery, SCIM lets Microsoft Entra ID push user and group information automatically — creating, updating, and deactivating users and keeping group memberships in sync without any manual intervention. When combined with SAML SSO, SCIM handles the _provisioning_ side of identity management. SAML authenticates users when they log in, while SCIM continuously keeps the user directory and group structure in Applivery up to date. Crucially, **SCIM group management is fully independent of SAML** — groups pushed via SCIM exist in Applivery as first-class objects before any user ever logs in, and they don't require any additional group configuration on the SAML side. :::tip SCIM works on top of an existing SAML SSO integration. If you haven't set that up yet, start with the [Single Sign-On with Azure AD](https://docs.applivery.com/en/platform/authentication/sso/azure-ad/) guide first. ::: * * * ### What SCIM manages in Applivery SCIM can manage three types of resources in Applivery, each with different provisioning behavior depending on the portal you configure it for. **Enterprise Store** When SCIM is configured for the **Enterprise Store**, Applivery can automatically create or remove employee accounts in response to changes in Entra ID. When a user is created in Entra ID you can choose to either do nothing or automatically create them as an employee. When they are deactivated, you can choose to either do nothing or remove them from Applivery. **Dashboard** When SCIM is configured for the **Dashboard**, Applivery manages Collaborator accounts. When a user is created in Entra ID you can choose to either do nothing or create them as a Collaborator with a default role (Admin, Developer/Editor, or Viewer). When they are deactivated, you can do nothing or remove them as a Collaborator. The initial role assigned on creation can be overridden by group-based role mapping — see [Role mapping](#role-mapping) below. **MDM Portal** When SCIM is configured for the **MDM Portal**, Applivery offers the most granular deactivation options. When a user is created in Entra ID, you can do nothing or create them as an MDM employee. When they are deactivated, you have five options: do nothing, unassign the user from their Devices, change the Policy of their assigned Devices, remove the user, or remove the user and all their associated Devices. * * * ### Setting up SCIM **Enable SCIM in Applivery** In the Applivery Dashboard, go to your \*\*Workspace Settings from the top dropdown menu, then open **Login providers** in the left-hand menu. Find the **SAML** row and click **Configure** for the portal you want to protect — **Dashboard**, **App Store**, or **MDM Portal**. Scroll to the bottom of the SAML configuration screen and click **Enable SCIM**. Applivery will generate a **Base URL** and **Bearer Token**. Copy both — you'll need them when configuring Entra ID. The provisioning behavior options (what happens when a user is created or deactivated) are also available here, specific to the portal you selected. **Register an Enterprise Application in Entra ID** In the [Microsoft Entra admin center](https://entra.microsoft.com), follow the steps described [here](https://docs.applivery.com/en/platform/authentication/sso/azure-ad/) to create your new application. **Configure the SCIM connection** Inside the newly created application, open the **Provisioning** section and click **Get started**. Set the **Provisioning Mode** to **Automatic**, then fill in the Admin Credentials: | Field | Value | | --- | --- | | **Tenant URL** | The Base URL generated by Applivery. | | **Secret Token** | The Bearer Token generated by Applivery. | ![provisioning scim](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/80f3196d-8aef-445d-b7ab-7c67bb9a7409.png) Click **Test Connection** to verify the credentials are correct, then click **Save**. If the test fails, double-check that the SCIM endpoint is enabled in Applivery and that the token hasn't been regenerated since you copied it. **Configure provisioning scope and activate** After saving the credentials, return to the provisioning settings and set **Scope** to **Sync only assigned users and groups** — this ensures Entra ID only pushes users and groups that are explicitly assigned to this application, rather than your entire directory. Then toggle **Provisioning Status** to **On**. ![scope and settings](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/8cf9c064-eb8f-4e1a-820a-ff6ecee15edf.png) **Create users and groups in Entra ID** If the users and groups you want to provision don't exist yet in Entra ID, create them now. To create a user, go to **Users → New user → Create new user**, fill in the required fields, and click **Review + create**. To create a group, go to **Groups → New group**, give it a name and description, and click **Create**. Once the group exists, open it, navigate to **Members → Add members**, search for the users you want to include, and confirm. If your users and groups already exist in Entra ID, you can skip this step. **Assign users and groups to the SCIM application** Entra ID only provisions users and groups that are explicitly assigned to the application. Go to **Enterprise applications → your SCIM app → Users and groups,** and click **Add user/group**. Search for and select the groups (or individual users) you want to provision into Applivery, then click **Assign**. Once assigned, the next automatic provisioning cycle — which typically runs every 40 minutes — will sync the selected users and groups to Applivery. :::tip Assigning groups is generally preferable to assigning individual users. When a group is assigned, all its members are provisioned automatically, and any future membership changes in Entra ID are reflected in Applivery on the next sync cycle. ::: * * * ### Provision on demand Instead of waiting for the scheduled sync cycle, you can push changes to Applivery immediately using **Provision on demand**. This is especially useful when onboarding new users or testing your provisioning configuration without waiting up to 40 minutes for the next automatic window. Go to **Enterprise applications → your SCIM app → Provisioning → Provision on demand**. Search for the user or group you want to sync immediately and select it, then click **Provision**. :::warning When provisioning a group on demand, Entra ID requires you to also select the group's individual members explicitly — they appear listed under **View members only** in the selection UI. Simply selecting the group alone is not sufficient for the on-demand flow; the scheduled provisioning cycle handles this automatically. ::: * * * ### Role mapping When SCIM is configured for the **Dashboard**, you can map Entra ID groups to Applivery Collaborator roles. If a user is being provisioned for the first time — meaning they don't yet exist in Applivery — their role is determined by the groups they belong to in Entra ID: | Entra ID group name | Applivery role | | --- | --- | | `applivery-admin` | Admin | | `applivery-editor` | Developer / Editor | | `applivery-viewer` | Viewer | | `applivery-unassigned` | Unassigned | If a user belongs to more than one of these groups, the highest-privilege role takes precedence. If the user doesn't belong to any of these groups, they are created without a role, and an admin will need to assign one manually. :::info SAML and SCIM role mapping applies only to **App Distribution**. Device Management permissions are governed exclusively by [Segment permissions.](https://docs.applivery.com/en/device-management/general-settings/segments/) ::: --- ## Azure AD Source: https://docs.applivery.com/en/platform/authentication/sso/azure-ad/ Description: Integrate Applivery with Azure AD via SAML for Single Sign-On — configure Microsoft Entra ID as your Identity Provider. TL;DR: Integrate Applivery with Azure AD for Single Sign-On (SSO) using SAML by exchanging metadata and configuring user group mappings. Key topics: Azure AD, SAML, Single Sign-On, Applivery Integration, Azure Security Groups, Applivery, Microsoft Entra ID, Microsoft 365 :::warning This is a premium feature that may not be available on your current plan. Check availability on the [Applivery pricing page](https://www.applivery.com/pricing/). ::: Once set up, your organization members can log in to the Applivery Dashboard, App Store, or MDM Portal using their Microsoft 365 credentials — no separate Applivery password needed. The flow goes in two directions: first, you export the Service Provider metadata from Applivery and import it into Entra ID, then you export the Identity Provider metadata from Entra ID and import it back into Applivery. Azure Security Group mapping — which has a unique quirk compared to other IdPs — is covered at the end. :::info If you plan to use a custom domain for your App Store or MDM Portal, configure it in Applivery **before** setting up SSO. Custom domains change the callback URLs embedded in the SAML metadata, so the order matters. ::: * * * ### Prerequisites You'll need administrator access to your Applivery Workspace, and Global Administrator or Application Administrator access to the [Microsoft Entra admin center](https://entra.microsoft.com/). If you are using a custom domain, make sure it is configured first in Applivery under the Settings section, then navigate to Store Customization from the left-hand menu. * * * ### Setup **Get the Service Provider metadata from Applivery** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), go to your **Workspace Settings** from the top dropdown menu, then open Login providers in the left-hand menu. Find the **SAML** row and click **Configure** for the portal you want to protect — **Dashboard**, **App Store**, or **MDM Portal**. Each portal is configured independently. On the SAML configuration screen, you have two options depending on your Entra ID setup: **Upload metadata file (recommended)** Click **Download Metadata** to get the **SAML Metadata XML** file. This is the fastest option — uploading it to Entra ID will fill in all required fields automatically. **Manual configuration** If your Entra ID tenant doesn't support metadata upload, use the individual values shown on screen: | Field | Description | | --- | --- | | **Identifier (Entity ID)** | The unique identifier for Applivery as a Service Provider. | | **Reply URL (ACS URL)** | Where Entra ID will POST the SAML response after authentication. | | **Callback URL** | The URL users land on after a successful login. | **Create an Enterprise Application in Entra ID** In the [Azure Portal](https://portal.azure.com/), go to **Microsoft Entra ID → Enterprise applications** and click **\+ New application**. ![microsoft entra id](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/5f8e775e-a1c1-4d91-a9f9-341dbc9fd2fe.png) Select **Create your own application**, give it a name (e.g. `Applivery`), choose **Integrate any other application you don't find in the gallery (Non-gallery)**, and click **Create**. ![create your own app](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/5d29afbf-0d9c-4b94-86d4-732460a05f72.png) **Configure SAML SSO in Entra ID** Inside the application, go to **Setup Single Sign-On** from the left menu and select **SAML**. At the top of the configuration page, click **Upload metadata file** and select the XML file you downloaded from Applivery — the required fields will populate automatically. ![upload metadata file](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/60f0eafe-5aed-460d-b12c-310cd09120ae.png) If you're configuring manually, fill in **Section 1 – Basic SAML Configuration** with the Identifier, Reply URL, and Sign on URL values from Applivery, then click **Save**. **Assign users or groups** Before anyone can log in via SSO, they need to be assigned to the application in Entra ID. Go to **Users and groups** in the left menu, click **\+ Add user/group**, select the users or groups who should have access to Applivery, and click **Assign**. **Download the Identity Provider metadata from Entra ID** Go back to **Single Sign-On** in your application. In **Section 3 – SAML Certificates**, click the **Download** link next to **Federation Metadata XML** and save the file — you'll upload it to Applivery in the next step. ![saml certificates](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/1ebb5e6a-59a4-4793-b904-9bf575eedc49.png) **Complete the configuration in Applivery** Go back to the Applivery SAML configuration screen for the same portal you started with in Step 1. Upload the **Federation Metadata XML** file from Entra ID, click **Save changes**, then use the toggle switch to **enable** the integration. **Test the integration** With everything saved and enabled, test with an assigned user. For the Dashboard, go to [https://dashboard.applivery.io/welcome/sso](https://dashboard.applivery.io/welcome/sso), enter the user's email, and you'll be redirected to Microsoft for authentication. For the App Store or MDM Portal, just navigate to the portal URL — the SSO redirect will happen automatically. * * * ### Azure Security Group mapping Unlike most Identity Providers, **Azure Entra ID does not send group display names in SAML assertions — it sends Object IDs (GUIDs)**. This means that without additional configuration, the groups Applivery receive look like `89f3b2c1-4a7e-4d91-...` rather than `engineering` or `qa-team`. To make groups usable for Publication filters and role mapping, you need to do two things: enable group claims in Entra ID so the assertion includes them, and then map the Object IDs to friendly names in Applivery. #### Enable group claims in Entra ID In your Enterprise Application, go to **Single Sign-On and** edit the **Attributes & Claims configuration**. Then click the **\+ Add a group claim button** and select **Security groups** (or **All groups** if needed), set the **Source attribute** to `Group ID`, and make sure the claim schema is: ``` http://schemas.microsoft.com/ws/2008/06/identity/claims/groups ``` ![user attributes and claims](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/82fccbeb-c237-4493-88db-55b763810b52.png) Save your changes. Entra ID will now include Security Group Object IDs in every SAML assertion. #### Map Object IDs to group names in Applivery In the Applivery Dashboard, go to your **SAML** configuration. For each Azure Security Group, add a mapping entry with the group's **Object ID** as the key and the desired Applivery group name as the value. ![group translation](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/62681408-4af1-47c4-99b8-9a22055247eb.png) You can find Object IDs under **Microsoft Entra ID → Groups** — open each group and copy the **Object ID** field. ![](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/73db51a7-2a6f-4c92-a027-36fde2146ea6.png) :::tip You don't need to pre-configure all groups before going live. Applivery automatically detects new Object IDs as users authenticate and adds them to the mapping list as placeholders. You can assign friendly names at any time after the integration is active. ::: * * * ### Role mapping from Azure groups If you're configuring the Dashboard portal and want Azure Security Groups to automatically assign Applivery Collaborator roles to new users, you need to send group **display names** instead of Object IDs — so Applivery can match them directly to the reserved role group names (`applivery-admin`, `applivery-editor`, etc.). In the **User Attributes & Claims** section of your Entra ID application, edit the group's claim and set the **Source attribute** to **Cloud-only group display names** instead of `Group ID`. With this in place, Applivery can assign roles on first login without needing any Object ID → name mapping. ![group claims](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/cdda8163-d252-4bea-b8da-23a25d19ba3d.webp) :::note Role mapping only applies to **App Distribution**. Device Management permissions are governed exclusively by [Segment permissions](https://docs.applivery.com/en/device-management/general-settings/segments/#segment-based-role-delegation). ::: --- ## LDAP Source: https://docs.applivery.com/en/platform/authentication/sso/ldap/ Description: Integrate Applivery with your LDAP server for secure User authentication across App Distribution and Device Management. TL;DR: Integrate Applivery with your LDAP server to enable secure user authentication for App Distribution and Device Management using existing corporate credentials. Key topics: LDAP Authentication, App Distribution Integration, Device Management Integration, User Group Synchronization, Configuration Steps, Applivery, LDAP, Active Directory, OpenLDAP :::warning This is a premium feature that may not be available on your current plan. Check availability on the [Applivery pricing page](https://www.applivery.com/pricing/). ::: The Lightweight Directory Access Protocol (LDAP) is an open, vendor-neutral application protocol for accessing and managing distributed directory information — most commonly corporate user directories such as Active Directory or OpenLDAP. Integrating Applivery with your LDAP server allows employees to authenticate against your existing directory using their corporate credentials, without needing a separate Applivery account. LDAP authentication applies to **both** Applivery modules: - **App Distribution** — employees authenticate against your LDAP directory when accessing private App Stores. Access can be restricted by LDAP groups to control which users see which Apps. - **Device Management** — end users of managed Devices authenticate against your LDAP directory when the MDM portal requires identity verification, for example, during device enrollment flows that require user authentication. Applivery supports LDAP both with and without SSL (`ldap://` and `ldaps://`). * * * ### How LDAP authentication works The authentication flow is the same regardless of which module the user is accessing: 1. The user reaches an Applivery login prompt — either an App Store domain/subdomain (App Distribution) or the MDM portal (Device Management). 2. They enter their corporate username and password. 3. Applivery sends the credentials to your LDAP server for validation. 4. If authentication succeeds and the user has the required permissions, they are granted access and see only the resources they are authorized for. No Applivery account creation is required for end users — their existing directory credentials are the only login needed. #### App Distribution Users accessing a private App Store are shown only the Publications they are authorized for, based on their LDAP group membership. This is the primary use case for controlling which employees can download which app Builds. #### Device Management Users authenticating through the MDM portal — for example, during enrollment flows or when accessing the employee-facing portal — are validated against your LDAP directory. This allows IT teams to enforce corporate identity verification as part of the Device onboarding process, without requiring a separate Applivery identity for each user. * * * ### Prerequisites Before configuring the integration in Applivery, make sure you have the following information from your LDAP administrator: - The LDAP server address, protocol (`ldap://` or `ldaps://`), and port (typically `389` for LDAP, `636` for LDAPS). - A **Bind DN** — the distinguished name of a service account with read access to your directory. - The **Bind DN password** for that service account. - The **Search base** — the distinguished name of the directory node from which Applivery should search for users (e.g., `ou=people,dc=example,dc=com`). - The **Search filter** — the LDAP attribute that contains the user's login name (e.g., `uid`, `sAMAccountName`). - The **Email field** — the LDAP attribute that contains the user's email address (e.g., `mail`). #### Authorize Applivery's IP address If your LDAP server uses IP allowlisting, you must add the following Applivery IP address to your firewall or LDAP server access rules before users can authenticate: ``` 34.175.89.200 ``` * * * ### Configuration **Add the LDAP login provider** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), go to your Workspace Settings from the top dropdown menu. Then, in the left-hand menu, open Login Providers and select the LDAP option under either the Enterprise Store section or the MDM Portal section. ![ldap](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/5056c374-965a-49aa-b61a-dd0870a4ad38.png) **Configure the connection** These fields control how Applivery connects to and authenticates against your LDAP server: | Field | Description | Example | | --- | --- | --- | | **Server** | The LDAP server URL, including protocol and port. | `ldaps://ldap.example.com:636` | | **Bind DN** | Distinguished name of the service account used to connect to the directory. | `cn=applivery-svc,ou=services,dc=example,dc=com` | | **Bind password** | Password for the Bind DN service account. | — | :::warning The Bind DN account only needs **read access** to the directory. Do not use an account with write permissions. ::: **Configure the directory** These fields control how Applivery searches for users within your LDAP directory: | Field | Description | Example | | --- | --- | --- | | **Search base** | The distinguished name of the directory node where user searches begin. | `ou=people,dc=example,dc=com` | | **Search filter** | The LDAP attribute used as the login identifier. | `uid` (OpenLDAP) or `sAMAccountName` (Active Directory) | | **Email field** | The LDAP attribute containing the user's email address. | `mail` | Click **Save** to activate the LDAP integration. ### User Group synchronization Applivery automatically imports your LDAP Organizational Units (OUs) as User Groups. These groups are available across both App Distribution and Device Management for access control purposes. #### How it works - Groups are synchronized every time a user logs in — there is no background sync between logins. - Imported LDAP groups are prefixed with `ldap:` to distinguish them from groups created manually in Applivery (e.g. `ldap:engineering`, `ldap:qa-team`). - All LDAP groups for a user are **fully replaced** on each login. If you add or remove a user from a group in your LDAP directory, the change will be reflected in Applivery the next time that user logs in. #### Using LDAP groups in App Distribution LDAP groups can be used as distribution group filters on private Publications, restricting access to specific App Builds to specific teams or departments — with no manual user management needed in Applivery. To learn more about private Publications and distribution group filters, see [How to Distribute Your Apps](https://docs.applivery.com/en/app-distribution/distribute/distribute-apps/). #### Using LDAP groups in Device Management LDAP groups can also be referenced in Device Management to segment Device Audiences and apply different Policies or configurations to different User Groups. For example, you can apply stricter Policies to one organizational unit and a more permissive configuration to another, all driven by the groups imported from your existing directory. --- ## SCIM for Okta Source: https://docs.applivery.com/en/platform/authentication/sso/okta-scim/ Description: Automate User provisioning with SCIM in Applivery — configure Okta SCIM for seamless User and group management across your organization. TL;DR: Automate user and group provisioning in Applivery with SCIM and Okta for streamlined identity management. Key topics: SCIM Configuration, Okta Integration, User Provisioning, Role Mapping, Attribute Mapping, SCIM, Applivery, Okta, SAML :::warning This is a premium feature that may not be available on your current plan. Check availability on the [Applivery pricing page](https://www.applivery.com/pricing/). ::: **System for Cross-domain Identity Management (SCIM)** is an open standard that automates user and group provisioning across cloud services. Rather than managing users manually inside Applivery, SCIM lets your Identity Provider push user and group information automatically — creating, updating, and deactivating users and keeping group memberships in sync without any manual intervention. When combined with SAML SSO, SCIM handles the _provisioning_ side of identity management. SAML authenticates users when they log in, while SCIM continuously keeps the user directory and group structure in Applivery up to date. Crucially, **SCIM group management is fully independent of SAML** — groups pushed via SCIM exist in Applivery as first-class objects before any user ever logs in, and they don't require any additional group configuration on the SAML side. :::tip SCIM works on top of an existing SAML SSO integration. If you haven't set that up yet, start with the [Single Sign-On with Okta](https://docs.applivery.com/en/platform/authentication/sso/okta-scim/) guide first. ::: * * * ### What SCIM manages in Applivery SCIM can manage three types of resources in Applivery, each with different provisioning behavior depending on the portal you configure it for. **Enterprise Store** When SCIM is configured for the **Enterprise Store**, Applivery can automatically create or remove employee accounts in response to changes in Okta. When a user is created in Okta, you can choose to either do nothing or automatically create them as an employee. When they are deactivated, you can choose to either do nothing or remove them from Applivery. **Dashboard** When SCIM is configured for the **Dashboard**, Applivery manages Collaborator accounts. When a user is created in Okta, you can choose to either do nothing or create them as a Collaborator with a default role (Admin, Developer/Editor, or Viewer). When they are deactivated, you can do nothing or remove them as a Collaborator. The initial role assigned on creation can be overridden by group-based role mapping — see [Role mapping](#role-mapping) below. **MDM Portal** When SCIM is configured for the **MDM Portal**, Applivery offers the most granular deactivation options. When a user is created in Okta you can do nothing or create them as an MDM employee. When they are deactivated, you have five options: do nothing, unassign the user from their Devices, change the Policy of their assigned Devices, remove the user, or remove the user and all their associated Devices. * * * ### Setting up SCIM There are two ways to configure SCIM with Okta. The **native approach** — recommended — adds SCIM directly to your existing Applivery SAML application in Okta, keeping SSO and provisioning together in a single app. A **separate app approach** using a standalone SCIM app from the Okta catalog is also available as a fallback. **Enable SCIM in Applivery** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), go to your **Workspace Settings** from the top dropdown menu, then open **Login providers** in the left-hand menu. Find the **SAML** row and click **Configure** for the portal you want to protect — **Dashboard**, **App Store**, or **MDM Portal**. Scroll to the bottom of the SAML configuration screen and click **Enable SCIM**. Applivery will generate a **Base URL** and **Bearer Token**. Copy both — you'll need them in Okta. The provisioning behavior options (what happens when a user is created or deactivated) are also available here, specific to the portal you selected. **Enable SCIM on your existing Okta SAML application** In the [Okta Admin Portal](https://www.okta.com/), open the **Applivery SAML application** you already have configured. Go to the **General** tab, find the **App Settings** section, and click **Edit**. Under **Provisioning**, select **SCIM** and click **Save**. A new **Provisioning** tab will appear in the application. ![provisioning scim](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/d7936ff3-e525-4814-94bc-a4014787257d.png) :::info The SCIM option under App Settings may not be available in all Okta plans. If it doesn't appear, contact Okta support to have it enabled for your organization, or use a [separate Okta SCIM app](#alternative-separate-okta-scim-app). ::: **Configure the SCIM connection** Go to the **Provisioning** tab and select **Integration** from the left sidebar. Click **Edit** and fill in the connection details: | Field | Value | | --- | --- | | **SCIM connector base URL** | The Base URL generated by Applivery in Step 1 | | **Unique identifier field for users** | `email` | | **Supported provisioning actions** | **Push New Users**, **Push Profile Updates**, **Push Groups** | | **Authentication Mode** | HTTP Header | | **Authorization** (Bearer token) | The Bearer Token generated by Applivery in Step 1 | Click **Test Connector Configuration** to verify. If the test passes, click **Save**. **Enable provisioning actions** Still in the **Provisioning** tab, select **To App** from the left sidebar and click **Edit**. Enable **Create Users**, **Update User Attributes**, and **Deactivate Users**, then save. **Push groups to Applivery** Go to the **Push Groups** tab at the top of the Provisioning section. Click **Push Groups → Find groups by name**, search for the Okta groups you want to sync to Applivery, select each one, and click **Save**. Add more groups by clicking **Save & Add Another**. When a group is pushed, Okta sends both the group object and its members to Applivery. These groups are immediately available in Applivery for Publication filters, role mapping, and access control — no additional SAML configuration needed. :::tip Okta does not support using the same group for both **Assignments** and **Push Groups**. If you run into syncing issues, use separate groups for assigning users to the App and for pushing groups to Applivery. ::: * * * ### Role mapping When SCIM is configured for the **Dashboard**, you can map Okta groups to Applivery Collaborator roles. If a user is being provisioned for the first time — meaning they don't yet exist in Applivery — their role is determined by the groups they belong to in Okta: | Okta group | Applivery role | | --- | --- | | `applivery-admin` | Admin | | `applivery-editor` | Developer / Editor | | `applivery-viewer` | Viewer | | `applivery-unassigned` | Unassigned | If a user belongs to more than one of these groups, the highest-privilege role takes precedence. :::info Role mapping applies only to **App Distribution**. Device Management permissions are governed exclusively by [Segment permissions](https://docs.applivery.com/en/device-management/general-settings/segments/#segment-based-role-delegation). ::: * * * ### Attribute mapping Beyond user creation and group sync, SCIM can also push custom user attributes from Okta into the `metadata` field of the corresponding user object in Applivery. This is useful for storing department, cost center, employee ID, or any other custom field from your directory. See the full guide in [SCIM Attribute Mapping](https://docs.applivery.com/en/device-management/integrations/sso/scim-attributes-mapping/). * * * ### Alternative: separate Okta SCIM app If enabling SCIM directly on your SAML application is not available in your Okta plan, you can configure provisioning using a standalone SCIM app from the Okta catalog. This approach uses two separate Okta applications — one for SAML SSO and one for SCIM provisioning. #### Configure provisioning with a separate SCIM app In the Okta Admin Portal, go to **Applications** (inside Applications) and click **Browse App Catalog**. ![browse app catalog](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/bf96f00e-00d4-4a67-a7b2-ab06ecb8708d.png) Search for **SCIM 2.0 Test App (OAuth Bearer Token)**, select the first result, and click **\+ Add integration**. Give it a label (e.g., `Applivery SCIM`) and complete the general settings, then click **Done**. ![add scim integration](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ab357246-9b63-4620-9881-d20cd2b1fef9.png) Inside the new App, go to the **Provisioning** tab and click **Configure API Integration**. Enter the **Base URL** and **Bearer Token** from Applivery (Step 1 of the main guide). Click **Test API Credentials** — Okta will send a GET request to Applivery to verify the connection. If it passes, click **Save**. ![enable scim integration](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/35924cea-4213-4e30-9632-405e45f9968d.png) Still in Provisioning, click **Edit** under **Provisioning to App** and enable **Create Users**, **Update User Attributes**, and **Deactivate Users**. To sync groups, go to the **Assignments** tab, select **Groups** from the sidebar, click **Assign → Assign to Groups**, and select the Okta groups you want to provision into Applivery. --- ## Okta Source: https://docs.applivery.com/en/platform/authentication/sso/okta/ Description: Enable Okta SAML SSO for Applivery — connect your Dashboard, App Store, and MDM Portal using Okta credentials. TL;DR: Configure Applivery SSO with Okta SAML by creating a SAML application in Okta and uploading the metadata to Applivery, enabling users to log in with their Okta credentials. Key topics: SAML configuration, Okta application setup, Applivery SSO integration, Identity Provider metadata, Applivery, Okta, SAML, Service Provider, Identity Provider :::warning This is a premium feature that may not be available on your current plan. Check availability on the [Applivery pricing page](https://www.applivery.com/pricing/). ::: Once configured, your organization members will be able to log in to the Applivery Dashboard, App Store, or MDM Portal using their Okta credentials — no separate Applivery password required. :::warning Okta does not support metadata file upload. Unlike other Identity Providers, Okta does not allow importing the Applivery pre-configured SAML Metadata XML file. You must configure the SAML application in Okta manually using the values provided in the Applivery Dashboard. ::: :::info If you plan to use a custom domain for your App Store or MDM Portal, configure it in Applivery **before** setting up SSO. Custom domains change the callback URLs, so the order matters. ::: * * * ### Prerequisites - Administrator access to your Applivery Workspace. - Administrator access to your [Okta Admin Portal](https://www.okta.com/). - Your Applivery **organization slug** — visible in the URL when logged into the Applivery Dashboard (e.g., `demo` in `https://dashboard.applivery.io/demo/...`). - If you are using a custom domain, make sure it is configured first in Applivery under the Settings section, then navigate to Store Customization from the left-hand menu. * * * **Get the Service Provider values from Applivery** Applivery acts as the SAML **Service Provider (SP)**. Since Okta requires manual entry, you need to collect two specific values from the Applivery SAML configuration screen. Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), go to your **Workspace Settings** from the top dropdown menu, then open Login providers in the left-hand menu. Find the **SAML** row and click **Configure** for the portal you want to protect — **Dashboard**, **App Store**, or **MDM Portal**. ![login providers](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/7756cdbd-a769-4464-a458-6d957e34ff73.png) Copy the following values: ##### Values by portal type **Dashboard** | Field | Value | | --- | --- | | **Single Sign-On URL (Callback URL)** | `https://dashboard.applivery.io/welcome/sso/{organization_slug}` | | **Audience URI (SP Entity ID)** | `https://dashboard.applivery.com/sso/{organization_slug}/metadata.xml` | **App Store (Enterprise Store)** | Field | Value | | --- | --- | | **Single Sign-On URL (Callback URL)** | Your App Store URL: `{organization_slug}.applivery.io` or your custom domain `you.yourcompany.com` | | **Audience URI (SP Entity ID)** | `https://dashboard.applivery.com/sso/{organization_slug}/metadata.xml` | **MDM Portal** | Field | Value | | --- | --- | | **Single Sign-On URL (Callback URL)** | `https://mdm-portal.applivery.io/login/{organization_id}` | | **Audience URI (SP Entity ID)** | `https://dashboard.applivery.com/sso/{organization_slug}/metadata.xml` | Replace `{organization_slug}` and `{organization_id}` with your actual values, visible in the Applivery SAML configuration screen. **Create a SAML application in Okta** ##### Create a new App Integration Log in to your [Okta Admin Portal](https://www.okta.com/), go to **Applications** (inside Applications), and click the **Create App Integration** button. ![create app integration](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/6c523c0f-2dc0-433f-be3c-6129455f9e6f.png) Select **SAML 2.0** as the sign-on method, then click **Next**. ##### General settings Enter a name for the application (e.g., `Applivery`), and optionally upload a logo for easy identification. Then click **Next**. ![general settings](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/8f131921-9567-4603-ac2d-fc35b86c9b5f.png) ##### Configure SAML settings Fill in the following fields on the SAML configuration screen: | Field | Value | | --- | --- | | **Single sign-on URL** | The Callback URL for your portal from Step 1 | | **Audience URI (SP Entity ID)** | The Entity ID for your portal from Step 1 | | **Name ID format** | `EmailAddress` | | **Application username** | `Email` | ![saml settings](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/43e3bad4-a697-4fc7-8674-85b93d0a3f50.png) Leave all other fields at their default values. :::warning The **Single sign-on URL** field must contain the **Callback URL** (not the general login URL). For example, for the Dashboard portal: `https://dashboard.applivery.io/welcome/sso/demo`. ::: Click **Next** when done. ##### Configure Group Attribute Statements To enable Okta groups to be sent to Applivery (required for distribution group filtering and role mapping), you need to configure a **Group Attribute Statement**. Scroll down to the **Group Attribute Statements** section. If it is collapsed, click **Show Legacy Configuration → Edit**. Add a group claim with the following settings: | Field | Value | | --- | --- | | **Name** | `http://schemas.microsoft.com/ws/2008/06/identity/claims/groups` | | **Name format** | `URI Reference` | | **Filter** | See filter options below | **Filter options** — choose based on your needs: | Option | When to use | | --- | --- | | **Starts with** + a prefix | Send only groups whose names begin with a specific prefix. Useful for scoping which Okta groups are synced to Applivery. | | **Matches regex** `.*` | Send all Okta groups the user belongs to. | | **Regex** with a specific pattern | Send only groups matching a custom regular expression. | ![group attribute statement](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/be3b5ea8-bae5-4823-982e-338b64f1ad6f.png) Click **Save** to apply the attribute statement. ##### Complete the application setup Finish the Okta wizard (click **Next** through any remaining steps). Okta will confirm the application has been created. **Get the Identity Provider metadata from Okta** Applivery needs Okta's Identity Provider metadata to validate incoming SAML assertions. Inside the newly created application in Okta, go to the **Sign On** tab, click **View SAML Setup Instructions**. Next, scroll to the bottom of the page and locate the **Identity Provider metadata** section. Copy the full XML content and save it as a `.xml` file (e.g., `okta-metadata.xml`). ![view saml setup instructions](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/a5b18fc1-7639-4405-b5c4-45b6651c484e.png) **Complete the configuration in Applivery** Go back to the Applivery SAML configuration screen for the same portal you started with in Step 1. Under **Step 2** of the Applivery SAML form, upload the **Federation Metadata XML** file you saved from Okta and click **Save**. Use the **toggle switch** to **enable** the SAML integration for your organization. **Assign users in Okta** Before users can authenticate via SSO, they must be assigned to the Applivery application in Okta. In your Okta application, go to the **Assignments** tab. Click **Assign** and select **Assign to People** or **Assign to Groups,** depending on your preferred access management approach. Assign the users or groups who should have access to Applivery and click **Done**. ![assignments](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/269956c4-cd2f-469f-bafe-cea22810564a.png) :::warning Users who are not assigned to the application in Okta will not be able to log in via SSO, even if the integration is correctly configured. ::: **Test the integration** Once both sides are configured and enabled, test with an assigned user: - **Dashboard:** Go to [https://dashboard.applivery.io/welcome/sso](https://dashboard.applivery.io/welcome/sso) and enter the user's email. You will be redirected to Okta for authentication. - **App Store / MDM Portal:** Navigate to your App Store or MDM Portal URL. Users with SAML configured will be redirected to Okta for authentication before accessing the portal. If authentication fails, double-check that the **Single Sign-On URL** in Okta exactly matches the Callback URL from Applivery (including the organization slug), and that the user is assigned to the application in Okta. --- ## Ping Identity Source: https://docs.applivery.com/en/platform/authentication/sso/ping-identity/ Description: Configure Applivery SSO using Ping Identity — covers setup, attribute mapping, and testing the integration end to end. TL;DR: Configure Applivery SSO with Ping Identity by exchanging SAML metadata, mapping attributes, and enabling the integration for secure user authentication. Key topics: SAML Configuration, Ping Identity Setup, Applivery Configuration, Attribute Mapping, SSO Testing, Applivery, Ping Identity, SAML :::warning This is a premium feature that may not be available on your current plan. Check availability on the [Applivery pricing page](https://www.applivery.com/pricing/). ::: The setup involves two sides: first, you collect the Service Provider metadata from Applivery, then you configure a SAML application in Ping Identity, and finally, you complete the configuration back in Applivery with the Identity Provider metadata. :::info If you plan to use a custom domain for your App Store or MDM Portal, configure it in Applivery **before** setting up SSO. Custom domains change the callback URLs in the SAML metadata, so the order matters. ::: * * * ### Prerequisites - Administrator access to your Applivery Workspace. - Administrator access to your [Ping Identity console](https://www.pingidentity.com/). - If you are using a custom domain, make sure it is configured first in Applivery under the Settings section, then navigate to Store Customization from the left-hand menu. * * * **Get the Service Provider metadata from Applivery** Applivery acts as the SAML **Service Provider (SP)**. The first step is to collect its metadata to import into Ping Identity. Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), go to your **Workspace Settings** from the top dropdown menu, then open Login providers in the left-hand menu. Find the **SAML** row and click **Configure** for the portal you want to protect — **Dashboard**, **App Store**, or **MDM Portal**. :::tip It’s generally recommended to set up each portal separately, using a dedicated Ping Identity application per portal, since the User Groups and access requirements typically differ across them. ::: ![login providers](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/487bb3c8-9552-4eff-9a0c-a0208d3bc46e.png) Once selected, download the **SAML metadata XML** from step 1 and keep it at hand — you will upload it to Ping Identity in the next step. **Configure a SAML application in Ping Identity** **Create the application** Log in to your [Ping Identity console](https://www.pingidentity.com/), then navigate to Applications and click the **+** 1 button at the top of the page to create a new application. Provide a descriptive name (for example, Applivery) and select SAML Application 2 as the application type. ![ping create application](https://www.applivery.com/wp-content/uploads/2024/10/Screenshot-2024-10-24-at-091737-1024x651.png "Screenshot 2024-10-24 at 091737 | Applivery") Click Configure, then in the SAML configuration dialog, choose Import Metadata and upload the SAML Metadata XML file downloaded from Applivery in step 1. Finally, click Save to complete the setup. ![upload metadata to ping](https://www.applivery.com/wp-content/uploads/2024/10/Screenshot-2024-10-24-at-092742-1024x651.png "upload-metadata-to-ping | Applivery") **Enable the application** Once the application is created, locate it in the Applications list and **enable the toggle switch** to activate it. The application must be enabled for SSO to work. ![enable ping application](https://www.applivery.com/wp-content/uploads/2024/10/Screenshot-2024-10-24-at-095406-1024x651.png "enable-ping-application | Applivery") **Configure attribute mappings** Applivery requires specific SAML attributes to identify users and assign group memberships. Go to the **Attribute Mapping** tab of your new application and click the pencil icon to edit. Add the following four mappings: | Applivery attribute | PingOne mapping | Notes | | --- | --- | --- | | `saml_subject` | Email Address | The primary user identifier. Required. | | `firstName` | Given Name | User's first name. | | `lastName` | Family Name | User's last name. | | `groups` | Group Names | Used to sync Ping Identity groups into Applivery for access control. | **For each mapping**: type the attribute name in the left field, select the corresponding PingOne mapping from the dropdown, and click **\+ Add**. Once all four are added, click **Save**. ![ping attribute mappings](https://www.applivery.com/wp-content/uploads/2024/10/Screenshot-2024-10-24-at-100847-1024x651.png "ping-attribute-mappings | Applivery") **Set the signing option** Go to the **Configuration** tab and click the pencil icon to edit. Under signing options, select **Sign Assertion & Response**. This ensures both the SAML assertion and the response envelope are signed, which Applivery requires. Click **Save** to apply. **Download the Identity Provider metadata** Still on the **Configuration** tab, click **Download Metadata** to download the **Federation Metadata XML** file from Ping Identity. This file contains the Identity Provider information (issuer URL, signing certificate, SSO endpoint) that Applivery needs to validate incoming SAML assertions. ![download ping metadata](https://www.applivery.com/wp-content/uploads/2024/10/Screenshot-2024-10-24-at-102857-1024x651.png "download-ping-metadata | Applivery") **Complete the configuration in Applivery** Go back to the Applivery Dashboard. Under **Step 2** of the SAML form, upload the **Federation Metadata XML** file you downloaded from Ping Identity. Configure the attribute mappings to match what you set in Ping Identity under step 4: - **First name attribute:** `firstName`. - **Last name attribute:** `lastName`. - **Group’s attribute:** `groups`. Click **Save** and use the **toggle switch** to **enable** the SAML integration for your organization. ![ping mapping](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/808b4d6e-947a-4177-b2a1-b11c7225aecd.png) **Assign users in Ping Identity** Before users can log in via SSO, they must be assigned to the Applivery application in Ping Identity. Go to **Directory → Users** in your Ping Identity console and assign the users or groups who should have access to Applivery. **Test the integration** Once both sides are configured and the integration is enabled, test it with an assigned user: - **Dashboard:** Go to [https://dashboard.applivery.io/welcome/sso](https://dashboard.applivery.io/welcome/sso) and enter the user's email. You will be redirected to Ping Identity for authentication. - **App Store / MDM Portal:** Navigate to your App Store or MDM Portal URL. Users with SAML configured will be redirected to Ping Identity for authentication before accessing the portal. If authentication fails, verify that the attribute names in Applivery match exactly those configured in Ping Identity's attribute mapping (case-sensitive), and that the **Sign Assertion & Response** option is set correctly in Ping Identity. --- ## SAML Source: https://docs.applivery.com/en/platform/authentication/sso/saml/ Description: Enable SSO for Applivery using SAML 2.0 — integrate with Okta, Azure AD, Ping Identity, and more, with attribute and group mapping. TL;DR: Configure SAML SSO for Applivery to enable secure authentication through your existing Identity Provider, simplifying user access and management. Key topics: SAML SSO configuration, Identity Provider integration, Attribute mapping, Group mapping, Role mapping, Applivery, SAML 2.0, Okta, Azure AD, Ping Identity, Microsoft Entra ID, Auth0 :::warning This is a premium feature that may not be available on your current plan. Check availability on the [Applivery pricing page](https://www.applivery.com/pricing/). ::: SAML 2.0 (Security Assertion Markup Language) is the industry standard for web-based Single Sign-On. It allows your Identity Provider (IdP) — such as Okta, Azure AD, or Ping Identity — to handle authentication, while Applivery trusts the result and grants access without ever handling your users' passwords. Once configured, users who visit a protected Applivery portal are redirected to your IdP's login page. After authenticating there, the IdP sends a signed SAML assertion back to Applivery confirming the user's identity and group memberships. Applivery validates the assertion and lets the user in — no separate Applivery password needed. SAML SSO can be configured independently for each of the three Applivery portals: - **Dashboard** — access for Collaborators (developers, admins, viewers) managing Apps and Policies. - **App Store (Enterprise Store)** — access for store employees downloading internal app Builds. - **MDM Portal** — access for device users authenticating during enrollment or portal access. * * * ### Supported Identity Providers Applivery supports any SAML 2.0 compliant Identity Provider. Step-by-step setup guides are available for the most common ones: **Azure AD (Microsoft Entra ID)** Includes Security Group mapping and role assignment. **Okta** Includes group attribute configuration and SCIM provisioning. **Ping Identity** Includes attribute mapping and federation metadata exchange. :::tip If your IdP is not listed above, you can still configure SAML SSO as long as it supports SAML 2.0. The general flow — exchanging SP metadata from Applivery, configuring the IdP, uploading the IdP's Federation Metadata XML back into Applivery — is the same for all providers. ::: * * * ### Authentication flow When a user accesses a SAML-protected Applivery portal, the flow works as follows: The user visits your App Store domain, Dashboard, or MDM Portal and clicks **Login**. Applivery redirects them to your Identity Provider's login page, where they authenticate using their corporate credentials. Once authenticated, the IdP sends a signed SAML Response to Applivery's callback endpoint. Applivery validates the signature, extracts the user's identity and group information from the assertion, and grants access — showing only the Apps and resources the user is authorized to see. * * * ### Attribute mapping Applivery reads user identity from specific attributes in the SAML assertion. The exact attribute name varies depending on the Identity Provider. You can override the defaults in the SAML configuration screen under **Attribute Mapping** — leave a field blank to use the default value for the detected IdP. #### Email The email address is the primary user identifier. Applivery looks for it in the following locations, in order: | IdP | Attribute | | --- | --- | | Standard (default) | `nameID` | | Azure AD | `EmailAddress` (`http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress`) | | Auth0 | `http://schemas.auth0.com/email` | #### First name | IdP | Attribute | | --- | --- | | Standard (default) | `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname` | | Azure AD | `http://schemas.microsoft.com/identity/claims/displayname` | | Auth0 | `http://schemas.auth0.com/given_name` | #### Last name | IdP | Attribute | | --- | --- | | Standard (default) | `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname` | | Azure AD | `http://schemas.microsoft.com/identity/claims/displayname` | | Auth0 | `http://schemas.auth0.com/family_name` | #### User Groups Groups from your IdP are used for access control in Applivery — controlling which users see which Publications, and assigning Dashboard roles. Applivery reads groups from: | IdP | Attribute | | --- | --- | | Standard (default) | `http://schemas.xmlsoap.org/claims/Group` | | Azure AD | `http://schemas.microsoft.com/ws/2008/06/identity/claims/groups` | | Okta | `http://schemas.microsoft.com/ws/2008/06/identity/claims/groups` (configured via Group Attribute Statement) | * * * ### Group mapping Some Identity Providers — notably Azure AD — don't send group display names in SAML assertions. Instead, they send opaque identifiers (Object IDs in Azure's case). Applivery's group mapping feature lets you translate these IDs to human-readable group names. You can configure key/value mappings in your SAML configuration in the [**Applivery Dashboard**](https://dashboard.applivery.io/), under Group Mapping. Applivery will also automatically discover new group values as users authenticate and add them to the list — you can then assign names to them without needing to pre-configure every group upfront. ![group translation](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/77dbb6fe-4d7d-443c-a18d-260855c5f24f.png) For a detailed walkthrough specific to Azure AD, see [Single Sign-On with Azure AD — Security Group mapping](https://docs.applivery.com/en/platform/authentication/sso/azure-ad/). * * * ### Role mapping from SSO When SAML is configured for the **Dashboard**, Applivery can automatically assign a Collaborator role to new users based on the groups sent in their SAML assertion. :::info This applies only on first login — if the user already exists in Applivery, their existing role is not changed. ::: The role is determined by which of the following reserved group names the user belongs to in their IdP: | Group name | Applivery role assigned | | --- | --- | | `applivery-admin` | Admin | | `applivery-editor` | Developer / Editor | | `applivery-viewer` | Viewer | | `applivery-unassigned` | Unassigned | If a user belongs to more than one of these groups, the highest-privilege role takes precedence. If the user doesn't belong to any of these groups, they are created without a role assignment and an admin will need to assign one manually. :::tip Role mapping also works in combination with Group Mapping. If your IdP sends Object IDs instead of display names, you can map the Object IDs to the reserved group names (`applivery-admin`, etc.) in the Group Mapping settings, and role assignment will work correctly. ::: :::info Role mapping only applies to **App Distribution**. Device Management permissions are governed exclusively by [Segment permissions](https://docs.applivery.com/en/device-management/general-settings/segments/). ::: --- ## Organization Source: https://docs.applivery.com/en/platform/organization/ Description: Configure the structural and branding aspects of your Applivery Workspace — custom domains, Workspace settings, and multi-Workspace management. Organization settings let you configure the structural and branding aspects of your Applivery Workspace — including custom domains, Workspace configuration, and multi-Workspace management for organizations with multiple environments. Set up your organization and control how it's presented within the Applivery platform. --- ## Custom Domain Source: https://docs.applivery.com/en/platform/organization/custom-domain/ Description: Brand your Applivery App Store with a custom domain — set up a CNAME record and enable it from the Dashboard. TL;DR: Configure a custom domain for your Applivery App Store by creating a CNAME record and enabling it in the Applivery Dashboard. Key topics: Custom Domain Setup, CNAME Configuration, SSO Considerations, SSL Certificates, Applivery, DNS, CNAME, SAML, Azure AD, Okta, Ping Identity, DigiCert, Google Trust Services, Let's Encrypt, SSL.com By default, your Applivery App Store is accessible at `{your-organization}.applivery.io`. Custom domains let you replace this with a subdomain of your own — for example, `apps.yourcompany.com` — giving employees a branded, recognizable URL when they access internal app Builds. :::info Custom domains apply to the **App Store (Enterprise Store)** only. The Applivery Dashboard and MDM Portal are not affected. ::: * * * ### Setup **Create a CNAME record in your DNS provider** Before configuring anything in Applivery, you need to point your subdomain to Applivery's servers. In your DNS provider, create a new `CNAME` record for the subdomain you want to use: | Type | Name | Value | | --- | --- | --- | | `CNAME` | `Apps` _(your chosen subdomain)_ | `domains.applivery.io` | DNS propagation can take a few minutes to several hours, depending on your provider and TTL settings. You can verify it has propagated using a tool like [dnschecker.org](https://dnschecker.org/) before proceeding. :::tip Custom domains only work with **subdomains** (e.g., `apps.yourcompany.com`). Apex domains (e.g., `yourcompany.com` without a subdomain prefix) are not supported, as they require an A record rather than a CNAME. ::: **Enable the custom domain in Applivery** In the [**Applivery Dashboard**](https://dashboard.applivery.io/), navigate to the **Settings** 1 section and select **Store Customization** 2 from the left-hand menu. Locate the **Custom domain** 3 field, type your subdomain (e.g., `apps.yourcompany.com`), and click **Save**. ![store customization](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/feaade91-affe-47a7-ae39-ebee9b203418.png) Applivery will verify that the CNAME record is correctly configured and activate the custom domain for your App Store. Once active, your employees can access the App Store at the new URL. * * * ### What changes after enabling a custom domain **Your original URL keeps working.** The default `{your-organization}.applivery.io` URL remains active after you enable a custom domain — both URLs work simultaneously. You don't need to communicate a migration deadline to your users. **SSO configuration may need to be updated.** If you have Single Sign-On configured via SAML (Azure AD, Okta, Ping Identity, or any other SAML-based provider), the callback URLs embedded in the SAML metadata will change when a custom domain is active. You may need to reconfigure the SAML integration from scratch with the updated metadata to restore SSO functionality. :::warning Always configure your custom domain **before** setting up SAML SSO. The SAML metadata Applivery generates includes the App Store URL as a callback endpoint — if you add a custom domain after configuring SSO, you will need to regenerate the metadata and update your Identity Provider. ::: * * * ### SSL certificate and CAA records Applivery automatically provisions and manages an SSL certificate for your custom domain. No manual certificate configuration is required on your side. If your domain uses **CAA (Certification Authority Authorization)** DNS records to restrict which Certificate Authorities can issue certificates for it, you need to authorize the CAs that Applivery uses. Add a CAA record for each of the following: | Type | Name | Value | | --- | --- | --- | | `CAA` | `@` _(or your subdomain)_ | `0 issue "digicert.com"` | | `CAA` | `@` _(or your subdomain)_ | `0 issue "pki.goog"` | | `CAA` | `@` _(or your subdomain)_ | `0 issue "letsencrypt.org"` | | `CAA` | `@` _(or your subdomain)_ | `0 issue "ssl.com"` | If you don't have any CAA records configured, all CAs are permitted by default, and no action is needed. You can use [SSLMate's CAA Record Generator](https://sslmate.com/caa/) to generate the correct record for your setup. --- ## Workspaces Source: https://docs.applivery.com/en/platform/organization/workspaces/ Description: Manage Applivery Workspaces — create, switch, configure billing, and transfer ownership to organize your Apps and Devices efficiently. TL;DR: Manage your Applivery environment by creating, switching between, and configuring workspaces for optimal app and device organization. Key topics: Workspace creation, Workspace switching, Billing management, Ownership transfer, Applivery, Workspace, Admin A Workspace is the top-level organizational unit in Applivery. It groups all your Apps, Devices, team members, Billing, and Settings under a single umbrella. You can have multiple workspaces — for example, one per business unit, client, or environment — and switch between them at any time from the top navigation bar. * * * ### Switching between workspaces The Workspace dropdown in the top navigation bar always shows your currently active Workspace. Click it to see all workspaces you have access to and select any of them to switch. From the same dropdown, you can also access **Audit**, **Billing**, and **Settings** for the active Workspace. ![Workspace dropdown](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/38435af9-3a19-4539-a1e0-2b85df6c3c32.png) * * * ### Creating a Workspace To create a new Workspace, open the Workspace dropdown in the top navigation bar and click **\+ New Workspace**. Type a name and confirm. The new Workspace starts empty — no Apps, Devices, or team members — and has its own independent Billing. ![create Workspace](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/e1c9f566-8fa1-433b-97f2-66ba10baba67.png) * * * ### Billing and subscription Billing is managed per Workspace. Each Workspace has its own plan, payment method, and invoice history, all accessible from **Workspace → Billing**. The Billing section is organized into three areas: - **Plan & Usage** — view your current plan, upgrade, downgrade, or cancel your subscription, and monitor usage against your plan limits. - **Payment** — manage your billing details and payment methods. - **Invoices** — access the full history of invoices associated with the Workspace. ![billing section](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/0f4cc557-3df0-47ea-9d4a-ca33b364e9be.png) #### Updating payment information Go to **Workspace → Billing → Payment** to update billing details or add a new payment method. #### Upgrading or changing your plan Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), go to your **Workspace**, select **Billing**, and then click the **Plan & Usage** button. Then just click Manage next to your current plan. A modal will appear showing your current plan alongside the available alternatives. Select a new plan from the tabs at the top and click **Continue** to apply the change. :::tip You can upgrade or cancel your plan at any time without contacting support — changes take effect immediately. ::: * * * ### Transferring Workspace ownership Ownership of a Workspace can be transferred to any existing member of the organization. To do so, go to **Workspace Settings, and** from the left-hand menu navigate to the **Danger Zone**. Click the **Transfer** button next to the **Transfer Ownership** option. Then, select the new owner from the list of organization members and confirm the action. The transfer happens immediately. The previous owner is automatically reassigned to the **Admin** role and retains access to the Workspace. ![transfer ownership](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/078e6b67-6529-4555-b4b0-16a335e2fa35.png) :::warning Ownership transfer is immediate and cannot be undone from the dashboard. If you need to reverse a transfer, the new owner must initiate another transfer back. ::: --- ## Roles & Permissions Source: https://docs.applivery.com/en/platform/roles-permissions/ Description: Control what each Collaborator can see and do within Applivery — assign predefined roles or configure granular permissions to match your organization's structure. Roles and permissions control what each Collaborator can see and do within Applivery. You can assign predefined roles or configure granular permissions to match your organization's structure — from full administrators to read-only viewers or platform-specific operators. Review the available roles, see how permissions are structured across App Distribution and Device Management, and assign and manage Collaborator access. --- ## Custom Collaborator Roles Source: https://docs.applivery.com/en/platform/roles-permissions/custom-collaborator-roles/ Description: Create custom Collaborator roles for Device Management in Applivery and assign them on Segment permissions to give each team exactly the access it needs. TL;DR: Create a role with the exact actions a job needs, then assign it on a Segment permission. Workspace actions only apply on the Global Segment. Key topics: What a Collaborator role is, Roles vs Segment permissions, Workspace and Device Management action groups, How permissions add up across Segments, Creating and assigning custom roles, Applivery, Collaborator, Segment, Device Management Custom Collaborator roles let you decide exactly what each [Collaborator](https://docs.applivery.com/en/device-management/getting-started/manage-users/#collaborators) on your team can do in the Device Management area of the Applivery Dashboard. Instead of choosing between **Admin**, **Editor** or **Viewer** for every Segment permission, you can build a role for a specific job, such as helpdesk, store admin or auditor, and reuse it wherever you need it. That way, nobody gets full Admin access just because they need one extra action in one place. :::info This applies to **Device Management** Collaborator roles. [App Distribution Collaborator roles](https://docs.applivery.com/en/app-distribution/distribute/manage-users/#roles-and-permissions) work the same as before. ::: ### What is a Collaborator role A Collaborator role is a named set of Dashboard actions. It answers **what** a Collaborator can do, but not **where**: that's decided by the Segment permission you assign it to. Roles live at organization level. You create them once and reuse them across as many Segment permissions as you like. A role doesn't belong to any Segment. #### Built-in roles **Admin**, **Editor,** and **Viewer** are still available. They're marked as built-in, and you can't edit or delete them. If you want something close to one of them, **Duplicate** it and edit the copy, which becomes a new custom role. If you open a built-in role without duplicating it, it opens in read-only mode. #### Custom roles You create custom roles from scratch with **Create role**, or by duplicating an existing role. You can edit their name, description, and actions at any time. When you pick a role on a permission, the role selector shows the custom role's name. In the **Permissions** and **By collaborators** tables, custom roles show a generic **Custom** tag instead, so long names don't break the layout. ### Roles and Segment permissions Two layers work together to give someone access:

Layer

What it decides

Where you manage it

Role

Which Dashboard actions are allowed

Settings → Directory → Roles

Segment permission

Who gets that role, and on which Segment

Settings → Segments & Permission

On a Segment permission, you select one role. You can't create or edit the role from the permission itself; instead, the permission shows a read-only preview of the actions included in the selected role. ### Action groups: Workspace and Device Management Every action belongs to one of two groups: - **Workspace** (**W**): organization-level settings and people management, such as Collaborators, Segments, login providers, and the few billing-related actions that aren't Owner-only. - **Device Management** (**M**): actions on Devices, Policies, enrollment, and other Device Management elements inside a Segment. A role can include Workspace actions, Device Management actions, or both. The **Roles** list and the role selector show a **W** and an **M** badge for each role: the badge is highlighted when the role has actions in that group, and greyed out when it has none. **Owner-only actions**, such as transferring ownership, deleting the workspace, and most billing management actions, are shown in the Workspace group but stay locked. They can't be granted through any role. ![built in roles](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/863777de-c3b5-4403-af49-4af91fed2572.png) #### Workspace actions only apply on Global Workspace actions only take effect when the Segment permission sits on **Global**, the root Segment of your tree. If you assign a role that includes Workspace actions on a child Segment: - The role's Device Management actions still apply on that Segment. - Its Workspace actions don't take effect there. - The Dashboard shows a warning under the **Role** field, but you can still save. - The read-only preview hides the Workspace section, since those actions won't apply. ![segment perms](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/c62410a2-674f-427c-a4d6-5c53a7f2c996.png) ### How permissions add up across Segments Permissions **add up** as you go down the [Segment](https://docs.applivery.com/en/device-management/general-settings/segments/) tree. Here's an example: - A Collaborator has **Viewer** on **Global**. - The same Collaborator has a custom role with extra Device Management actions on **Madrid**, a child Segment. On Madrid, that Collaborator can do everything Global and Madrid grant combined. This also means a permission on a child Segment **can't remove** actions granted higher up in the tree. If someone needs fewer actions in one store than in the whole region, assign the narrower role at the store level (or lower), rather than a wide role at the region level. :::info The permission preview only shows the actions in the selected role. It doesn't include what the Collaborator already has from permissions on parent Segments. ::: ### How to create a Collaborator role **Go to Roles** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), navigate to the **Settings** section 1 and, in the left-hand menu under **Directory**, select **Roles** 2. **Create the role** Click **Create role** 3, then enter a name and a description for it. ![create role](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/60e212f9-e127-4a35-9cd5-1fee51090065.png) **Select the actions** If you want to start from an existing role's actions, choose it as a template 4. Then select or clear the actions you need in the **Workspace** and **Device Management** groups 5. Owner-only actions stay locked. ![role modal](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/c6d97939-11b8-4cfe-9ab2-4d3f66cc1b9c.png) **Save** Save the role. It's now available to assign on any Segment permission. To create a custom role based on a built-in one, open **Admin**, **Editor,** or **Viewer**, click **Duplicate,** and edit the new role. ### How to assign a role on a Segment permission This follows the same flow you use to [create Segments and permissions](https://docs.applivery.com/en/device-management/general-settings/segments/#how-to-create-segments-and-permissions), with the new role options. **Open the Segment** Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), navigate to the **Settings** section 1, select **Segments & Permission** 2 from the left-hand menu, select the Segment 3, and create or edit a permission 4. ![role and segment](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/eb1dbbd7-30d0-4cc0-b52e-b3a9f06e9814.png) **Name the permission and choose the role** Give the permission a clear name and choose the role, either built-in or custom. Check its **W** and **M** badges to see which groups of actions it includes. If the Segment isn't Global and the role includes Workspace actions, you'll see a warning. Remember that those Workspace actions won't apply to this Segment. **Add who gets it** Add the groups and/or email addresses that match this permission. **Review and save** Check the read-only preview of the role's actions and save. You can't change individual actions on a single permission. To adjust them, edit the role, or create a new one and assign it instead. ### Things to keep in mind - **App Distribution** Collaborator roles aren't affected by custom roles. See [Manage users in App Distribution](https://docs.applivery.com/en/app-distribution/distribute/manage-users/#roles-and-permissions). - **Inventory** actions aren't part of custom roles. - A permission on a child Segment can't deny or remove actions granted on a parent Segment. - Each permission uses one role as it is. There's no way to customize actions per permission without creating or editing a role. - Custom roles are for people. Service accounts used for API access and automation have their own roles. See [Service Accounts](https://docs.applivery.com/en/platform/api/service-accounts/). --- ## Permissions by Role Source: https://docs.applivery.com/en/platform/roles-permissions/permissions-by-role/ Description: Check which Applivery API endpoints and actions each built-in role can use in Device Management, App Distribution and the Workspace. TL;DR: Each API endpoint requires one permission, and each built-in role includes a set of permissions. Use the summary to compare roles and the tables by area to check a specific endpoint. Key topics: How roles and permissions work, Endpoints and actions by role, Permissions by area, Applivery, Collaborator, Device Management, App Distribution Every endpoint of the [Applivery API](https://docs.applivery.com/en/api/) that depends on a role requires one permission, which you'll find as **Required Permission** on its reference page. Each built-in role includes a fixed set of these permissions, so the role a Collaborator or Service Account has decides which endpoints it can call and which actions it can take in the Dashboard. Use the summary to compare what each role covers, and the tables by area to check a specific permission or endpoint. ### How roles and permissions work A permission, also called an action, has four parts: `area.context.resource.operation`. For example, `mdm.apple.depDevice.get` lets you get an Apple Business device in Device Management. It's the same name you'll see as **Required Permission** in the API reference. These are the built-in roles: | Role | Where it applies | | --- | --- | | **Owner** | The Workspace owner. Has every action, including billing and ownership. There's only one Owner per Workspace. | | **Device Management Admin, Editor, and Viewer** | The built-in Device Management Collaborator roles, assigned on Segment permissions. Check [Custom Collaborator Roles](https://docs.applivery.com/en/platform/roles-permissions/custom-collaborator-roles/). | | **App Distribution Admin, Editor, and Viewer** | The Workspace-level App Distribution Collaborator roles. Check [Roles and Permissions in App Distribution](https://docs.applivery.com/en/app-distribution/distribute/manage-users/#roles-and-permissions). | | **App Admin, App Editor, and App Viewer** | Roles on a single App in App Distribution. An App Owner gets the same actions as an App Admin. | | **Unassigned** | No access at Workspace level. The Collaborator can still get a role on a specific App. | | **No Role** | The actions applied when the user has no role in the Workspace or the App. | Keep in mind that: - **Actions add up.** A Collaborator with a Workspace role and an App role gets the actions from both, and [permissions add up down the Segment tree](https://docs.applivery.com/en/platform/roles-permissions/custom-collaborator-roles/#how-permissions-add-up-across-segments) in Device Management. - **Custom roles** include the actions you select, so they don't appear on this page. Owner actions (`owner.*`) and App Distribution people actions (`people.mad.*`) can't be part of a custom role. ### Endpoints by role **Endpoints** counts the API operations a role can call. **Actions** counts every permission the role includes, including actions that no public endpoint uses. One action can cover several endpoints. The last three columns split the endpoints by area. | Role | Endpoints | Actions | Device Management | App Distribution | Workspace | | --- | :-: | :-: | :-: | :-: | :-: | | **Owner** | 584 | 552 | 386 | 108 | 90 | | **Device Management Admin** | 472 | 424 | 386 | 0 | 86 | | **Device Management Editor** | 297 | 245 | 257 | 0 | 40 | | **Device Management Viewer** | 192 | 142 | 164 | 1 | 27 | | **App Distribution Admin** | 172 | 164 | 0 | 108 | 64 | | **App Distribution Editor** | 101 | 85 | 0 | 65 | 36 | | **App Distribution Viewer** | 74 | 57 | 0 | 51 | 23 | | **App Admin** | 117 | 108 | 0 | 94 | 23 | | **App Editor** | 79 | 66 | 0 | 60 | 19 | | **App Viewer** | 62 | 48 | 0 | 43 | 19 | | **Unassigned** | 8 | 5 | 0 | 0 | 8 | | **No Role** | 9 | 8 | 0 | 1 | 8 | :::info The API has 663 endpoints, and 584 of them require a permission. The rest, such as authentication, don't depend on a Collaborator role. ::: ### Permissions by area Each table lists the permissions of one area, the endpoints that require them, and the roles that include them: **✓** means the role includes the permission and **–** means it doesn't. An endpoint path is relative to `/organizations/:organizationId`, and **—** in **Endpoints** means no public API endpoint uses that permission. The role columns use these abbreviations: | Abbreviation | Role | | --- | --- | | **O** | Owner | | **A**, **E**, **V** | Admin, Editor, and Viewer of Device Management or App Distribution, depending on the tab or table | | **App A**, **App E**, **App V** | App Admin, App Editor, and App Viewer | In the **Workspace** tab, each area has two tables: one for the Device Management roles and one for the App Distribution roles. A **¹** marks a permission that other roles also include, such as Unassigned or No Role; you'll find them under the table. **Device Management** **Global (mdm.global) · 67 actions, 67 endpoints** | Permission | Endpoints | O | A | E | V | | --- | --- | :-: | :-: | :-: | :-: | | `mdm.global.agentLog.get` | [`GET /mdm/agent-logs/:mdmAgentLogsId`](https://docs.applivery.com/en/api/uem/agent-logs/get-agent-log/) | ✓ | ✓ | ✓ | ✓ | | `mdm.global.agentLog.list` | [`GET /mdm/agent-logs`](https://docs.applivery.com/en/api/uem/agent-logs/get-agent-logs/) | ✓ | ✓ | ✓ | ✓ | | `mdm.global.agentLog.remove` | [`DELETE /mdm/agent-logs/:mdmAgentLogsId`](https://docs.applivery.com/en/api/uem/agent-logs/delete-agent-log/) | ✓ | ✓ | ✓ | ✓ | | `mdm.global.agentLog.view` | — | ✓ | ✓ | ✓ | ✓ | | `mdm.global.asset.create` | [`POST /mdm/assets`](https://docs.applivery.com/en/api/uem/managed-assets/post-asset/)
[`POST /mdm/assets/edge/asset`](https://docs.applivery.com/en/api/uem/managed-assets/edge/post-asset/)
[`GET /mdm/assets/edge/prepare`](https://docs.applivery.com/en/api/uem/managed-assets/edge/get-prepare/) | ✓ | ✓ | ✓ | – | | `mdm.global.asset.download` | [`GET /mdm/assets/:mdmAssetId/download`](https://docs.applivery.com/en/api/uem/managed-assets/get-download/) | ✓ | ✓ | ✓ | – | | `mdm.global.asset.get` | [`GET /mdm/assets/:mdmAssetId`](https://docs.applivery.com/en/api/uem/managed-assets/get-asset/)
[`GET /mdm/assets/:mdmAssetId/assignations`](https://docs.applivery.com/en/api/uem/managed-assets/get-assignations/) | ✓ | ✓ | ✓ | ✓ | | `mdm.global.asset.list` | [`GET /mdm/assets`](https://docs.applivery.com/en/api/uem/managed-assets/get-assets/) | ✓ | ✓ | ✓ | ✓ | | `mdm.global.asset.remove` | [`DELETE /mdm/assets/:mdmAssetId`](https://docs.applivery.com/en/api/uem/managed-assets/delete-asset/) | ✓ | ✓ | ✓ | – | | `mdm.global.asset.update` | [`PUT /mdm/assets/:mdmAssetId`](https://docs.applivery.com/en/api/uem/managed-assets/put-asset/) | ✓ | ✓ | ✓ | – | | `mdm.global.asset.view` | [`GET /mdm/assets/:mdmAssetId/view`](https://docs.applivery.com/en/api/uem/managed-assets/get-view/) | ✓ | ✓ | ✓ | ✓ | | `mdm.global.automationRule.create` | [`POST /mdm/automation-rules`](https://docs.applivery.com/en/api/uem/automation-rules/post-automation-rule/) | ✓ | ✓ | ✓ | – | | `mdm.global.automationRule.get` | [`GET /mdm/automation-rules/:mdmAutomationRuleId`](https://docs.applivery.com/en/api/uem/automation-rules/get-automation-rule/) | ✓ | ✓ | ✓ | ✓ | | `mdm.global.automationRule.list` | [`GET /mdm/automation-rules`](https://docs.applivery.com/en/api/uem/automation-rules/get-automation-rules/) | ✓ | ✓ | ✓ | ✓ | | `mdm.global.automationRule.remove` | [`DELETE /mdm/automation-rules/:mdmAutomationRuleId`](https://docs.applivery.com/en/api/uem/automation-rules/delete-automation-rule/) | ✓ | ✓ | ✓ | – | | `mdm.global.automationRule.update` | [`PUT /mdm/automation-rules/:mdmAutomationRuleId`](https://docs.applivery.com/en/api/uem/automation-rules/put-automation-rule/) | ✓ | ✓ | ✓ | – | | `mdm.global.automationRuleLog.list` | [`GET /mdm/automation-rules-logs`](https://docs.applivery.com/en/api/uem/automation-rules-logs/get-automation-rules-logs/) | ✓ | ✓ | ✓ | ✓ | | `mdm.global.configurations.get` | [`GET /mdm/configurations`](https://docs.applivery.com/en/api/uem/configurations/get-organizations-organizationid-mdm-configurations/) | ✓ | ✓ | – | – | | `mdm.global.configurations.update` | [`PUT /mdm/configurations`](https://docs.applivery.com/en/api/uem/configurations/put-organizations-organizationid-mdm-configurations/) | ✓ | ✓ | – | – | | `mdm.global.device.list` | [`GET /mdm/devices`](https://docs.applivery.com/en/api/uem/devices/get-devices/)
[`GET /mdm/devices/available-updates`](https://docs.applivery.com/en/api/uem/devices/get-available-updates/)
[`GET /mdm/devices/csv`](https://docs.applivery.com/en/api/uem/devices/get-csv/)
[`GET /mdm/devices/os-versions`](https://docs.applivery.com/en/api/uem/devices/get-os-versions/)
[`GET /mdm/devices/sync-errors`](https://docs.applivery.com/en/api/uem/devices/get-sync-errors/)
[`GET /mdm/devices/tags`](https://docs.applivery.com/en/api/uem/devices/get-tags/) | ✓ | ✓ | ✓ | ✓ | | `mdm.global.deviceAudience.create` | [`POST /mdm/device-audiences`](https://docs.applivery.com/en/api/platform/device-audiences/post-device-audience/) | ✓ | ✓ | ✓ | – | | `mdm.global.deviceAudience.download` | — | ✓ | ✓ | ✓ | – | | `mdm.global.deviceAudience.get` | [`GET /mdm/device-audiences/:deviceAudienceId`](https://docs.applivery.com/en/api/platform/device-audiences/get-device-audience/) | ✓ | ✓ | ✓ | ✓ | | `mdm.global.deviceAudience.list` | [`GET /mdm/device-audiences`](https://docs.applivery.com/en/api/platform/device-audiences/get-device-audiences/) | ✓ | ✓ | ✓ | ✓ | | `mdm.global.deviceAudience.preview` | [`POST /mdm/device-audiences/preview`](https://docs.applivery.com/en/api/platform/device-audiences/preview/post/)
[`POST /mdm/device-audiences/preview-multiple`](https://docs.applivery.com/en/api/platform/device-audiences/post-preview-multiple/) | ✓ | ✓ | ✓ | ✓ | | `mdm.global.deviceAudience.remove` | [`DELETE /mdm/device-audiences/:deviceAudienceId`](https://docs.applivery.com/en/api/platform/device-audiences/delete-device-audience/) | ✓ | ✓ | ✓ | – | | `mdm.global.deviceAudience.update` | [`PUT /mdm/device-audiences/:deviceAudienceId`](https://docs.applivery.com/en/api/platform/device-audiences/put-device-audience/) | ✓ | ✓ | ✓ | – | | `mdm.global.deviceAudience.view` | [`GET /mdm/device-audiences/:deviceAudienceId/preview`](https://docs.applivery.com/en/api/platform/device-audiences/preview/get/) | ✓ | ✓ | ✓ | ✓ | | `mdm.global.deviceMessage.get` | [`GET /mdm/device-messages/:deviceMessageId`](https://docs.applivery.com/en/api/uem/device-message/get-organizations-organizationid-mdm-device-messages-devicemessageid/) | ✓ | ✓ | ✓ | ✓ | | `mdm.global.deviceMessage.list` | [`GET /mdm/device-messages`](https://docs.applivery.com/en/api/uem/device-message/get-organizations-organizationid-mdm-device-messages/) | ✓ | ✓ | ✓ | ✓ | | `mdm.global.deviceMessage.upsert` | — | ✓ | ✓ | ✓ | – | | `mdm.global.deviceTmv.requestControl` | `POST /mdm/tmv/request-control` | ✓ | ✓ | – | – | | `mdm.global.location.get` | [`GET /mdm/locations/:type/:identifier/:mdmLocationId`](https://docs.applivery.com/en/api/uem/locations/get-location/) | ✓ | ✓ | ✓ | ✓ | | `mdm.global.location.list` | [`GET /mdm/locations/:type/:identifier`](https://docs.applivery.com/en/api/uem/locations/get-locations/) | ✓ | ✓ | ✓ | ✓ | | `mdm.global.location.remove` | [`DELETE /mdm/locations/:type/:identifier/:mdmLocationId`](https://docs.applivery.com/en/api/uem/locations/delete-location/) | ✓ | ✓ | – | – | | `mdm.global.mdmSmartAttribute.update` | — | ✓ | ✓ | ✓ | – | | `mdm.global.mdmUser.create` | [`POST /mdm/users`](https://docs.applivery.com/en/api/uem/users/post-user/) | ✓ | ✓ | ✓ | – | | `mdm.global.mdmUser.get` | [`GET /mdm/users/:mdmUserId`](https://docs.applivery.com/en/api/uem/users/get-user/) | ✓ | ✓ | ✓ | ✓ | | `mdm.global.mdmUser.list` | [`GET /mdm/users`](https://docs.applivery.com/en/api/uem/users/get-users/)
[`GET /mdm/users/csv/sample`](https://docs.applivery.com/en/api/uem/users/get-csv-sample/)
[`GET /mdm/users/tags`](https://docs.applivery.com/en/api/uem/users/get-tags/) | ✓ | ✓ | ✓ | ✓ | | `mdm.global.mdmUser.remove` | [`DELETE /mdm/users/:mdmUserId`](https://docs.applivery.com/en/api/uem/users/delete-user/) | ✓ | ✓ | – | – | | `mdm.global.mdmUser.update` | [`PUT /mdm/users/:mdmUserId`](https://docs.applivery.com/en/api/uem/users/put-user/) | ✓ | ✓ | ✓ | – | | `mdm.global.networkStatus.get` | [`GET /mdm/network-status/:type/:identifier/:mdmNetworkStatusId`](https://docs.applivery.com/en/api/uem/network-status/get-network-status/) | ✓ | ✓ | ✓ | ✓ | | `mdm.global.networkStatus.list` | [`GET /mdm/network-status/:type/:identifier`](https://docs.applivery.com/en/api/uem/network-status/get-network-statuses/) | ✓ | ✓ | ✓ | ✓ | | `mdm.global.networkStatus.remove` | [`DELETE /mdm/network-status/:type/:identifier/:mdmNetworkStatusId`](https://docs.applivery.com/en/api/uem/network-status/delete-network-status/) | ✓ | ✓ | – | – | | `mdm.global.packageTime.get` | [`GET /mdm/package-times/:type/:identifier/:mdmPackageTimeId`](https://docs.applivery.com/en/api/uem/package-times/get-package-time/) | ✓ | ✓ | ✓ | ✓ | | `mdm.global.packageTime.list` | [`GET /mdm/package-times/:type/:identifier`](https://docs.applivery.com/en/api/uem/package-times/get-package-times/) | ✓ | ✓ | ✓ | ✓ | | `mdm.global.packageTime.remove` | [`DELETE /mdm/package-times/:type/:identifier/:mdmPackageTimeId`](https://docs.applivery.com/en/api/uem/package-times/delete-package-time/) | ✓ | ✓ | – | – | | `mdm.global.packageTransfer.get` | [`GET /mdm/package-transfers/:type/:identifier/:mdmPackageTransferId`](https://docs.applivery.com/en/api/uem/package-transfers/get-package-transfer/) | ✓ | ✓ | ✓ | ✓ | | `mdm.global.packageTransfer.list` | [`GET /mdm/package-transfers/:type/:identifier`](https://docs.applivery.com/en/api/uem/package-transfers/get-package-transfers/) | ✓ | ✓ | ✓ | ✓ | | `mdm.global.packageTransfer.remove` | [`DELETE /mdm/package-transfers/:type/:identifier/:mdmPackageTransferId`](https://docs.applivery.com/en/api/uem/package-transfers/delete-package-transfer/) | ✓ | ✓ | – | – | | `mdm.global.policy.list` | [`GET /mdm/policies`](https://docs.applivery.com/en/api/uem/policies/get-policies/) | ✓ | ✓ | ✓ | ✓ | | `mdm.global.policySync.list` | [`GET /mdm/policy-sync`](https://docs.applivery.com/en/api/uem/policy-sync/get-policy-sync/) | ✓ | ✓ | ✓ | ✓ | | `mdm.global.policySync.remove` | — | ✓ | ✓ | ✓ | ✓ | | `mdm.global.policyTemplate.create` | — | ✓ | ✓ | ✓ | – | | `mdm.global.policyTemplate.get` | — | ✓ | ✓ | ✓ | ✓ | | `mdm.global.policyTemplate.list` | — | ✓ | ✓ | ✓ | ✓ | | `mdm.global.policyTemplate.remove` | — | ✓ | ✓ | ✓ | – | | `mdm.global.policyTemplate.update` | — | ✓ | ✓ | ✓ | – | | `mdm.global.pushNotification.send` | [`POST /mdm/push-notifications/send`](https://docs.applivery.com/en/api/uem/push-notifications/post-send/) | ✓ | ✓ | – | – | | `mdm.global.smartAttribute.create` | [`POST /smart-attributes`](https://docs.applivery.com/en/api/platform/smart-attributes/post-smart-attribute/) | ✓ | ✓ | ✓ | – | | `mdm.global.smartAttribute.get` | [`GET /smart-attributes/:smartAttributeId`](https://docs.applivery.com/en/api/platform/smart-attributes/get-smart-attribute/)
[`GET /smart-attributes/:smartAttributeId/assignments`](https://docs.applivery.com/en/api/platform/smart-attributes/get-assignments/) | ✓ | ✓ | ✓ | ✓ | | `mdm.global.smartAttribute.list` | [`GET /smart-attributes`](https://docs.applivery.com/en/api/platform/smart-attributes/get-smart-attributes/) | ✓ | ✓ | ✓ | ✓ | | `mdm.global.smartAttribute.remove` | [`DELETE /smart-attributes/:smartAttributeId`](https://docs.applivery.com/en/api/platform/smart-attributes/delete-smart-attribute/) | ✓ | ✓ | ✓ | – | | `mdm.global.smartAttribute.update` | [`PUT /smart-attributes/:smartAttributeId`](https://docs.applivery.com/en/api/platform/smart-attributes/put-smart-attribute/) | ✓ | ✓ | ✓ | – | | `mdm.global.status.get` | [`GET /mdm`](https://docs.applivery.com/en/api/uem/status/get-mdm/) | ✓ | ✓ | ✓ | ✓ | | `mdm.global.tenantTmv.read` | — | ✓ | ✓ | – | – | | `mdm.global.tenantTmv.update` | — | ✓ | ✓ | – | – | **Apple (mdm.apple) · 101 actions, 121 endpoints** | Permission | Endpoints | O | A | E | V | | --- | --- | :-: | :-: | :-: | :-: | | `mdm.apple.application.create` | [`POST /mdm/apple/enterprise/applications`](https://docs.applivery.com/en/api/apple/applications/post-application/) | ✓ | ✓ | ✓ | – | | `mdm.apple.application.get` | [`GET /mdm/apple/enterprise/applications/:admApplicationId`](https://docs.applivery.com/en/api/apple/applications/get-application/) | ✓ | ✓ | ✓ | ✓ | | `mdm.apple.application.list` | [`GET /mdm/apple/enterprise/applications`](https://docs.applivery.com/en/api/apple/applications/get-applications/) | ✓ | ✓ | ✓ | ✓ | | `mdm.apple.application.remove` | [`DELETE /mdm/apple/enterprise/applications/:admApplicationId`](https://docs.applivery.com/en/api/apple/applications/delete-application/) | ✓ | ✓ | – | – | | `mdm.apple.application.search` | [`GET /mdm/apple/enterprise/applications/search`](https://docs.applivery.com/en/api/apple/applications/get-search/) | ✓ | ✓ | ✓ | ✓ | | `mdm.apple.application.update` | [`PUT /mdm/apple/enterprise/applications/:admApplicationId`](https://docs.applivery.com/en/api/apple/applications/put-application/) | ✓ | ✓ | ✓ | – | | `mdm.apple.command.cancel` | [`POST /mdm/apple/enterprise/commands/:targetType/:targetId/:admCommandId/cancel`](https://docs.applivery.com/en/api/apple/commands/post-cancel/) | ✓ | ✓ | – | – | | `mdm.apple.command.create` | [`POST /mdm/apple/enterprise/commands/:targetType`](https://docs.applivery.com/en/api/apple/commands/post-bulk/)
[`POST /mdm/apple/enterprise/commands/:targetType/:targetId`](https://docs.applivery.com/en/api/apple/commands/post-command/) | ✓ | ✓ | – | – | | `mdm.apple.command.get` | [`GET /mdm/apple/enterprise/commands/:targetType/:targetId/:admCommandId`](https://docs.applivery.com/en/api/apple/commands/get-command/) | ✓ | ✓ | ✓ | – | | `mdm.apple.command.list` | [`GET /mdm/apple/enterprise/commands/:targetType/:targetId`](https://docs.applivery.com/en/api/apple/commands/get-commands/)
[`GET /mdm/apple/enterprise/commands/:targetType/:targetId/grouped`](https://docs.applivery.com/en/api/apple/commands/get-grouped/) | ✓ | ✓ | ✓ | – | | `mdm.apple.defaultDeviceConfig.create` | [`POST /mdm/apple/enterprise/default-config`](https://docs.applivery.com/en/api/apple/default-config/post-default-config/) | ✓ | ✓ | – | – | | `mdm.apple.defaultDeviceConfig.get` | [`GET /mdm/apple/enterprise/default-config/:admDefaultDeviceConfigId`](https://docs.applivery.com/en/api/apple/default-config/get-default-config-by-id/) | ✓ | ✓ | – | – | | `mdm.apple.defaultDeviceConfig.list` | [`GET /mdm/apple/enterprise/default-config`](https://docs.applivery.com/en/api/apple/default-config/get-default-config/) | ✓ | ✓ | – | – | | `mdm.apple.defaultDeviceConfig.remove` | [`DELETE /mdm/apple/enterprise/default-config/:admDefaultDeviceConfigId`](https://docs.applivery.com/en/api/apple/default-config/delete-default-config/) | ✓ | ✓ | – | – | | `mdm.apple.defaultDeviceConfig.update` | [`PUT /mdm/apple/enterprise/default-config/:admDefaultDeviceConfigId`](https://docs.applivery.com/en/api/apple/default-config/put-default-config/) | ✓ | ✓ | – | – | | `mdm.apple.depDevice.assignProfile` | [`POST /mdm/apple/enterprise/dep/devices/:admDepDeviceId/assign-profile`](https://docs.applivery.com/en/api/apple/dep-devices/post-assign-profile/) | ✓ | ✓ | – | – | | `mdm.apple.depDevice.disown` | [`POST /mdm/apple/enterprise/dep/devices/:admDepDeviceId/disown`](https://docs.applivery.com/en/api/apple/dep-devices/post-disown/) | ✓ | ✓ | – | – | | `mdm.apple.depDevice.get` | [`GET /mdm/apple/enterprise/dep/devices/:admDepDeviceId`](https://docs.applivery.com/en/api/apple/dep-devices/get-device/) | ✓ | ✓ | – | – | | `mdm.apple.depDevice.list` | [`GET /mdm/apple/enterprise/dep/devices`](https://docs.applivery.com/en/api/apple/dep-devices/get-devices/) | ✓ | ✓ | – | – | | `mdm.apple.depDevice.lock` | [`POST /mdm/apple/enterprise/dep/devices/:admDepDeviceId/lock`](https://docs.applivery.com/en/api/apple/dep-devices/post-lock/) | ✓ | ✓ | – | – | | `mdm.apple.depDevice.removeProfile` | [`DELETE /mdm/apple/enterprise/dep/devices/:admDepDeviceId/remove-profile`](https://docs.applivery.com/en/api/apple/dep-devices/delete-remove-profile/) | ✓ | ✓ | – | – | | `mdm.apple.depDevice.sync` | [`GET /mdm/apple/enterprise/dep/devices/sync`](https://docs.applivery.com/en/api/apple/dep-devices/get-sync/)
[`GET /mdm/apple/enterprise/dep/devices/sync-all`](https://docs.applivery.com/en/api/apple/dep-devices/get-sync-all/)
[`GET /mdm/apple/enterprise/dep/devices/sync-transaction`](https://docs.applivery.com/en/api/apple/dep-devices/sync-transaction/get/)
[`GET /mdm/apple/enterprise/dep/devices/sync-transaction/:admDepSyncTransactionId`](https://docs.applivery.com/en/api/apple/dep-devices/sync-transaction/get-by-id/) | ✓ | ✓ | – | – | | `mdm.apple.depDevice.update` | [`PUT /mdm/apple/enterprise/dep/devices/:admDepDeviceId`](https://docs.applivery.com/en/api/apple/dep-devices/put-device/) | ✓ | ✓ | – | – | | `mdm.apple.depProfile.create` | [`POST /mdm/apple/enterprise/dep/profiles`](https://docs.applivery.com/en/api/apple/dep-profiles/post-profile/) | ✓ | ✓ | – | – | | `mdm.apple.depProfile.get` | [`GET /mdm/apple/enterprise/dep/profiles/:admDepProfileId`](https://docs.applivery.com/en/api/apple/dep-profiles/get-profile/) | ✓ | ✓ | – | – | | `mdm.apple.depProfile.list` | [`GET /mdm/apple/enterprise/dep/profiles`](https://docs.applivery.com/en/api/apple/dep-profiles/get-profiles/) | ✓ | ✓ | – | – | | `mdm.apple.depProfile.remove` | [`DELETE /mdm/apple/enterprise/dep/profiles/:admDepProfileId`](https://docs.applivery.com/en/api/apple/dep-profiles/delete-profile/) | ✓ | ✓ | – | – | | `mdm.apple.device.action` | [`POST /mdm/apple/enterprise/devices/:admDeviceId/action`](https://docs.applivery.com/en/api/apple/devices/post-action/)
[`GET /mdm/apple/enterprise/devices/:admDeviceId/agent-cleanup`](https://docs.applivery.com/en/api/apple/devices/get-agent-cleanup/)
[`GET /mdm/apple/enterprise/devices/:admDeviceId/agent-recovery`](https://docs.applivery.com/en/api/apple/devices/get-agent-recovery/)
[`GET /mdm/apple/enterprise/devices/:admDeviceId/agent-recovery-managed-configuration`](https://docs.applivery.com/en/api/apple/devices/get-agent-recovery-managed-configuration/)
[`GET /mdm/apple/enterprise/devices/:admDeviceId/setup-assistant-recovery-managed-configuration`](https://docs.applivery.com/en/api/apple/devices/get-setup-assistant-recovery-managed-configuration/) | ✓ | ✓ | – | – | | `mdm.apple.device.create` | — | ✓ | ✓ | – | – | | `mdm.apple.device.get` | [`GET /mdm/apple/enterprise/devices/:admDeviceId`](https://docs.applivery.com/en/api/apple/devices/get-device/)
[`GET /mdm/apple/enterprise/devices/:admDeviceId/agent-config`](https://docs.applivery.com/en/api/apple/devices/get-agent-config/)
[`GET /mdm/apple/enterprise/devices/:admDeviceId/agent-config-assets`](https://docs.applivery.com/en/api/apple/devices/get-agent-config-assets/)
[`GET /mdm/apple/enterprise/devices/:admDeviceId/agent-config-assets-setup`](https://docs.applivery.com/en/api/apple/devices/get-agent-config-assets-setup/)
[`GET /mdm/apple/enterprise/devices/:admDeviceId/agent-tokens`](https://docs.applivery.com/en/api/apple/devices/get-agent-tokens/)
[`GET /mdm/apple/enterprise/devices/:admDeviceId/applications`](https://docs.applivery.com/en/api/apple/devices/get-applications/)
[`GET /mdm/apple/enterprise/devices/:admDeviceId/scheduler-scripts`](https://docs.applivery.com/en/api/apple/devices/get-scheduler-scripts/) | ✓ | ✓ | ✓ | ✓ | | `mdm.apple.device.getActivationLockBypassCode` | [`GET /mdm/apple/enterprise/devices/:admDeviceId/activation-lock-bypass-code`](https://docs.applivery.com/en/api/apple/devices/get-activation-lock-bypass-code/) | ✓ | ✓ | – | – | | `mdm.apple.device.getFileVaultRecoveryKey` | [`GET /mdm/apple/enterprise/devices/:admDeviceId/file-vault-recovery-key`](https://docs.applivery.com/en/api/apple/devices/get-file-vault-recovery-key/) | ✓ | ✓ | – | – | | `mdm.apple.device.list` | [`GET /mdm/apple/enterprise/devices`](https://docs.applivery.com/en/api/apple/devices/get-devices/) | ✓ | ✓ | ✓ | ✓ | | `mdm.apple.device.move` | [`PUT /mdm/apple/enterprise/devices/:admDeviceId/move`](https://docs.applivery.com/en/api/apple/devices/put-move/) | ✓ | ✓ | – | – | | `mdm.apple.device.notify` | [`GET /mdm/apple/enterprise/devices/:admDeviceId/check-notify`](https://docs.applivery.com/en/api/apple/devices/get-check-notify/)
[`GET /mdm/apple/enterprise/devices/:admDeviceId/notify`](https://docs.applivery.com/en/api/apple/devices/get-notify/) | ✓ | ✓ | ✓ | – | | `mdm.apple.device.refresh` | [`GET /mdm/apple/enterprise/devices/:admDeviceId/refresh`](https://docs.applivery.com/en/api/apple/devices/get-refresh/) | ✓ | ✓ | ✓ | – | | `mdm.apple.device.reinstall` | [`GET /mdm/apple/enterprise/devices/:admDeviceId/reinstall`](https://docs.applivery.com/en/api/apple/devices/get-reinstall/) | ✓ | ✓ | – | – | | `mdm.apple.device.remove` | [`DELETE /mdm/apple/enterprise/devices/:admDeviceId`](https://docs.applivery.com/en/api/apple/devices/delete-device/) | ✓ | ✓ | – | – | | `mdm.apple.device.sync` | [`GET /mdm/apple/enterprise/devices/:admDeviceId/sync`](https://docs.applivery.com/en/api/apple/devices/get-sync/) | ✓ | ✓ | ✓ | – | | `mdm.apple.device.unlock` | [`GET /mdm/apple/enterprise/devices/:admDeviceId/unlock`](https://docs.applivery.com/en/api/apple/devices/get-unlock/) | ✓ | ✓ | – | – | | `mdm.apple.device.update` | [`PUT /mdm/apple/enterprise/devices/:admDeviceId`](https://docs.applivery.com/en/api/apple/devices/put-device/) | ✓ | ✓ | ✓ | – | | `mdm.apple.deviceNotification.action` | [`POST /mdm/apple/enterprise/devices/:admDeviceId/notifications`](https://docs.applivery.com/en/api/apple/devices/notifications/post-notification/) | ✓ | ✓ | – | – | | `mdm.apple.deviceScriptLog.get` | [`GET /mdm/apple/enterprise/devices/:admDeviceId/script-logs/:admDeviceScriptLogId`](https://docs.applivery.com/en/api/apple/devices/script-logs/get-script-log/) | ✓ | ✓ | ✓ | ✓ | | `mdm.apple.deviceScriptLog.invalidate` | [`POST /mdm/apple/enterprise/devices/:admDeviceId/script-logs/:admDeviceScriptLogId/invalidate`](https://docs.applivery.com/en/api/apple/devices/script-logs/post-invalidate/)
[`POST /mdm/apple/enterprise/devices/:admDeviceId/script-logs/invalidate-once`](https://docs.applivery.com/en/api/apple/devices/script-logs/post-invalidate-once/) | ✓ | ✓ | ✓ | ✓ | | `mdm.apple.deviceScriptLog.list` | [`GET /mdm/apple/enterprise/devices/:admDeviceId/script-logs`](https://docs.applivery.com/en/api/apple/devices/script-logs/get-script-logs/)
[`GET /mdm/apple/enterprise/devices/:admDeviceId/script-logs/summary`](https://docs.applivery.com/en/api/apple/devices/script-logs/get-summary/) | ✓ | ✓ | ✓ | ✓ | | `mdm.apple.deviceUser.get` | [`GET /mdm/apple/enterprise/devices/:admDeviceId/users/:admDeviceUserId`](https://docs.applivery.com/en/api/apple/devices/users/get-user/)
[`GET /mdm/apple/enterprise/devices/:admDeviceId/users/:admDeviceUserId/applications`](https://docs.applivery.com/en/api/apple/devices/users/get-applications/) | ✓ | ✓ | ✓ | ✓ | | `mdm.apple.deviceUser.list` | [`GET /mdm/apple/enterprise/devices/:admDeviceId/users`](https://docs.applivery.com/en/api/apple/devices/users/get-users/) | ✓ | ✓ | ✓ | ✓ | | `mdm.apple.deviceUser.notify` | [`GET /mdm/apple/enterprise/devices/:admDeviceId/users/:admDeviceUserId/notify`](https://docs.applivery.com/en/api/apple/devices/users/get-notify/) | ✓ | ✓ | ✓ | – | | `mdm.apple.deviceUser.refresh` | [`GET /mdm/apple/enterprise/devices/:admDeviceId/users/:admDeviceUserId/refresh`](https://docs.applivery.com/en/api/apple/devices/users/get-refresh/) | ✓ | ✓ | ✓ | – | | `mdm.apple.deviceUser.remove` | — | ✓ | ✓ | – | – | | `mdm.apple.deviceUser.sync` | [`GET /mdm/apple/enterprise/devices/:admDeviceId/users/:admDeviceUserId/sync`](https://docs.applivery.com/en/api/apple/devices/users/get-sync/) | ✓ | ✓ | ✓ | – | | `mdm.apple.deviceUser.update` | [`PUT /mdm/apple/enterprise/devices/:admDeviceId/users/:admDeviceUserId`](https://docs.applivery.com/en/api/apple/devices/users/put-user/) | ✓ | ✓ | – | – | | `mdm.apple.enrollmentTemplate.create` | [`POST /mdm/apple/enterprise/enrollment-templates`](https://docs.applivery.com/en/api/apple/enrollment-templates/post-enrollment-template/) | ✓ | ✓ | ✓ | – | | `mdm.apple.enrollmentTemplate.get` | [`GET /mdm/apple/enterprise/enrollment-templates/:admEnrollmentTemplateId`](https://docs.applivery.com/en/api/apple/enrollment-templates/get-enrollment-template/)
[`GET /mdm/apple/enterprise/enrollment-templates/:admEnrollmentTemplateId/assignations`](https://docs.applivery.com/en/api/apple/enrollment-templates/get-assignations/) | ✓ | ✓ | ✓ | ✓ | | `mdm.apple.enrollmentTemplate.list` | [`GET /mdm/apple/enterprise/enrollment-templates`](https://docs.applivery.com/en/api/apple/enrollment-templates/get-enrollment-templates/) | ✓ | ✓ | ✓ | ✓ | | `mdm.apple.enrollmentTemplate.remove` | [`DELETE /mdm/apple/enterprise/enrollment-templates/:admEnrollmentTemplateId`](https://docs.applivery.com/en/api/apple/enrollment-templates/delete-enrollment-template/) | ✓ | ✓ | – | – | | `mdm.apple.enrollmentTemplate.templates` | — | ✓ | ✓ | – | – | | `mdm.apple.enrollmentTemplate.update` | [`PUT /mdm/apple/enterprise/enrollment-templates/:admEnrollmentTemplateId`](https://docs.applivery.com/en/api/apple/enrollment-templates/put-enrollment-template/) | ✓ | ✓ | ✓ | – | | `mdm.apple.enrollmentToken.create` | [`POST /mdm/apple/enterprise/enrollment-tokens`](https://docs.applivery.com/en/api/apple/enrollment-tokens/post-enrollment-token/)
[`POST /mdm/apple/enterprise/enrollment-tokens/bulk`](https://docs.applivery.com/en/api/apple/enrollment-tokens/post-bulk/) | ✓ | ✓ | – | – | | `mdm.apple.enrollmentToken.get` | [`GET /mdm/apple/enterprise/enrollment-tokens/:admEnrollmentTokenId`](https://docs.applivery.com/en/api/apple/enrollment-tokens/get-enrollment-token/) | ✓ | ✓ | ✓ | ✓ | | `mdm.apple.enrollmentToken.list` | [`GET /mdm/apple/enterprise/enrollment-tokens`](https://docs.applivery.com/en/api/apple/enrollment-tokens/get-enrollment-tokens/) | ✓ | ✓ | ✓ | ✓ | | `mdm.apple.enrollmentToken.remove` | [`DELETE /mdm/apple/enterprise/enrollment-tokens/:admEnrollmentTokenId`](https://docs.applivery.com/en/api/apple/enrollment-tokens/delete-enrollment-token/) | ✓ | ✓ | – | – | | `mdm.apple.enrollmentToken.update` | [`PUT /mdm/apple/enterprise/enrollment-tokens/:admEnrollmentTokenId`](https://docs.applivery.com/en/api/apple/enrollment-tokens/put-enrollment-token/) | ✓ | ✓ | ✓ | – | | `mdm.apple.enterprise.applepush` | — | ✓ | ✓ | – | – | | `mdm.apple.enterprise.create` | [`POST /mdm/apple/enterprise`](https://docs.applivery.com/en/api/apple/enterprise/post-enterprise/) | ✓ | ✓ | – | – | | `mdm.apple.enterprise.get` | [`GET /mdm/apple/enterprise`](https://docs.applivery.com/en/api/apple/enterprise/get-enterprise/) | ✓ | ✓ | ✓ | ✓ | | `mdm.apple.enterprise.reinstallDevices` | [`GET /mdm/apple/enterprise/reinstall-devices`](https://docs.applivery.com/en/api/apple/enterprise/get-reinstall-devices/) | ✓ | ✓ | – | – | | `mdm.apple.enterprise.search` | [`GET /mdm/apple/enterprise/search`](https://docs.applivery.com/en/api/apple/enterprise/get-search/)
[`POST /mdm/apple/enterprise/search-bundle-ids`](https://docs.applivery.com/en/api/apple/enterprise/post-search-bundle-ids/) | ✓ | ✓ | ✓ | ✓ | | `mdm.apple.enterprise.update` | [`PUT /mdm/apple/enterprise`](https://docs.applivery.com/en/api/apple/enterprise/put-enterprise/)
[`PUT /mdm/apple/enterprise/dep`](https://docs.applivery.com/en/api/apple/enterprise/put-dep/) | ✓ | ✓ | – | – | | `mdm.apple.enterprise.uploadIdentity` | — | ✓ | ✓ | – | – | | `mdm.apple.policy.composition` | [`POST /mdm/apple/enterprise/policies/composition`](https://docs.applivery.com/en/api/apple/policies/post-composition/) | ✓ | ✓ | ✓ | ✓ | | `mdm.apple.policy.create` | [`POST /mdm/apple/enterprise/policies`](https://docs.applivery.com/en/api/apple/policies/post-policy/) | ✓ | ✓ | ✓ | – | | `mdm.apple.policy.get` | [`GET /mdm/apple/enterprise/policies/:admPolicyId`](https://docs.applivery.com/en/api/apple/policies/get-policy/)
[`GET /mdm/apple/enterprise/policies/:admPolicyId/agent-config`](https://docs.applivery.com/en/api/apple/policies/get-agent-config/)
[`GET /mdm/apple/enterprise/policies/:admPolicyId/assignations`](https://docs.applivery.com/en/api/apple/policies/get-assignations/)
`GET /mdm/apple/enterprise/policies/:admPolicyId/provisioning-profiles/:UUID` | ✓ | ✓ | ✓ | ✓ | | `mdm.apple.policy.list` | [`GET /mdm/apple/enterprise/policies`](https://docs.applivery.com/en/api/apple/policies/get-policies/) | ✓ | ✓ | ✓ | ✓ | | `mdm.apple.policy.remove` | [`DELETE /mdm/apple/enterprise/policies/:admPolicyId`](https://docs.applivery.com/en/api/apple/policies/delete-policy/) | ✓ | ✓ | – | – | | `mdm.apple.policy.templates` | [`GET /mdm/apple/enterprise/policies/templates`](https://docs.applivery.com/en/api/apple/policies/templates/get/)
[`GET /mdm/apple/enterprise/policies/templates/:templateId`](https://docs.applivery.com/en/api/apple/policies/templates/get-by-id/) | ✓ | ✓ | – | – | | `mdm.apple.policy.update` | [`PUT /mdm/apple/enterprise/policies/:admPolicyId`](https://docs.applivery.com/en/api/apple/policies/put-policy/) | ✓ | ✓ | ✓ | – | | `mdm.apple.profile.create` | [`POST /mdm/apple/enterprise/profiles`](https://docs.applivery.com/en/api/apple/profiles/post-profile/) | ✓ | ✓ | – | – | | `mdm.apple.profile.get` | [`GET /mdm/apple/enterprise/profiles/:admProfileId`](https://docs.applivery.com/en/api/apple/profiles/get-profile/) | ✓ | ✓ | ✓ | ✓ | | `mdm.apple.profile.list` | [`GET /mdm/apple/enterprise/profiles`](https://docs.applivery.com/en/api/apple/profiles/get-profiles/) | ✓ | ✓ | ✓ | ✓ | | `mdm.apple.profile.remove` | [`DELETE /mdm/apple/enterprise/profiles/:admProfileId`](https://docs.applivery.com/en/api/apple/profiles/delete-profile/) | ✓ | ✓ | – | – | | `mdm.apple.profile.update` | [`PUT /mdm/apple/enterprise/profiles/:admProfileId`](https://docs.applivery.com/en/api/apple/profiles/put-profile/) | ✓ | ✓ | – | – | | `mdm.apple.router.get` | [`GET /mdm/apple/enterprise/router/:admRouterId`](https://docs.applivery.com/en/api/apple/router/get-router-by-id/) | ✓ | ✓ | ✓ | ✓ | | `mdm.apple.router.list` | [`GET /mdm/apple/enterprise/router`](https://docs.applivery.com/en/api/apple/router/get-router/) | ✓ | ✓ | ✓ | ✓ | | `mdm.apple.syncHistory.list` | [`GET /mdm/apple/enterprise/sync-history/:targetType/:targetId`](https://docs.applivery.com/en/api/apple/sync-history/get-sync-history/) | ✓ | ✓ | ✓ | ✓ | | `mdm.apple.vppAsset.assignments` | [`GET /mdm/apple/enterprise/vpp/locations/:admVppLocationId/assets/assignments`](https://docs.applivery.com/en/api/apple/locations/assets/get-assignments/) | ✓ | ✓ | ✓ | – | | `mdm.apple.vppAsset.associate` | [`POST /mdm/apple/enterprise/vpp/locations/:admVppLocationId/assets/associate`](https://docs.applivery.com/en/api/apple/locations/assets/post-associate/) | ✓ | ✓ | ✓ | – | | `mdm.apple.vppAsset.disassociate` | [`POST /mdm/apple/enterprise/vpp/locations/:admVppLocationId/assets/disassociate`](https://docs.applivery.com/en/api/apple/locations/assets/post-disassociate/) | ✓ | ✓ | ✓ | – | | `mdm.apple.vppAsset.list` | [`GET /mdm/apple/enterprise/vpp/locations/:admVppLocationId/assets`](https://docs.applivery.com/en/api/apple/locations/assets/get/) | ✓ | ✓ | ✓ | – | | `mdm.apple.vppAsset.revoke` | [`POST /mdm/apple/enterprise/vpp/locations/:admVppLocationId/assets/revoke`](https://docs.applivery.com/en/api/apple/locations/assets/post-revoke/) | ✓ | ✓ | ✓ | – | | `mdm.apple.vppEvent.check` | [`GET /mdm/apple/enterprise/vpp/locations/:admVppLocationId/events/check/:eventId`](https://docs.applivery.com/en/api/apple/event-check/get-check/) | ✓ | ✓ | ✓ | – | | `mdm.apple.vppLocation.create` | [`POST /mdm/apple/enterprise/vpp/locations`](https://docs.applivery.com/en/api/apple/locations/post-location/) | ✓ | ✓ | – | – | | `mdm.apple.vppLocation.get` | [`GET /mdm/apple/enterprise/vpp/locations/:admVppLocationId`](https://docs.applivery.com/en/api/apple/locations/get-location/) | ✓ | ✓ | ✓ | – | | `mdm.apple.vppLocation.list` | [`GET /mdm/apple/enterprise/vpp/locations`](https://docs.applivery.com/en/api/apple/locations/get-locations/) | ✓ | ✓ | ✓ | – | | `mdm.apple.vppLocation.remove` | [`DELETE /mdm/apple/enterprise/vpp/locations/:admVppLocationId`](https://docs.applivery.com/en/api/apple/locations/delete-location/) | ✓ | ✓ | – | – | | `mdm.apple.vppLocation.update` | — | ✓ | ✓ | – | – | | `mdm.apple.vppUser.create` | [`POST /mdm/apple/enterprise/vpp/locations/:admVppLocationId/users`](https://docs.applivery.com/en/api/apple/locations/users/post/) | ✓ | ✓ | ✓ | – | | `mdm.apple.vppUser.get` | — | ✓ | ✓ | ✓ | – | | `mdm.apple.vppUser.list` | [`GET /mdm/apple/enterprise/vpp/locations/:admVppLocationId/users`](https://docs.applivery.com/en/api/apple/locations/users/get/)
[`GET /mdm/apple/enterprise/vpp/locations/:admVppLocationId/users/all`](https://docs.applivery.com/en/api/apple/locations/users/get-all/) | ✓ | ✓ | ✓ | – | | `mdm.apple.vppUser.retire` | [`DELETE /mdm/apple/enterprise/vpp/locations/:admVppLocationId/users/:mdmUserId`](https://docs.applivery.com/en/api/apple/locations/users/delete-by-id/) | ✓ | ✓ | ✓ | – | | `mdm.apple.vppUser.update` | — | ✓ | ✓ | ✓ | – | **Android Enterprise (mdm.android) · 60 actions, 70 endpoints** | Permission | Endpoints | O | A | E | V | | --- | --- | :-: | :-: | :-: | :-: | | `mdm.android.application.create` | [`POST /mdm/android/enterprise/applications/emm-application`](https://docs.applivery.com/en/api/android/applications/post-application/) | ✓ | ✓ | ✓ | – | | `mdm.android.application.get` | [`GET /mdm/android/enterprise/applications/emm-application/:emmApplicationId`](https://docs.applivery.com/en/api/android/applications/get-application/) | ✓ | ✓ | ✓ | ✓ | | `mdm.android.application.getApplication` | [`GET /mdm/android/enterprise/applications/:applicationName`](https://docs.applivery.com/en/api/android/applications/get-by-name/) | ✓ | ✓ | ✓ | ✓ | | `mdm.android.application.list` | [`GET /mdm/android/enterprise/applications/emm-application`](https://docs.applivery.com/en/api/android/applications/get-applications/) | ✓ | ✓ | ✓ | ✓ | | `mdm.android.application.remove` | [`DELETE /mdm/android/enterprise/applications/emm-application/:emmApplicationId`](https://docs.applivery.com/en/api/android/applications/delete-application/) | ✓ | ✓ | – | – | | `mdm.android.application.update` | [`PUT /mdm/android/enterprise/applications/emm-application/:emmApplicationId`](https://docs.applivery.com/en/api/android/applications/put-application/) | ✓ | ✓ | ✓ | – | | `mdm.android.certificateReport.get` | [`GET /mdm/android/enterprise/devices/:emmDeviceId/certificate-reports/history/:historyId`](https://docs.applivery.com/en/api/android/certificate-report/history/get-by-id/) | ✓ | ✓ | ✓ | ✓ | | `mdm.android.certificateReport.list` | [`GET /mdm/android/enterprise/devices/:emmDeviceId/certificate-reports/history`](https://docs.applivery.com/en/api/android/certificate-report/history/get/) | ✓ | ✓ | ✓ | ✓ | | `mdm.android.certificateReport.reset` | [`POST /mdm/android/enterprise/devices/:emmDeviceId/certificate-reports/reset`](https://docs.applivery.com/en/api/android/certificate-report/post-reset/) | ✓ | ✓ | – | – | | `mdm.android.command.cancel` | [`POST /mdm/android/enterprise/devices/:emmDeviceId/commands/:emmCommandId/cancel`](https://docs.applivery.com/en/api/android/commands/post-cancel/) | ✓ | ✓ | – | – | | `mdm.android.command.create` | [`POST /mdm/android/enterprise/devices/:emmDeviceId/commands`](https://docs.applivery.com/en/api/android/commands/post-command/) | ✓ | ✓ | – | – | | `mdm.android.command.get` | [`GET /mdm/android/enterprise/devices/:emmDeviceId/commands/:emmCommandId`](https://docs.applivery.com/en/api/android/commands/get-command/) | ✓ | ✓ | ✓ | – | | `mdm.android.command.list` | [`GET /mdm/android/enterprise/devices/:emmDeviceId/commands`](https://docs.applivery.com/en/api/android/commands/get-commands/) | ✓ | ✓ | ✓ | – | | `mdm.android.device.action` | [`POST /mdm/android/enterprise/devices/:emmDeviceId/action`](https://docs.applivery.com/en/api/android/devices/post-action/) | ✓ | ✓ | – | – | | `mdm.android.device.create` | — | ✓ | ✓ | – | – | | `mdm.android.device.emmCommandBulk` | [`POST /mdm/android/enterprise/devices/commands`](https://docs.applivery.com/en/api/android/devices/post-commands/) | ✓ | ✓ | – | – | | `mdm.android.device.get` | [`GET /mdm/android/enterprise/devices/:emmDeviceId`](https://docs.applivery.com/en/api/android/devices/get-device/)
[`GET /mdm/android/enterprise/devices/:emmDeviceId/agent-config`](https://docs.applivery.com/en/api/android/devices/agent/get-config/)
[`GET /mdm/android/enterprise/devices/:emmDeviceId/agent-config-assets`](https://docs.applivery.com/en/api/android/devices/agent/get-config-assets/)
[`GET /mdm/android/enterprise/devices/:emmDeviceId/agent-tokens`](https://docs.applivery.com/en/api/android/devices/agent/get-tokens/)
[`GET /mdm/android/enterprise/devices/:emmDeviceId/applications`](https://docs.applivery.com/en/api/android/devices/get-applications/)
[`GET /mdm/android/enterprise/devices/:emmDeviceId/events`](https://docs.applivery.com/en/api/android/devices/get-events/)
[`GET /mdm/android/enterprise/devices/:emmDeviceId/launcher-config`](https://docs.applivery.com/en/api/android/devices/get-launcher-config/) | ✓ | ✓ | ✓ | ✓ | | `mdm.android.device.list` | [`GET /mdm/android/enterprise/devices`](https://docs.applivery.com/en/api/android/devices/get-devices/) | ✓ | ✓ | ✓ | ✓ | | `mdm.android.device.move` | [`PUT /mdm/android/enterprise/devices/:emmDeviceId/move`](https://docs.applivery.com/en/api/android/devices/put-move/) | ✓ | ✓ | – | – | | `mdm.android.device.remove` | [`DELETE /mdm/android/enterprise/devices/:emmDeviceId`](https://docs.applivery.com/en/api/android/devices/delete-device/) | ✓ | ✓ | – | – | | `mdm.android.device.sync` | [`GET /mdm/android/enterprise/devices/:emmDeviceId/sync`](https://docs.applivery.com/en/api/android/devices/get-sync/) | ✓ | ✓ | ✓ | – | | `mdm.android.device.update` | [`PUT /mdm/android/enterprise/devices/:emmDeviceId`](https://docs.applivery.com/en/api/android/devices/put-device/) | ✓ | ✓ | ✓ | – | | `mdm.android.deviceNotification.action` | [`POST /mdm/android/enterprise/devices/:emmDeviceId/notifications`](https://docs.applivery.com/en/api/android/notifications/post-notification/) | ✓ | ✓ | – | – | | `mdm.android.directProvisioning.create` | [`POST /mdm/android/enterprise/enrollment-templates/:emmEnrollmentTemplateId/direct-provisioning`](https://docs.applivery.com/en/api/android/enrollment-templates/direct-provisioning/post/) | ✓ | ✓ | ✓ | – | | `mdm.android.directProvisioning.get` | [`GET /mdm/android/enterprise/enrollment-templates/:emmEnrollmentTemplateId/direct-provisioning/:emmDirectProvisioningId`](https://docs.applivery.com/en/api/android/enrollment-templates/direct-provisioning/get-by-id/) | ✓ | ✓ | ✓ | ✓ | | `mdm.android.directProvisioning.list` | [`GET /mdm/android/enterprise/enrollment-templates/:emmEnrollmentTemplateId/direct-provisioning`](https://docs.applivery.com/en/api/android/enrollment-templates/direct-provisioning/get/) | ✓ | ✓ | ✓ | ✓ | | `mdm.android.directProvisioning.remove` | [`DELETE /mdm/android/enterprise/enrollment-templates/:emmEnrollmentTemplateId/direct-provisioning/:emmDirectProvisioningId`](https://docs.applivery.com/en/api/android/enrollment-templates/direct-provisioning/delete-by-id/) | ✓ | ✓ | – | – | | `mdm.android.directProvisioning.update` | [`PUT /mdm/android/enterprise/enrollment-templates/:emmEnrollmentTemplateId/direct-provisioning/:emmDirectProvisioningId`](https://docs.applivery.com/en/api/android/enrollment-templates/direct-provisioning/put-by-id/) | ✓ | ✓ | ✓ | – | | `mdm.android.enrollmentTemplate.create` | [`POST /mdm/android/enterprise/enrollment-templates`](https://docs.applivery.com/en/api/android/enrollment-templates/post-enrollment-template/)
[`POST /mdm/android/enterprise/enrollment-templates/:emmEnrollmentTemplateId/notify`](https://docs.applivery.com/en/api/android/enrollment-templates/post-notify/) | ✓ | ✓ | ✓ | – | | `mdm.android.enrollmentTemplate.get` | [`GET /mdm/android/enterprise/enrollment-templates/:emmEnrollmentTemplateId`](https://docs.applivery.com/en/api/android/enrollment-templates/get-enrollment-template/) | ✓ | ✓ | ✓ | ✓ | | `mdm.android.enrollmentTemplate.list` | [`GET /mdm/android/enterprise/enrollment-templates`](https://docs.applivery.com/en/api/android/enrollment-templates/get-enrollment-templates/) | ✓ | ✓ | ✓ | ✓ | | `mdm.android.enrollmentTemplate.remove` | [`DELETE /mdm/android/enterprise/enrollment-templates/:emmEnrollmentTemplateId`](https://docs.applivery.com/en/api/android/enrollment-templates/delete-enrollment-template/) | ✓ | ✓ | – | – | | `mdm.android.enrollmentTemplate.templates` | — | ✓ | ✓ | – | – | | `mdm.android.enrollmentTemplate.update` | [`PUT /mdm/android/enterprise/enrollment-templates/:emmEnrollmentTemplateId`](https://docs.applivery.com/en/api/android/enrollment-templates/put-enrollment-template/)
[`POST /mdm/android/enterprise/enrollment-templates/:emmEnrollmentTemplateId/default-managed-domain`](https://docs.applivery.com/en/api/android/enrollment-templates/post-default-managed-domain/) | ✓ | ✓ | ✓ | – | | `mdm.android.enrollmentToken.create` | [`POST /mdm/android/enterprise/enrollment-tokens`](https://docs.applivery.com/en/api/android/enrollment-tokens/post-enrollment-token/)
[`POST /mdm/android/enterprise/enrollment-tokens/bulk`](https://docs.applivery.com/en/api/android/enrollment-tokens/post-bulk/) | ✓ | ✓ | – | – | | `mdm.android.enrollmentToken.get` | [`GET /mdm/android/enterprise/enrollment-tokens/:emmEnrollmentTokenId`](https://docs.applivery.com/en/api/android/enrollment-tokens/get-enrollment-token/) | ✓ | ✓ | ✓ | ✓ | | `mdm.android.enrollmentToken.list` | [`GET /mdm/android/enterprise/enrollment-tokens`](https://docs.applivery.com/en/api/android/enrollment-tokens/get-enrollment-tokens/) | ✓ | ✓ | ✓ | ✓ | | `mdm.android.enrollmentToken.remove` | [`DELETE /mdm/android/enterprise/enrollment-tokens/:emmEnrollmentTokenId`](https://docs.applivery.com/en/api/android/enrollment-tokens/delete-enrollment-token/) | ✓ | ✓ | – | – | | `mdm.android.enrollmentToken.update` | [`PUT /mdm/android/enterprise/enrollment-tokens/:emmEnrollmentTokenId`](https://docs.applivery.com/en/api/android/enrollment-tokens/put-enrollment-token/) | ✓ | ✓ | ✓ | – | | `mdm.android.enterprise.create` | [`POST /mdm/android/enterprise`](https://docs.applivery.com/en/api/android/enterprise/post-enterprise/) | ✓ | ✓ | – | – | | `mdm.android.enterprise.generateEnterpriseUpgradeUrl` | [`POST /mdm/android/enterprise/upgrade-url`](https://docs.applivery.com/en/api/android/enterprise/post-upgrade-url/) | ✓ | ✓ | – | – | | `mdm.android.enterprise.generateWebToken` | [`POST /mdm/android/enterprise/web-token`](https://docs.applivery.com/en/api/android/enterprise/post-web-token/) | ✓ | ✓ | – | – | | `mdm.android.enterprise.getByOrganization` | [`GET /mdm/android/enterprise`](https://docs.applivery.com/en/api/android/enterprise/get-enterprise/) | ✓ | ✓ | – | – | | `mdm.android.enterprise.remove` | [`DELETE /mdm/android/enterprise`](https://docs.applivery.com/en/api/android/enterprise/delete-enterprise/) | ✓ | ✓ | – | – | | `mdm.android.enterprise.signupUrlsCreate` | [`POST /mdm/android/enterprise/signup-url`](https://docs.applivery.com/en/api/android/enterprise/post-signup-url/) | ✓ | ✓ | – | – | | `mdm.android.enterprise.sync` | [`GET /mdm/android/enterprise/sync`](https://docs.applivery.com/en/api/android/enterprise/get-sync/) | ✓ | ✓ | – | – | | `mdm.android.enterprise.update` | [`PUT /mdm/android/enterprise`](https://docs.applivery.com/en/api/android/enterprise/put-enterprise/) | ✓ | ✓ | – | – | | `mdm.android.package.get` | [`GET /mdm/android/enterprise/packages/:packageName`](https://docs.applivery.com/en/api/platform/package-information/get-package/) | ✓ | ✓ | ✓ | ✓ | | `mdm.android.policy.composition` | [`POST /mdm/android/enterprise/policies/composition`](https://docs.applivery.com/en/api/android/policies/post-composition/) | ✓ | ✓ | ✓ | ✓ | | `mdm.android.policy.create` | [`POST /mdm/android/enterprise/policies`](https://docs.applivery.com/en/api/android/policies/post-policy/) | ✓ | ✓ | ✓ | – | | `mdm.android.policy.get` | [`GET /mdm/android/enterprise/policies/:emmPolicyId`](https://docs.applivery.com/en/api/android/policies/get-policy/)
[`GET /mdm/android/enterprise/policies/:emmPolicyId/agent-config`](https://docs.applivery.com/en/api/android/policies/get-agent-config/)
[`GET /mdm/android/enterprise/policies/:emmPolicyId/assignations`](https://docs.applivery.com/en/api/android/policies/get-assignations/) | ✓ | ✓ | ✓ | ✓ | | `mdm.android.policy.list` | [`GET /mdm/android/enterprise/policies`](https://docs.applivery.com/en/api/android/policies/get-policies/) | ✓ | ✓ | ✓ | ✓ | | `mdm.android.policy.remove` | [`DELETE /mdm/android/enterprise/policies/:emmPolicyId`](https://docs.applivery.com/en/api/android/policies/delete-policy/) | ✓ | ✓ | – | – | | `mdm.android.policy.templates` | [`GET /mdm/android/enterprise/policies/templates`](https://docs.applivery.com/en/api/android/policies/templates/get/)
[`GET /mdm/android/enterprise/policies/templates/:templateId`](https://docs.applivery.com/en/api/android/policies/templates/get-by-id/) | ✓ | ✓ | – | – | | `mdm.android.policy.update` | [`PUT /mdm/android/enterprise/policies/:emmPolicyId`](https://docs.applivery.com/en/api/android/policies/put-policy/) | ✓ | ✓ | ✓ | – | | `mdm.android.webApp.create` | [`POST /mdm/android/enterprise/web-apps`](https://docs.applivery.com/en/api/android/web-apps/post-web-app/) | ✓ | ✓ | ✓ | – | | `mdm.android.webApp.get` | [`GET /mdm/android/enterprise/web-apps/:emmWebAppId`](https://docs.applivery.com/en/api/android/web-apps/get-web-app/) | ✓ | ✓ | ✓ | ✓ | | `mdm.android.webApp.list` | [`GET /mdm/android/enterprise/web-apps`](https://docs.applivery.com/en/api/android/web-apps/get-web-apps/) | ✓ | ✓ | ✓ | ✓ | | `mdm.android.webApp.remove` | [`DELETE /mdm/android/enterprise/web-apps/:emmWebAppId`](https://docs.applivery.com/en/api/android/web-apps/delete-web-app/) | ✓ | ✓ | – | – | | `mdm.android.webApp.update` | [`PUT /mdm/android/enterprise/web-apps/:emmWebAppId`](https://docs.applivery.com/en/api/android/web-apps/put-web-app/) | ✓ | ✓ | ✓ | – | **AOSP (mdm.aosp) · 34 actions, 46 endpoints** | Permission | Endpoints | O | A | E | V | | --- | --- | :-: | :-: | :-: | :-: | | `mdm.aosp.application.create` | [`POST /mdm/aosp/enterprise/applications`](https://docs.applivery.com/en/api/aosp/applications/post-application/) | ✓ | ✓ | ✓ | – | | `mdm.aosp.application.get` | [`GET /mdm/aosp/enterprise/applications/:aosApplicationId`](https://docs.applivery.com/en/api/aosp/applications/get-application/) | ✓ | ✓ | ✓ | ✓ | | `mdm.aosp.application.list` | [`GET /mdm/aosp/enterprise/applications`](https://docs.applivery.com/en/api/aosp/applications/get-applications/) | ✓ | ✓ | ✓ | ✓ | | `mdm.aosp.application.remove` | [`DELETE /mdm/aosp/enterprise/applications/:aosApplicationId`](https://docs.applivery.com/en/api/aosp/applications/delete-application/) | ✓ | ✓ | – | – | | `mdm.aosp.application.update` | [`PUT /mdm/aosp/enterprise/applications/:aosApplicationId`](https://docs.applivery.com/en/api/aosp/applications/put-application/) | ✓ | ✓ | ✓ | – | | `mdm.aosp.command.cancel` | [`POST /mdm/aosp/enterprise/devices/:aosDeviceId/commands/:aosCommandId/cancel`](https://docs.applivery.com/en/api/aosp/commands/post-cancel/) | ✓ | ✓ | – | – | | `mdm.aosp.command.create` | [`POST /mdm/aosp/enterprise/devices/:aosDeviceId/commands`](https://docs.applivery.com/en/api/aosp/commands/post-command/) | ✓ | ✓ | – | – | | `mdm.aosp.command.get` | [`GET /mdm/aosp/enterprise/devices/:aosDeviceId/commands/:aosCommandId`](https://docs.applivery.com/en/api/aosp/commands/get-command/)
[`GET /mdm/aosp/enterprise/devices/:aosDeviceId/commands/:aosCommandId/push-status`](https://docs.applivery.com/en/api/aosp/commands/get-push-status/) | ✓ | ✓ | ✓ | – | | `mdm.aosp.command.list` | [`GET /mdm/aosp/enterprise/devices/:aosDeviceId/commands`](https://docs.applivery.com/en/api/aosp/commands/get-commands/) | ✓ | ✓ | ✓ | – | | `mdm.aosp.device.get` | [`GET /mdm/aosp/enterprise/devices/:aosDeviceId`](https://docs.applivery.com/en/api/aosp/devices/get-device/)
[`GET /mdm/aosp/enterprise/devices/:aosDeviceId/agent-config`](https://docs.applivery.com/en/api/aosp/devices/agent/get-config/)
[`GET /mdm/aosp/enterprise/devices/:aosDeviceId/agent-config-assets`](https://docs.applivery.com/en/api/aosp/devices/agent/get-config-assets/)
[`GET /mdm/aosp/enterprise/devices/:aosDeviceId/applications`](https://docs.applivery.com/en/api/aosp/devices/get-applications/) | ✓ | ✓ | ✓ | ✓ | | `mdm.aosp.device.list` | [`GET /mdm/aosp/enterprise/devices`](https://docs.applivery.com/en/api/aosp/devices/get-devices/) | ✓ | ✓ | ✓ | ✓ | | `mdm.aosp.device.move` | [`PUT /mdm/aosp/enterprise/devices/:aosDeviceId/move`](https://docs.applivery.com/en/api/aosp/devices/put-move/) | ✓ | ✓ | – | – | | `mdm.aosp.device.remove` | [`DELETE /mdm/aosp/enterprise/devices/:aosDeviceId`](https://docs.applivery.com/en/api/aosp/devices/delete-device/) | ✓ | ✓ | – | – | | `mdm.aosp.device.update` | [`PUT /mdm/aosp/enterprise/devices/:aosDeviceId`](https://docs.applivery.com/en/api/aosp/devices/put-device/)
[`POST /mdm/aosp/enterprise/devices/:aosDeviceId/check-update`](https://docs.applivery.com/en/api/aosp/devices/post-check-update/)
[`POST /mdm/aosp/enterprise/devices/:aosDeviceId/report-status`](https://docs.applivery.com/en/api/aosp/devices/post-report-status/)
[`POST /mdm/aosp/enterprise/devices/:aosDeviceId/send-logs`](https://docs.applivery.com/en/api/aosp/devices/post-send-logs/) | ✓ | ✓ | ✓ | – | | `mdm.aosp.enrollmentTemplate.create` | `POST /mdm/aosp/enterprise/enrollment-templates` | ✓ | ✓ | ✓ | – | | `mdm.aosp.enrollmentTemplate.get` | `GET /mdm/aosp/enterprise/enrollment-templates/:aosEnrollmentTemplateId` | ✓ | ✓ | ✓ | ✓ | | `mdm.aosp.enrollmentTemplate.list` | `GET /mdm/aosp/enterprise/enrollment-templates` | ✓ | ✓ | ✓ | ✓ | | `mdm.aosp.enrollmentTemplate.remove` | `DELETE /mdm/aosp/enterprise/enrollment-templates/:aosEnrollmentTemplateId` | ✓ | ✓ | – | – | | `mdm.aosp.enrollmentTemplate.update` | `PUT /mdm/aosp/enterprise/enrollment-templates/:aosEnrollmentTemplateId` | ✓ | ✓ | ✓ | – | | `mdm.aosp.enrollmentToken.create` | [`POST /mdm/aosp/enterprise/enrollment-tokens`](https://docs.applivery.com/en/api/aosp/enrollment-tokens/post-enrollment-token/)
[`POST /mdm/aosp/enterprise/enrollment-tokens/bulk`](https://docs.applivery.com/en/api/aosp/enrollment-tokens/post-bulk/) | ✓ | ✓ | – | – | | `mdm.aosp.enrollmentToken.get` | [`GET /mdm/aosp/enterprise/enrollment-tokens/:aosEnrollmentTokenId`](https://docs.applivery.com/en/api/aosp/enrollment-tokens/get-enrollment-token/) | ✓ | ✓ | ✓ | ✓ | | `mdm.aosp.enrollmentToken.list` | [`GET /mdm/aosp/enterprise/enrollment-tokens`](https://docs.applivery.com/en/api/aosp/enrollment-tokens/get-enrollment-tokens/)
[`GET /mdm/aosp/enterprise/enrollment-tokens/dpc-build-tags`](https://docs.applivery.com/en/api/aosp/enrollment-tokens/get-dpc-build-tags/) | ✓ | ✓ | ✓ | ✓ | | `mdm.aosp.enrollmentToken.remove` | [`DELETE /mdm/aosp/enterprise/enrollment-tokens/:aosEnrollmentTokenId`](https://docs.applivery.com/en/api/aosp/enrollment-tokens/delete-enrollment-token/) | ✓ | ✓ | – | – | | `mdm.aosp.enrollmentToken.update` | [`PUT /mdm/aosp/enterprise/enrollment-tokens/:aosEnrollmentTokenId`](https://docs.applivery.com/en/api/aosp/enrollment-tokens/put-enrollment-token/) | ✓ | ✓ | ✓ | – | | `mdm.aosp.enterprise.create` | [`POST /mdm/aosp/enterprise`](https://docs.applivery.com/en/api/aosp/enterprise/post-enterprise/) | ✓ | ✓ | – | – | | `mdm.aosp.enterprise.get` | [`GET /mdm/aosp/enterprise`](https://docs.applivery.com/en/api/aosp/enterprise/get-enterprise/) | ✓ | ✓ | – | – | | `mdm.aosp.enterprise.remove` | [`DELETE /mdm/aosp/enterprise`](https://docs.applivery.com/en/api/aosp/enterprise/delete-enterprise/) | ✓ | ✓ | – | – | | `mdm.aosp.enterprise.update` | [`PUT /mdm/aosp/enterprise`](https://docs.applivery.com/en/api/aosp/enterprise/put-enterprise/) | ✓ | ✓ | – | – | | `mdm.aosp.policy.composition` | [`POST /mdm/aosp/enterprise/policies/composition`](https://docs.applivery.com/en/api/aosp/policies/post-composition/) | ✓ | ✓ | ✓ | ✓ | | `mdm.aosp.policy.create` | [`POST /mdm/aosp/enterprise/policies`](https://docs.applivery.com/en/api/aosp/policies/post-policy/) | ✓ | ✓ | ✓ | – | | `mdm.aosp.policy.get` | [`GET /mdm/aosp/enterprise/policies/:aosPolicyId`](https://docs.applivery.com/en/api/aosp/policies/get-policy/)
[`GET /mdm/aosp/enterprise/policies/:aosPolicyId/agent-config`](https://docs.applivery.com/en/api/aosp/policies/get-agent-config/)
[`GET /mdm/aosp/enterprise/policies/templates/:templateId`](https://docs.applivery.com/en/api/aosp/policies/templates/get-by-id/) | ✓ | ✓ | ✓ | ✓ | | `mdm.aosp.policy.list` | [`GET /mdm/aosp/enterprise/policies`](https://docs.applivery.com/en/api/aosp/policies/get-policies/)
[`GET /mdm/aosp/enterprise/policies/templates`](https://docs.applivery.com/en/api/aosp/policies/templates/get/) | ✓ | ✓ | ✓ | ✓ | | `mdm.aosp.policy.remove` | [`DELETE /mdm/aosp/enterprise/policies/:aosPolicyId`](https://docs.applivery.com/en/api/aosp/policies/delete-policy/) | ✓ | ✓ | – | – | | `mdm.aosp.policy.update` | [`PUT /mdm/aosp/enterprise/policies/:aosPolicyId`](https://docs.applivery.com/en/api/aosp/policies/put-policy/) | ✓ | ✓ | ✓ | – | **Windows (mdm.windows) · 60 actions, 70 endpoints** | Permission | Endpoints | O | A | E | V | | --- | --- | :-: | :-: | :-: | :-: | | `mdm.windows.admxConfig.create` | [`POST /mdm/windows/enterprise/admx-configs`](https://docs.applivery.com/en/api/windows/admx-configs/post-admx-config/) | ✓ | ✓ | ✓ | – | | `mdm.windows.admxConfig.get` | [`GET /mdm/windows/enterprise/admx-configs/:winAdmxConfigId`](https://docs.applivery.com/en/api/windows/admx-configs/get-admx-config/)
[`GET /mdm/windows/enterprise/admx-configs/:winAdmxConfigId/assignations`](https://docs.applivery.com/en/api/windows/admx-configs/get-assignations/) | ✓ | ✓ | ✓ | ✓ | | `mdm.windows.admxConfig.list` | [`GET /mdm/windows/enterprise/admx-configs`](https://docs.applivery.com/en/api/windows/admx-configs/get-admx-configs/) | ✓ | ✓ | ✓ | ✓ | | `mdm.windows.admxConfig.regenerate` | [`GET /mdm/windows/enterprise/admx-configs/:winAdmxConfigId/regenerate`](https://docs.applivery.com/en/api/windows/admx-configs/get-regenerate/) | ✓ | ✓ | – | – | | `mdm.windows.admxConfig.remove` | [`DELETE /mdm/windows/enterprise/admx-configs/:winAdmxConfigId`](https://docs.applivery.com/en/api/windows/admx-configs/delete-admx-config/) | ✓ | ✓ | – | – | | `mdm.windows.admxConfig.update` | — | ✓ | ✓ | ✓ | – | | `mdm.windows.application.create` | [`POST /mdm/windows/enterprise/applications`](https://docs.applivery.com/en/api/windows/applications/post-application/) | ✓ | ✓ | ✓ | – | | `mdm.windows.application.get` | [`GET /mdm/windows/enterprise/applications/:winApplicationId`](https://docs.applivery.com/en/api/windows/applications/get-application/) | ✓ | ✓ | ✓ | ✓ | | `mdm.windows.application.list` | [`GET /mdm/windows/enterprise/applications`](https://docs.applivery.com/en/api/windows/applications/get-applications/) | ✓ | ✓ | ✓ | ✓ | | `mdm.windows.application.remove` | [`DELETE /mdm/windows/enterprise/applications/:winApplicationId`](https://docs.applivery.com/en/api/windows/applications/delete-application/) | ✓ | ✓ | – | – | | `mdm.windows.application.search` | [`GET /mdm/windows/enterprise/applications/search`](https://docs.applivery.com/en/api/windows/applications/get-search/) | ✓ | ✓ | ✓ | ✓ | | `mdm.windows.application.update` | [`PUT /mdm/windows/enterprise/applications/:winApplicationId`](https://docs.applivery.com/en/api/windows/applications/put-application/) | ✓ | ✓ | ✓ | – | | `mdm.windows.command.cancel` | [`POST /mdm/windows/enterprise/devices/:winDeviceId/commands/:winCommandId/:cmdId/cancel`](https://docs.applivery.com/en/api/windows/commands/post-cancel/) | ✓ | ✓ | – | – | | `mdm.windows.command.create` | [`POST /mdm/windows/enterprise/devices/:winDeviceId/commands`](https://docs.applivery.com/en/api/windows/commands/post-command/) | ✓ | ✓ | – | – | | `mdm.windows.command.get` | [`GET /mdm/windows/enterprise/devices/:winDeviceId/commands/:winCommandId`](https://docs.applivery.com/en/api/windows/commands/get-command/)
[`GET /mdm/windows/enterprise/devices/:winDeviceId/commands/:winCommandId/actions`](https://docs.applivery.com/en/api/windows/commands/get-actions/) | ✓ | ✓ | ✓ | – | | `mdm.windows.command.list` | [`GET /mdm/windows/enterprise/devices/:winDeviceId/commands`](https://docs.applivery.com/en/api/windows/commands/get-commands/) | ✓ | ✓ | ✓ | – | | `mdm.windows.defaultDeviceConfig.create` | [`POST /mdm/windows/enterprise/default-config`](https://docs.applivery.com/en/api/windows/default-config/post-default-config/) | ✓ | ✓ | – | – | | `mdm.windows.defaultDeviceConfig.get` | [`GET /mdm/windows/enterprise/default-config/:winDefaultDeviceConfigId`](https://docs.applivery.com/en/api/windows/default-config/get-default-config-by-id/) | ✓ | ✓ | – | – | | `mdm.windows.defaultDeviceConfig.list` | [`GET /mdm/windows/enterprise/default-config`](https://docs.applivery.com/en/api/windows/default-config/get-default-config/) | ✓ | ✓ | – | – | | `mdm.windows.defaultDeviceConfig.remove` | [`DELETE /mdm/windows/enterprise/default-config/:winDefaultDeviceConfigId`](https://docs.applivery.com/en/api/windows/default-config/delete-default-config-by-id/) | ✓ | ✓ | – | – | | `mdm.windows.defaultDeviceConfig.update` | [`PUT /mdm/windows/enterprise/default-config/:winDefaultDeviceConfigId`](https://docs.applivery.com/en/api/windows/default-config/put-default-config-by-id/) | ✓ | ✓ | – | – | | `mdm.windows.device.action` | [`POST /mdm/windows/enterprise/devices/:winDeviceId/action`](https://docs.applivery.com/en/api/windows/devices/post-action/) | ✓ | ✓ | – | – | | `mdm.windows.device.cleanCache` | [`POST /mdm/windows/enterprise/devices/:winDeviceId/clean-cache`](https://docs.applivery.com/en/api/windows/devices/post-clean-cache/) | ✓ | ✓ | – | – | | `mdm.windows.device.create` | — | ✓ | ✓ | – | – | | `mdm.windows.device.get` | [`GET /mdm/windows/enterprise/devices/:winDeviceId`](https://docs.applivery.com/en/api/windows/devices/get-device/)
[`GET /mdm/windows/enterprise/devices/:winDeviceId/agent-config`](https://docs.applivery.com/en/api/windows/devices/get-agent-config/)
[`GET /mdm/windows/enterprise/devices/:winDeviceId/agent-config-assets`](https://docs.applivery.com/en/api/windows/devices/get-agent-config-assets/)
[`GET /mdm/windows/enterprise/devices/:winDeviceId/agent-tokens`](https://docs.applivery.com/en/api/windows/devices/get-agent-tokens/)
[`GET /mdm/windows/enterprise/devices/:winDeviceId/applications`](https://docs.applivery.com/en/api/windows/devices/applications/get/)
[`GET /mdm/windows/enterprise/devices/:winDeviceId/applications/history`](https://docs.applivery.com/en/api/windows/devices/applications/get-history/)
[`GET /mdm/windows/enterprise/devices/:winDeviceId/scheduler-scripts`](https://docs.applivery.com/en/api/windows/devices/get-scheduler-scripts/) | ✓ | ✓ | ✓ | ✓ | | `mdm.windows.device.getBitlockerRecoveryKey` | `GET /mdm/windows/enterprise/devices/:winDeviceId/bitlocker-recovery-key` | ✓ | ✓ | – | – | | `mdm.windows.device.info` | [`POST /mdm/windows/enterprise/devices/:winDeviceId/info`](https://docs.applivery.com/en/api/windows/devices/post-info/) | ✓ | ✓ | ✓ | ✓ | | `mdm.windows.device.list` | [`GET /mdm/windows/enterprise/devices`](https://docs.applivery.com/en/api/windows/devices/get-devices/) | ✓ | ✓ | ✓ | ✓ | | `mdm.windows.device.move` | [`PUT /mdm/windows/enterprise/devices/:winDeviceId/move`](https://docs.applivery.com/en/api/windows/devices/put-move/) | ✓ | ✓ | – | – | | `mdm.windows.device.remove` | [`DELETE /mdm/windows/enterprise/devices/:winDeviceId`](https://docs.applivery.com/en/api/windows/devices/delete-device/) | ✓ | ✓ | – | – | | `mdm.windows.device.update` | [`PUT /mdm/windows/enterprise/devices/:winDeviceId`](https://docs.applivery.com/en/api/windows/devices/put-device/) | ✓ | ✓ | ✓ | – | | `mdm.windows.deviceNotification.action` | `POST /mdm/windows/enterprise/devices/:winDeviceId/notifications` | ✓ | ✓ | – | – | | `mdm.windows.deviceScriptLog.get` | [`GET /mdm/windows/enterprise/devices/:winDeviceId/script-logs/:winDeviceScriptLogId`](https://docs.applivery.com/en/api/windows/devices/script-logs/get-script-log/) | ✓ | ✓ | ✓ | ✓ | | `mdm.windows.deviceScriptLog.invalidate` | [`POST /mdm/windows/enterprise/devices/:winDeviceId/script-logs/:winDeviceScriptLogId/invalidate`](https://docs.applivery.com/en/api/windows/devices/script-logs/post-invalidate/)
[`POST /mdm/windows/enterprise/devices/:winDeviceId/script-logs/invalidate-once`](https://docs.applivery.com/en/api/windows/devices/script-logs/post-invalidate-once/) | ✓ | ✓ | ✓ | ✓ | | `mdm.windows.deviceScriptLog.list` | [`GET /mdm/windows/enterprise/devices/:winDeviceId/script-logs`](https://docs.applivery.com/en/api/windows/devices/script-logs/get-script-logs/)
[`GET /mdm/windows/enterprise/devices/:winDeviceId/script-logs/summary`](https://docs.applivery.com/en/api/windows/devices/script-logs/get-summary/) | ✓ | ✓ | ✓ | ✓ | | `mdm.windows.directProvisioning.create` | [`POST /mdm/windows/enterprise/enrollment-templates/:winEnrollmentTemplateId/direct-provisionings`](https://docs.applivery.com/en/api/windows/direct-provisionings/post-direct-provisioning/) | ✓ | ✓ | ✓ | – | | `mdm.windows.directProvisioning.get` | [`GET /mdm/windows/enterprise/enrollment-templates/:winEnrollmentTemplateId/direct-provisionings/:winDirectProvisioningId`](https://docs.applivery.com/en/api/windows/direct-provisionings/get-direct-provisioning/) | ✓ | ✓ | ✓ | ✓ | | `mdm.windows.directProvisioning.list` | [`GET /mdm/windows/enterprise/enrollment-templates/:winEnrollmentTemplateId/direct-provisionings`](https://docs.applivery.com/en/api/windows/direct-provisionings/get-direct-provisionings/) | ✓ | ✓ | ✓ | ✓ | | `mdm.windows.directProvisioning.remove` | [`DELETE /mdm/windows/enterprise/enrollment-templates/:winEnrollmentTemplateId/direct-provisionings/:winDirectProvisioningId`](https://docs.applivery.com/en/api/windows/direct-provisionings/delete-direct-provisioning/) | ✓ | ✓ | – | – | | `mdm.windows.directProvisioning.update` | [`PUT /mdm/windows/enterprise/enrollment-templates/:winEnrollmentTemplateId/direct-provisionings/:winDirectProvisioningId`](https://docs.applivery.com/en/api/windows/direct-provisionings/put-direct-provisioning/) | ✓ | ✓ | ✓ | – | | `mdm.windows.enrollmentTemplate.create` | [`POST /mdm/windows/enterprise/enrollment-templates`](https://docs.applivery.com/en/api/windows/enrollment-templates/post-enrollment-template/) | ✓ | ✓ | ✓ | – | | `mdm.windows.enrollmentTemplate.get` | [`GET /mdm/windows/enterprise/enrollment-templates/:winEnrollmentTemplateId`](https://docs.applivery.com/en/api/windows/enrollment-templates/get-enrollment-template/) | ✓ | ✓ | ✓ | ✓ | | `mdm.windows.enrollmentTemplate.list` | [`GET /mdm/windows/enterprise/enrollment-templates`](https://docs.applivery.com/en/api/windows/enrollment-templates/get-enrollment-templates/) | ✓ | ✓ | ✓ | ✓ | | `mdm.windows.enrollmentTemplate.remove` | [`DELETE /mdm/windows/enterprise/enrollment-templates/:winEnrollmentTemplateId`](https://docs.applivery.com/en/api/windows/enrollment-templates/delete-enrollment-template/) | ✓ | ✓ | – | – | | `mdm.windows.enrollmentTemplate.update` | [`PUT /mdm/windows/enterprise/enrollment-templates/:winEnrollmentTemplateId`](https://docs.applivery.com/en/api/windows/enrollment-templates/put-enrollment-template/) | ✓ | ✓ | ✓ | – | | `mdm.windows.enrollmentToken.create` | [`POST /mdm/windows/enterprise/enrollment-tokens`](https://docs.applivery.com/en/api/windows/enrollment-tokens/post-enrollment-token/)
[`POST /mdm/windows/enterprise/enrollment-tokens/bulk`](https://docs.applivery.com/en/api/windows/enrollment-tokens/post-bulk/) | ✓ | ✓ | – | – | | `mdm.windows.enrollmentToken.get` | [`GET /mdm/windows/enterprise/enrollment-tokens/:winEnrollmentTokenId`](https://docs.applivery.com/en/api/windows/enrollment-tokens/get-enrollment-token/) | ✓ | ✓ | ✓ | ✓ | | `mdm.windows.enrollmentToken.list` | [`GET /mdm/windows/enterprise/enrollment-tokens`](https://docs.applivery.com/en/api/windows/enrollment-tokens/get-enrollment-tokens/) | ✓ | ✓ | ✓ | ✓ | | `mdm.windows.enrollmentToken.remove` | [`DELETE /mdm/windows/enterprise/enrollment-tokens/:winEnrollmentTokenId`](https://docs.applivery.com/en/api/windows/enrollment-tokens/delete-enrollment-token/) | ✓ | ✓ | – | – | | `mdm.windows.enrollmentToken.update` | [`PUT /mdm/windows/enterprise/enrollment-tokens/:winEnrollmentTokenId`](https://docs.applivery.com/en/api/windows/enrollment-tokens/put-enrollment-token/) | ✓ | ✓ | ✓ | – | | `mdm.windows.enterprise.create` | [`POST /mdm/windows/enterprise`](https://docs.applivery.com/en/api/windows/enterprise/post-enterprise/) | ✓ | ✓ | – | – | | `mdm.windows.enterprise.get` | [`GET /mdm/windows/enterprise`](https://docs.applivery.com/en/api/windows/enterprise/get-enterprise/) | ✓ | ✓ | ✓ | ✓ | | `mdm.windows.enterprise.update` | [`PUT /mdm/windows/enterprise`](https://docs.applivery.com/en/api/windows/enterprise/put-enterprise/) | ✓ | ✓ | – | – | | `mdm.windows.policy.composition` | [`POST /mdm/windows/enterprise/policies/composition`](https://docs.applivery.com/en/api/windows/policies/post-composition/) | ✓ | ✓ | ✓ | ✓ | | `mdm.windows.policy.create` | [`POST /mdm/windows/enterprise/policies`](https://docs.applivery.com/en/api/windows/policies/post-policy/) | ✓ | ✓ | ✓ | – | | `mdm.windows.policy.default` | [`GET /mdm/windows/enterprise/policies/default`](https://docs.applivery.com/en/api/windows/policies/get-default/) | ✓ | ✓ | ✓ | ✓ | | `mdm.windows.policy.get` | [`GET /mdm/windows/enterprise/policies/:winPolicyId`](https://docs.applivery.com/en/api/windows/policies/get-policy/)
[`GET /mdm/windows/enterprise/policies/:winPolicyId/assignations`](https://docs.applivery.com/en/api/windows/policies/get-assignations/) | ✓ | ✓ | ✓ | ✓ | | `mdm.windows.policy.list` | [`GET /mdm/windows/enterprise/policies`](https://docs.applivery.com/en/api/windows/policies/get-policies/) | ✓ | ✓ | ✓ | ✓ | | `mdm.windows.policy.remove` | [`DELETE /mdm/windows/enterprise/policies/:winPolicyId`](https://docs.applivery.com/en/api/windows/policies/delete-policy/) | ✓ | ✓ | – | – | | `mdm.windows.policy.update` | [`PUT /mdm/windows/enterprise/policies/:winPolicyId`](https://docs.applivery.com/en/api/windows/policies/put-policy/) | ✓ | ✓ | ✓ | – | **Applications (mdm.application) · 2 actions, 0 endpoints** | Permission | Endpoints | O | A | E | V | | --- | --- | :-: | :-: | :-: | :-: | | `mdm.application.management.get` | — | ✓ | ✓ | ✓ | ✓ | | `mdm.application.management.list` | — | ✓ | ✓ | ✓ | ✓ | **Builds (mdm.build) · 2 actions, 0 endpoints** | Permission | Endpoints | O | A | E | V | | --- | --- | :-: | :-: | :-: | :-: | | `mdm.build.management.get` | — | ✓ | ✓ | ✓ | ✓ | | `mdm.build.management.list` | — | ✓ | ✓ | ✓ | ✓ | **Integrations (mdm.integration) · 3 actions, 3 endpoints** | Permission | Endpoints | O | A | E | V | | --- | --- | :-: | :-: | :-: | :-: | | `mdm.integration.harmonyMobile.get` | [`GET /integrations/harmony-mobile`](https://docs.applivery.com/en/api/platform/organization-integrations-harmony-mobile/get-harmony-mobile/) | ✓ | ✓ | ✓ | – | | `mdm.integration.harmonyMobile.reset` | [`DELETE /integrations/harmony-mobile`](https://docs.applivery.com/en/api/platform/organization-integrations-harmony-mobile/delete-harmony-mobile/) | ✓ | ✓ | – | – | | `mdm.integration.harmonyMobile.update` | [`PUT /integrations/harmony-mobile`](https://docs.applivery.com/en/api/platform/organization-integrations-harmony-mobile/put-harmony-mobile/) | ✓ | ✓ | – | – | **Inventory (inventory.item) · 5 actions, 9 endpoints** | Permission | Endpoints | O | A | E | V | | --- | --- | :-: | :-: | :-: | :-: | | `inventory.item.management.create` | [`POST /inventory-items`](https://docs.applivery.com/en/api/platform/inventory-item/post-inventory-item/) | ✓ | ✓ | ✓ | ✓ | | `inventory.item.management.get` | [`GET /inventory-items/:inventoryItemId`](https://docs.applivery.com/en/api/platform/inventory-item/get-inventory-item/) | ✓ | ✓ | ✓ | ✓ | | `inventory.item.management.list` | [`GET /inventory-items`](https://docs.applivery.com/en/api/platform/inventory-item/get-inventory-items/)
[`GET /inventory-items/csv`](https://docs.applivery.com/en/api/platform/inventory-item/csv/get/)
[`GET /inventory-items/csv/sample`](https://docs.applivery.com/en/api/platform/inventory-item/csv/get-sample/) | ✓ | ✓ | ✓ | ✓ | | `inventory.item.management.remove` | [`DELETE /inventory-items/:inventoryItemId`](https://docs.applivery.com/en/api/platform/inventory-item/delete-inventory-item/) | ✓ | ✓ | – | – | | `inventory.item.management.update` | [`PUT /inventory-items/:inventoryItemId`](https://docs.applivery.com/en/api/platform/inventory-item/put-inventory-item/)
[`POST /inventory-items/:inventoryItemId/notes`](https://docs.applivery.com/en/api/platform/inventory-item/notes/post/)
[`DELETE /inventory-items/:inventoryItemId/notes/:noteId`](https://docs.applivery.com/en/api/platform/inventory-item/notes/delete-by-id/) | ✓ | ✓ | ✓ | ✓ | **App Distribution** **Applications (mad.application) · 26 actions, 27 endpoints** | Permission | Endpoints | O | A | E | V | App A | App E | App V | | --- | --- | :-: | :-: | :-: | :-: | :-: | :-: | :-: | | `mad.application.configuration.create` | — | ✓ | ✓ | – | – | ✓ | – | – | | `mad.application.configuration.deleteFile` | [`DELETE /apps/:applicationId/configuration/:applicationConfigurationType/file/:applicationConfigurationFile`](https://docs.applivery.com/en/api/app-distribution/application-configurations/file/delete-by-id/) | ✓ | ✓ | – | – | ✓ | – | – | | `mad.application.configuration.get` | [`GET /apps/:applicationId/configuration/:applicationConfigurationType`](https://docs.applivery.com/en/api/app-distribution/application-configurations/get-configuration/) | ✓ | ✓ | – | – | ✓ | – | – | | `mad.application.configuration.getStatus` | [`GET /apps/:applicationId/configuration/:applicationConfigurationType/status`](https://docs.applivery.com/en/api/app-distribution/application-configurations/get-status/) | ✓ | ✓ | ✓ | – | ✓ | ✓ | – | | `mad.application.configuration.remove` | [`DELETE /apps/:applicationId/configuration/:applicationConfigurationType`](https://docs.applivery.com/en/api/app-distribution/application-configurations/delete-configuration/) | ✓ | ✓ | – | – | ✓ | – | – | | `mad.application.configuration.update` | [`PUT /apps/:applicationId/configuration/:applicationConfigurationType`](https://docs.applivery.com/en/api/app-distribution/application-configurations/put-configuration/) | ✓ | ✓ | – | – | ✓ | – | – | | `mad.application.configuration.uploadFile` | [`POST /apps/:applicationId/configuration/:applicationConfigurationType/file`](https://docs.applivery.com/en/api/app-distribution/application-configurations/file/post/) | ✓ | ✓ | – | – | ✓ | – | – | | `mad.application.management.actions` ¹ | [`GET /apps/:applicationId/actions`](https://docs.applivery.com/en/api/app-distribution/application/get-actions/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `mad.application.management.checkSlug` ¹ | [`GET /apps/check-slug/:slug`](https://docs.applivery.com/en/api/app-distribution/application/get-check-slug-by-id/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `mad.application.management.create` | [`POST /apps`](https://docs.applivery.com/en/api/app-distribution/application/post-app/) | ✓ | ✓ | – | – | – | – | – | | `mad.application.management.get` | [`GET /apps/:applicationId`](https://docs.applivery.com/en/api/app-distribution/application/get-app/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `mad.application.management.list` | [`GET /apps`](https://docs.applivery.com/en/api/app-distribution/application/get-apps/)
[`GET /apps/downloads/csv`](https://docs.applivery.com/en/api/app-distribution/application/get-downloads-csv/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `mad.application.management.listGroups` | [`GET /apps/:applicationId/groups`](https://docs.applivery.com/en/api/app-distribution/application/get-groups/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `mad.application.management.listTypes` | [`GET /apps/:applicationId/list/:applicationType`](https://docs.applivery.com/en/api/app-distribution/application/get-list-by-id/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `mad.application.management.remove` | [`DELETE /apps/:applicationId`](https://docs.applivery.com/en/api/app-distribution/application/delete-app/) | ✓ | ✓ | – | – | ✓ | – | – | | `mad.application.management.update` | [`PUT /apps/:applicationId`](https://docs.applivery.com/en/api/app-distribution/application/put-app/)
[`PUT /apps/:applicationId/picture`](https://docs.applivery.com/en/api/app-distribution/application/put-picture/) | ✓ | ✓ | – | – | ✓ | – | – | | `mad.application.notification.create` | [`POST /apps/:applicationId/notifications`](https://docs.applivery.com/en/api/app-distribution/application-notifications/post-notification/) | ✓ | ✓ | – | – | ✓ | – | – | | `mad.application.notification.get` | [`GET /apps/:applicationId/notifications/:applicationNotificationId`](https://docs.applivery.com/en/api/app-distribution/application-notifications/get-notification/) | ✓ | ✓ | ✓ | – | ✓ | ✓ | – | | `mad.application.notification.list` | [`GET /apps/:applicationId/notifications`](https://docs.applivery.com/en/api/app-distribution/application-notifications/get-notifications/) | ✓ | ✓ | ✓ | – | ✓ | ✓ | – | | `mad.application.notification.remove` | [`DELETE /apps/:applicationId/notifications/:applicationNotificationId`](https://docs.applivery.com/en/api/app-distribution/application-notifications/delete-notification/) | ✓ | ✓ | – | – | ✓ | – | – | | `mad.application.notification.update` | [`PUT /apps/:applicationId/notifications/:applicationNotificationId`](https://docs.applivery.com/en/api/app-distribution/application-notifications/put-notification/) | ✓ | ✓ | – | – | ✓ | – | – | | `mad.application.token.create` | [`POST /apps/:applicationId/tokens`](https://docs.applivery.com/en/api/app-distribution/application-integration-tokens/post-token/) | ✓ | ✓ | – | – | ✓ | – | – | | `mad.application.token.get` | [`GET /apps/:applicationId/tokens/:tokenId`](https://docs.applivery.com/en/api/app-distribution/application-integration-tokens/get-token/) | ✓ | ✓ | ✓ | – | ✓ | ✓ | – | | `mad.application.token.list` | [`GET /apps/:applicationId/tokens`](https://docs.applivery.com/en/api/app-distribution/application-integration-tokens/get-tokens/) | ✓ | ✓ | ✓ | – | ✓ | ✓ | – | | `mad.application.token.remove` | [`DELETE /apps/:applicationId/tokens/:tokenId`](https://docs.applivery.com/en/api/app-distribution/application-integration-tokens/delete-token/) | ✓ | ✓ | – | – | ✓ | – | – | | `mad.application.token.update` | [`PUT /apps/:applicationId/tokens/:tokenId`](https://docs.applivery.com/en/api/app-distribution/application-integration-tokens/put-token/) | ✓ | ✓ | – | – | ✓ | – | – | ¹ Also allowed for: `mad.application.management.actions`: Device Management Viewer; `mad.application.management.checkSlug`: No Role. **Builds (mad.build) · 12 actions, 15 endpoints** | Permission | Endpoints | O | A | E | V | App A | App E | App V | | --- | --- | :-: | :-: | :-: | :-: | :-: | :-: | :-: | | `mad.build.management.addFile` | [`POST /apps/:applicationId/builds/:buildId/edge/file`](https://docs.applivery.com/en/api/app-distribution/builds/apps-edge-file-create/) | ✓ | ✓ | – | – | ✓ | ✓ | – | | `mad.build.management.create` | [`POST /apps/:applicationId/builds`](https://docs.applivery.com/en/api/app-distribution/build/post-organizations-organizationid-apps-applicationid-builds/)
[`POST /apps/:applicationId/builds/edge/build`](https://docs.applivery.com/en/api/app-distribution/builds/apps-edge-build-create/)
[`GET /apps/:applicationId/builds/edge/prepare`](https://docs.applivery.com/en/api/app-distribution/builds/apps-edge-prepare/) | ✓ | ✓ | ✓ | – | ✓ | ✓ | – | | `mad.build.management.get` | [`GET /apps/:applicationId/builds/:buildId`](https://docs.applivery.com/en/api/app-distribution/build/get-organizations-organizationid-apps-applicationid-builds-buildid/)
[`GET /apps/:applicationId/builds/:buildId/emm-json`](https://docs.applivery.com/en/api/app-distribution/builds/apps-emm-json/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `mad.build.management.getDownloadToken` | [`GET /apps/:applicationId/builds/:buildId/downloadToken`](https://docs.applivery.com/en/api/app-distribution/builds/apps-download-token/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `mad.build.management.list` | [`GET /apps/:applicationId/builds`](https://docs.applivery.com/en/api/app-distribution/builds/apps-list/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `mad.build.management.listPackageNames` | [`GET /apps/:applicationId/builds/list/packageName`](https://docs.applivery.com/en/api/app-distribution/builds/apps-package-names/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `mad.build.management.listVersionCodes` | [`GET /apps/:applicationId/builds/list/versionCode`](https://docs.applivery.com/en/api/app-distribution/builds/apps-version-codes/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `mad.build.management.listVersionNames` | [`GET /apps/:applicationId/builds/list/versionName`](https://docs.applivery.com/en/api/app-distribution/builds/apps-version-names/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `mad.build.management.remove` | [`DELETE /apps/:applicationId/builds/:buildId`](https://docs.applivery.com/en/api/app-distribution/builds/apps-delete/) | ✓ | ✓ | – | – | ✓ | – | – | | `mad.build.management.removeFile` | [`DELETE /apps/:applicationId/builds/:buildId/files/:fileId`](https://docs.applivery.com/en/api/app-distribution/builds/apps-files-delete/) | ✓ | ✓ | – | – | ✓ | – | – | | `mad.build.management.update` | [`PUT /apps/:applicationId/builds/:buildId`](https://docs.applivery.com/en/api/app-distribution/builds/apps-update/) | ✓ | ✓ | ✓ | – | ✓ | ✓ | – | | `mad.build.management.updateFile` | [`PUT /apps/:applicationId/builds/:buildId/files/:fileId`](https://docs.applivery.com/en/api/app-distribution/builds/apps-files-update/) | ✓ | ✓ | ✓ | – | ✓ | ✓ | – | **Downloads (mad.download) · 2 actions, 8 endpoints** | Permission | Endpoints | O | A | E | V | App A | App E | App V | | --- | --- | :-: | :-: | :-: | :-: | :-: | :-: | :-: | | `mad.download.management.get` | [`GET /apps/:applicationId/builds/:buildId/downloads/:downloadId`](https://docs.applivery.com/en/api/app-distribution/build-downloads-info/get-download/)
[`GET /organizations/organizationId/apps/applicationId/downloads/:downloadId`](https://docs.applivery.com/en/api/app-distribution/application-downloads-info/get-download/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `mad.download.management.list` | [`GET /apps/:applicationId/builds/:buildId/downloads`](https://docs.applivery.com/en/api/app-distribution/build-downloads-info/get-downloads/)
[`GET /apps/:applicationId/builds/:buildId/downloads/by-user`](https://docs.applivery.com/en/api/app-distribution/build-downloads-info/get-by-user/)
[`GET /apps/:applicationId/builds/:buildId/downloads/csv`](https://docs.applivery.com/en/api/app-distribution/build-downloads-info/get-csv/)
[`GET /organizations/organizationId/apps/applicationId/downloads`](https://docs.applivery.com/en/api/app-distribution/application-downloads-info/get-downloads/)
[`GET /organizations/organizationId/apps/applicationId/downloads/by-user`](https://docs.applivery.com/en/api/app-distribution/application-downloads-info/get-by-user/)
[`GET /organizations/organizationId/apps/applicationId/downloads/csv`](https://docs.applivery.com/en/api/app-distribution/application-downloads-info/get-csv/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | **Feedback (mad.feedback) · 5 actions, 7 endpoints** | Permission | Endpoints | O | A | E | V | App A | App E | App V | | --- | --- | :-: | :-: | :-: | :-: | :-: | :-: | :-: | | `mad.feedback.management.create` | [`POST /apps/:applicationId/feedbacks`](https://docs.applivery.com/en/api/app-distribution/application-feedbacks/post-feedback/) | ✓ | ✓ | ✓ | – | ✓ | ✓ | – | | `mad.feedback.management.get` | [`GET /apps/:applicationId/feedbacks/:feedbackId`](https://docs.applivery.com/en/api/app-distribution/application-feedbacks/get-feedback/)
[`GET /apps/:applicationId/feedbacks/:feedbackId/image`](https://docs.applivery.com/en/api/app-distribution/application-feedbacks/get-image/)
[`GET /apps/:applicationId/feedbacks/:feedbackId/video`](https://docs.applivery.com/en/api/app-distribution/application-feedbacks/get-video/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `mad.feedback.management.list` | [`GET /apps/:applicationId/feedbacks`](https://docs.applivery.com/en/api/app-distribution/application-feedbacks/get-feedbacks/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `mad.feedback.management.remove` | [`DELETE /apps/:applicationId/feedbacks/:feedbackId`](https://docs.applivery.com/en/api/app-distribution/application-feedbacks/delete-feedback/) | ✓ | ✓ | ✓ | – | ✓ | ✓ | – | | `mad.feedback.management.update` | [`PUT /apps/:applicationId/feedbacks/:feedbackId`](https://docs.applivery.com/en/api/app-distribution/application-feedbacks/put-feedback/) | ✓ | ✓ | ✓ | – | ✓ | ✓ | – | **Enterprise Stores (mad.store) · 17 actions, 16 endpoints** | Permission | Endpoints | O | A | E | V | App A | App E | App V | | --- | --- | :-: | :-: | :-: | :-: | :-: | :-: | :-: | | `mad.store.management.create` | — | ✓ | ✓ | – | – | – | – | – | | `mad.store.management.get` | [`GET /stores/:storeId`](https://docs.applivery.com/en/api/platform/organization-store/get-store/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `mad.store.management.list` | [`GET /stores`](https://docs.applivery.com/en/api/platform/organization-store/get-stores/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `mad.store.management.remove` | [`DELETE /stores/:storeId`](https://docs.applivery.com/en/api/platform/organization-store/delete-store/) | ✓ | ✓ | – | – | – | – | – | | `mad.store.management.update` | [`PUT /stores/:storeId`](https://docs.applivery.com/en/api/platform/organization-store/put-store/) | ✓ | ✓ | – | – | – | – | – | | `mad.store.otpUsers.create` | [`POST /organizations/:organizationSlug/stores/:storeId/otp-users`](https://docs.applivery.com/en/api/platform/otp-users/post-otp-user/) | ✓ | ✓ | – | – | ✓ | – | – | | `mad.store.otpUsers.get` | [`GET /organizations/:organizationSlug/stores/:storeId/otp-users/:otpUserId`](https://docs.applivery.com/en/api/platform/otp-users/get-otp-user/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `mad.store.otpUsers.list` | [`GET /organizations/:organizationSlug/stores/:storeId/otp-users`](https://docs.applivery.com/en/api/platform/otp-users/get-otp-users/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `mad.store.otpUsers.remove` | [`DELETE /organizations/:organizationSlug/stores/:storeId/otp-users/:otpUserId`](https://docs.applivery.com/en/api/platform/otp-users/delete-otp-user/) | ✓ | ✓ | – | – | ✓ | – | – | | `mad.store.otpUsers.update` | [`PUT /organizations/:organizationSlug/stores/:storeId/otp-users/:otpUserId`](https://docs.applivery.com/en/api/platform/otp-users/put-otp-user/) | ✓ | ✓ | – | – | ✓ | – | – | | `mad.store.publishedApplication.create` | [`POST /stores/:storeId/pubApps`](https://docs.applivery.com/en/api/app-distribution/store-published-applications/post-pub-app/) | ✓ | ✓ | – | – | ✓ | – | – | | `mad.store.publishedApplication.get` | [`GET /stores/:storeId/pubApps/:publishedApplicationId`](https://docs.applivery.com/en/api/app-distribution/store-published-applications/get-pub-app/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `mad.store.publishedApplication.list` | [`GET /stores/:storeId/pubApps`](https://docs.applivery.com/en/api/app-distribution/store-published-applications/get-pub-apps/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `mad.store.publishedApplication.notify` | [`POST /stores/:storeId/pubApps/:publishedApplicationId/notify`](https://docs.applivery.com/en/api/app-distribution/store-published-applications/post-notify/) | ✓ | ✓ | – | – | ✓ | – | – | | `mad.store.publishedApplication.remove` | [`DELETE /stores/:storeId/pubApps/:publishedApplicationId`](https://docs.applivery.com/en/api/app-distribution/store-published-applications/delete-pub-app/) | ✓ | ✓ | – | – | ✓ | – | – | | `mad.store.publishedApplication.target` | [`GET /stores/:storeId/pubApps/:publishedApplicationId/target`](https://docs.applivery.com/en/api/app-distribution/store-published-applications/get-target/) | ✓ | ✓ | ✓ | ✓ | ✓ | – | – | | `mad.store.publishedApplication.update` | [`PUT /stores/:storeId/pubApps/:publishedApplicationId`](https://docs.applivery.com/en/api/app-distribution/store-published-applications/put-pub-app/) | ✓ | ✓ | – | – | ✓ | – | – | **User Audiences (mad.userAudience) · 14 actions, 14 endpoints** | Permission | Endpoints | O | A | E | V | App A | App E | App V | | --- | --- | :-: | :-: | :-: | :-: | :-: | :-: | :-: | | `mad.userAudience.application.create` | [`POST /apps/:applicationId/user-audiences`](https://docs.applivery.com/en/api/platform/user-audience/apps/post-user-audience/) | ✓ | ✓ | – | – | ✓ | ✓ | – | | `mad.userAudience.application.get` | [`GET /apps/:applicationId/user-audiences/:userAudienceId`](https://docs.applivery.com/en/api/platform/user-audience/apps/get-user-audience/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `mad.userAudience.application.list` | [`GET /apps/:applicationId/user-audiences`](https://docs.applivery.com/en/api/platform/user-audience/apps/get-user-audiences/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `mad.userAudience.application.preview` | [`POST /apps/:applicationId/user-audiences/preview`](https://docs.applivery.com/en/api/platform/user-audience/apps/post-preview/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `mad.userAudience.application.remove` | [`DELETE /apps/:applicationId/user-audiences/:userAudienceId`](https://docs.applivery.com/en/api/platform/user-audience/apps/delete-user-audience/) | ✓ | ✓ | – | – | ✓ | ✓ | – | | `mad.userAudience.application.target` | [`GET /apps/:applicationId/user-audiences/:userAudienceId/target`](https://docs.applivery.com/en/api/platform/user-audience/apps/get-target/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `mad.userAudience.application.update` | [`PUT /apps/:applicationId/user-audiences/:userAudienceId`](https://docs.applivery.com/en/api/platform/user-audience/apps/put-user-audience/) | ✓ | ✓ | – | – | ✓ | ✓ | – | | `mad.userAudience.organization.create` | [`POST /user-audiences`](https://docs.applivery.com/en/api/platform/user-audience/post-user-audience/) | ✓ | ✓ | – | – | – | – | – | | `mad.userAudience.organization.get` | [`GET /user-audiences/:userAudienceId`](https://docs.applivery.com/en/api/platform/user-audience/get-user-audience/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `mad.userAudience.organization.list` | [`GET /user-audiences`](https://docs.applivery.com/en/api/platform/user-audience/get-user-audiences/) | ✓ | ✓ | ✓ | ✓ | ✓ | – | – | | `mad.userAudience.organization.preview` | [`POST /user-audiences/preview`](https://docs.applivery.com/en/api/platform/user-audience/post-preview/) | ✓ | ✓ | ✓ | ✓ | ✓ | – | – | | `mad.userAudience.organization.remove` | [`DELETE /user-audiences/:userAudienceId`](https://docs.applivery.com/en/api/platform/user-audience/delete-user-audience/) | ✓ | ✓ | – | – | – | – | – | | `mad.userAudience.organization.target` | [`GET /user-audiences/:userAudienceId/target`](https://docs.applivery.com/en/api/platform/user-audience/get-target/) | ✓ | ✓ | – | – | ✓ | – | – | | `mad.userAudience.organization.update` | [`PUT /user-audiences/:userAudienceId`](https://docs.applivery.com/en/api/platform/user-audience/put-user-audience/) | ✓ | ✓ | – | – | – | – | – | **Helheim (mad.helheim) · 6 actions, 0 endpoints** | Permission | Endpoints | O | A | E | V | App A | App E | App V | | --- | --- | :-: | :-: | :-: | :-: | :-: | :-: | :-: | | `mad.helheim.management.create` | — | ✓ | ✓ | – | – | ✓ | – | – | | `mad.helheim.management.get` | — | ✓ | ✓ | ✓ | – | ✓ | ✓ | – | | `mad.helheim.management.list` | — | ✓ | ✓ | ✓ | – | ✓ | ✓ | – | | `mad.helheim.management.process` | — | ✓ | ✓ | – | – | ✓ | – | – | | `mad.helheim.management.remove` | — | ✓ | ✓ | – | – | ✓ | – | – | | `mad.helheim.management.update` | — | ✓ | ✓ | – | – | ✓ | – | – | **People (people.mad) · 19 actions, 21 endpoints** | Permission | Endpoints | O | A | E | V | App A | App E | App V | | --- | --- | :-: | :-: | :-: | :-: | :-: | :-: | :-: | | `people.mad.applicationCollaborator.create` | [`POST /apps/:applicationId/collaborators`](https://docs.applivery.com/en/api/app-distribution/application-collaborators/post-collaborator/) | ✓ | ✓ | – | – | ✓ | – | – | | `people.mad.applicationCollaborator.get` | [`GET /apps/:applicationId/collaborators/:applicationCollaboratorId`](https://docs.applivery.com/en/api/app-distribution/application-collaborators/get-collaborator/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `people.mad.applicationCollaborator.invitations` | [`GET /apps/:applicationId/collaborators/invitations`](https://docs.applivery.com/en/api/app-distribution/application-collaborators/invitations/get/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `people.mad.applicationCollaborator.list` | [`GET /apps/:applicationId/collaborators`](https://docs.applivery.com/en/api/app-distribution/application-collaborators/get-collaborators/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `people.mad.applicationCollaborator.remove` | [`DELETE /apps/:applicationId/collaborators/:applicationCollaboratorId`](https://docs.applivery.com/en/api/app-distribution/application-collaborators/delete-collaborator/) | ✓ | ✓ | – | – | ✓ | – | – | | `people.mad.applicationCollaborator.removeInvitations` | [`DELETE /apps/:applicationId/collaborators/invitations/:invitationId`](https://docs.applivery.com/en/api/app-distribution/application-collaborators/invitations/delete-by-id/) | ✓ | ✓ | – | – | ✓ | – | – | | `people.mad.applicationCollaborator.update` | [`PUT /apps/:applicationId/collaborators/:applicationCollaboratorId`](https://docs.applivery.com/en/api/app-distribution/application-collaborators/put-collaborator/) | ✓ | ✓ | – | – | ✓ | – | – | | `people.mad.applicationEmployee.create` | [`POST /apps/:applicationId/employees`](https://docs.applivery.com/en/api/app-distribution/application-employees/post-employee/) | ✓ | ✓ | – | – | ✓ | – | – | | `people.mad.applicationEmployee.get` | [`GET /apps/:applicationId/employees/:applicationEmployeeId`](https://docs.applivery.com/en/api/app-distribution/application-employees/get-employee/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `people.mad.applicationEmployee.list` | [`GET /apps/:applicationId/employees`](https://docs.applivery.com/en/api/app-distribution/application-employees/get-employees/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `people.mad.applicationEmployee.remove` | [`DELETE /apps/:applicationId/employees/:applicationEmployeeId`](https://docs.applivery.com/en/api/app-distribution/application-employees/delete-employee/) | ✓ | ✓ | – | – | ✓ | – | – | | `people.mad.applicationEmployee.update` | [`PUT /apps/:applicationId/employees/:applicationEmployeeId`](https://docs.applivery.com/en/api/app-distribution/application-employees/put-employee/) | ✓ | ✓ | – | – | ✓ | – | – | | `people.mad.organizationEmployee.create` | [`POST /employees`](https://docs.applivery.com/en/api/app-distribution/organization-employees/post-employee/) | ✓ | ✓ | – | – | – | – | – | | `people.mad.organizationEmployee.get` | [`GET /employees/:organizationEmployeeId`](https://docs.applivery.com/en/api/app-distribution/organization-employees/get-employee/) | ✓ | ✓ | ✓ | ✓ | – | – | – | | `people.mad.organizationEmployee.list` | [`GET /employees`](https://docs.applivery.com/en/api/app-distribution/organization-employees/get-employees/)
[`GET /employees/apps`](https://docs.applivery.com/en/api/app-distribution/organization-employees/get-apps/) | ✓ | ✓ | ✓ | ✓ | – | – | – | | `people.mad.organizationEmployee.listAll` | [`GET /employees/all`](https://docs.applivery.com/en/api/app-distribution/organization-employees/get-all/)
[`GET /employees/all-csv`](https://docs.applivery.com/en/api/app-distribution/organization-employees/get-all-csv/) | ✓ | ✓ | ✓ | ✓ | – | – | – | | `people.mad.organizationEmployee.listGroups` | [`GET /employees/groups`](https://docs.applivery.com/en/api/app-distribution/organization-employees/get-groups/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `people.mad.organizationEmployee.remove` | [`DELETE /employees/:organizationEmployeeId`](https://docs.applivery.com/en/api/app-distribution/organization-employees/delete-employee/) | ✓ | ✓ | – | – | – | – | – | | `people.mad.organizationEmployee.update` | [`PUT /employees/:organizationEmployeeId`](https://docs.applivery.com/en/api/app-distribution/organization-employees/put-employee/) | ✓ | ✓ | ✓ | – | – | – | – | **Workspace** **Organization (base.organization) · 66 actions, 63 endpoints** **Device Management roles** | Permission | Endpoints | O | A | E | V | | --- | --- | :-: | :-: | :-: | :-: | | `base.organization.assistant.action` | [`POST /assistant/:action`](https://docs.applivery.com/en/api/platform/assistant/post-assistant-by-id/) | ✓ | ✓ | ✓ | ✓ | | `base.organization.audit.get` | [`GET /audit/:auditId`](https://docs.applivery.com/en/api/platform/audit/get-audit-by-id/) | ✓ | ✓ | – | – | | `base.organization.audit.list` | [`GET /audit`](https://docs.applivery.com/en/api/platform/audit/get-audit/) | ✓ | ✓ | – | – | | `base.organization.certificateProvider.assignations` | [`GET /certificate-providers/:certificateProviderId/assignations`](https://docs.applivery.com/en/api/platform/certificate-provider/get-assignations/) | ✓ | ✓ | – | – | | `base.organization.certificateProvider.create` | [`POST /certificate-providers`](https://docs.applivery.com/en/api/platform/certificate-provider/post-certificate-provider/) | ✓ | ✓ | – | – | | `base.organization.certificateProvider.get` | [`GET /certificate-providers/:certificateProviderId`](https://docs.applivery.com/en/api/platform/certificate-provider/get-certificate-provider/) | ✓ | ✓ | – | – | | `base.organization.certificateProvider.list` | [`GET /certificate-providers`](https://docs.applivery.com/en/api/platform/certificate-provider/get-certificate-providers/) | ✓ | ✓ | – | – | | `base.organization.certificateProvider.purge` | [`DELETE /certificate-providers/:certificateProviderId/purge`](https://docs.applivery.com/en/api/platform/certificateprovider/delete-organizations-organizationid-certificate-providers-certificateproviderid-purge/) | ✓ | ✓ | – | – | | `base.organization.certificateProvider.remove` | [`DELETE /certificate-providers/:certificateProviderId`](https://docs.applivery.com/en/api/platform/certificate-provider/delete-certificate-provider/) | ✓ | ✓ | – | – | | `base.organization.certificateProvider.update` | [`PUT /certificate-providers/:certificateProviderId`](https://docs.applivery.com/en/api/platform/certificate-provider/put-certificate-provider/) | ✓ | ✓ | – | – | | `base.organization.emails.list` | [`GET /emails/:scope`](https://docs.applivery.com/en/api/platform/organization-emails/get-email/) | ✓ | ✓ | ✓ | – | | `base.organization.loginProvider.create` | [`POST /providers`](https://docs.applivery.com/en/api/platform/organization-providers/post-provider/) | ✓ | ✓ | – | – | | `base.organization.loginProvider.get` | [`GET /providers/:providerId`](https://docs.applivery.com/en/api/platform/organization-providers/get-provider/) | ✓ | ✓ | – | – | | `base.organization.loginProvider.list` | [`GET /providers`](https://docs.applivery.com/en/api/platform/organization-providers/get-providers/) | ✓ | ✓ | – | – | | `base.organization.loginProvider.remove` | [`DELETE /providers/:providerId`](https://docs.applivery.com/en/api/platform/organization-providers/delete-provider/) | ✓ | ✓ | – | – | | `base.organization.loginProvider.update` | [`PUT /providers/:providerId`](https://docs.applivery.com/en/api/platform/organization-providers/put-provider/) | ✓ | ✓ | – | – | | `base.organization.loginProvider.updateSamlUris` | [`PUT /providers/:providerId/saml-uris`](https://docs.applivery.com/en/api/platform/organization-providers/put-saml-uris/) | ✓ | ✓ | – | – | | `base.organization.management.checkSlug` | [`GET /organizations/check-slug/:slug`](https://docs.applivery.com/en/api/platform/organization/get-check-slug-by-id/) | ✓ | ✓ | ✓ | ✓ | | `base.organization.management.create` | [`POST /organizations`](https://docs.applivery.com/en/api/platform/organization/post-organization/) | ✓ | ✓ | ✓ | – | | `base.organization.management.get` | [`GET /`](https://docs.applivery.com/en/api/platform/organization/get-organization/)
[`GET /actions`](https://docs.applivery.com/en/api/platform/organization/get-actions/)
[`GET /workspace`](https://docs.applivery.com/en/api/platform/organization/get-workspace/) | ✓ | ✓ | ✓ | ✓ | | `base.organization.management.getStorageProviders` | [`GET /storage-providers`](https://docs.applivery.com/en/api/platform/organization-storage-providers/get-storage-providers/) | ✓ | ✓ | ✓ | ✓ | | `base.organization.management.list` | [`GET /organizations`](https://docs.applivery.com/en/api/platform/organization/get-organizations/) | ✓ | ✓ | ✓ | ✓ | | `base.organization.management.listGroups` | [`GET /groups`](https://docs.applivery.com/en/api/platform/organization/get-groups/) | ✓ | ✓ | ✓ | ✓ | | `base.organization.management.manageIntegrations` | — | ✓ | ✓ | – | – | | `base.organization.management.sendSupportEmail` | [`GET /support-email/:action`](https://docs.applivery.com/en/api/platform/organization/get-support-email-by-id/) | ✓ | ✓ | ✓ | ✓ | | `base.organization.management.update` | [`PUT /`](https://docs.applivery.com/en/api/platform/organization/put-organization/) | ✓ | ✓ | – | – | | `base.organization.notification.create` | [`POST /notifications`](https://docs.applivery.com/en/api/platform/organization-notifications/post-notification/) | ✓ | ✓ | – | – | | `base.organization.notification.get` | [`GET /notifications/:organizationNotificationId`](https://docs.applivery.com/en/api/platform/organization-notifications/get-notification/) | ✓ | ✓ | ✓ | – | | `base.organization.notification.list` | [`GET /notifications`](https://docs.applivery.com/en/api/platform/organization-notifications/get-notifications/) | ✓ | ✓ | ✓ | – | | `base.organization.notification.remove` | [`DELETE /notifications/:organizationNotificationId`](https://docs.applivery.com/en/api/platform/organization-notifications/delete-notification/) | ✓ | ✓ | – | – | | `base.organization.notification.update` | [`PUT /notifications/:organizationNotificationId`](https://docs.applivery.com/en/api/platform/organization-notifications/put-notification/) | ✓ | ✓ | – | – | | `base.organization.pushNotificationProvider.create` | — | ✓ | ✓ | – | – | | `base.organization.pushNotificationProvider.get` | — | ✓ | ✓ | – | – | | `base.organization.pushNotificationProvider.list` | — | ✓ | ✓ | – | – | | `base.organization.pushNotificationProvider.remove` | — | ✓ | ✓ | – | – | | `base.organization.pushNotificationProvider.update` | — | ✓ | ✓ | – | – | | `base.organization.scim.create` | [`POST /providers/:providerId/scim`](https://docs.applivery.com/en/api/platform/organization-providers-scim/post-scim/) | ✓ | ✓ | – | – | | `base.organization.scim.get` | [`GET /providers/:providerId/scim`](https://docs.applivery.com/en/api/platform/organization-providers-scim/get-scim/) | ✓ | ✓ | ✓ | ✓ | | `base.organization.scim.list` | — | ✓ | ✓ | ✓ | ✓ | | `base.organization.scim.remove` | [`DELETE /providers/:providerId/scim`](https://docs.applivery.com/en/api/platform/organization-providers-scim/delete-scim/) | ✓ | ✓ | – | – | | `base.organization.scim.update` | [`PUT /providers/:providerId/scim`](https://docs.applivery.com/en/api/platform/organization-providers-scim/put-scim/) | ✓ | ✓ | – | – | | `base.organization.segment.actions` | [`GET /segments/:segmentId/actions`](https://docs.applivery.com/en/api/platform/segment/get-actions/) | ✓ | ✓ | ✓ | ✓ | | `base.organization.segment.counts` | [`GET /segments/:segmentId/counts`](https://docs.applivery.com/en/api/platform/segment/get-counts/)
[`GET /segments/:segmentId/counts-by-entity/:entity`](https://docs.applivery.com/en/api/platform/segment/get-counts-by-entity-by-id/) | ✓ | ✓ | ✓ | ✓ | | `base.organization.segment.create` | [`POST /segments`](https://docs.applivery.com/en/api/platform/segment/post-segment/) | ✓ | ✓ | – | – | | `base.organization.segment.get` | [`GET /segments/:segmentId`](https://docs.applivery.com/en/api/platform/segment/get-segment/) | ✓ | ✓ | – | – | | `base.organization.segment.list` | [`GET /segments`](https://docs.applivery.com/en/api/platform/segment/get-segments/) | ✓ | ✓ | – | – | | `base.organization.segment.remove` | [`DELETE /segments/:segmentId`](https://docs.applivery.com/en/api/platform/segment/delete-segment/) | ✓ | ✓ | – | – | | `base.organization.segment.update` | [`PUT /segments/:segmentId`](https://docs.applivery.com/en/api/platform/segment/put-segment/) | ✓ | ✓ | – | – | | `base.organization.segmentPermission.create` | [`POST /segment-permissions`](https://docs.applivery.com/en/api/platform/segment-permission/post-segment-permission/) | ✓ | ✓ | – | – | | `base.organization.segmentPermission.get` | [`GET /segment-permissions/:permissionId`](https://docs.applivery.com/en/api/platform/segment-permission/get-segment-permission/) | ✓ | ✓ | ✓ | ✓ | | `base.organization.segmentPermission.list` | [`GET /segment-permissions`](https://docs.applivery.com/en/api/platform/segment-permission/get-segment-permissions/) | ✓ | ✓ | ✓ | ✓ | | `base.organization.segmentPermission.preview` | [`POST /segment-permissions/preview`](https://docs.applivery.com/en/api/platform/segment-permission/post-preview/) | ✓ | ✓ | – | – | | `base.organization.segmentPermission.remove` | [`DELETE /segment-permissions/:permissionId`](https://docs.applivery.com/en/api/platform/segment-permission/delete-segment-permission/) | ✓ | ✓ | – | – | | `base.organization.segmentPermission.update` | [`PUT /segment-permissions/:permissionId`](https://docs.applivery.com/en/api/platform/segment-permission/put-segment-permission/) | ✓ | ✓ | – | – | | `base.organization.segmentPermission.userList` | [`GET /segment-permissions/users`](https://docs.applivery.com/en/api/platform/segment-permission/get-users/) | ✓ | ✓ | – | – | | `base.organization.segmentRole.create` | [`POST /segment-roles`](https://docs.applivery.com/en/api/platform/segment-role/post-segment-role/) | ✓ | ✓ | – | – | | `base.organization.segmentRole.get` | [`GET /segment-roles/:roleId`](https://docs.applivery.com/en/api/platform/segment-role/get-segment-role/) | ✓ | ✓ | ✓ | ✓ | | `base.organization.segmentRole.list` | [`GET /segment-roles`](https://docs.applivery.com/en/api/platform/segment-role/get-segment-roles/) | ✓ | ✓ | ✓ | ✓ | | `base.organization.segmentRole.remove` | [`DELETE /segment-roles/:roleId`](https://docs.applivery.com/en/api/platform/segment-role/delete-segment-role/) | ✓ | ✓ | – | – | | `base.organization.segmentRole.update` | [`PUT /segment-roles/:roleId`](https://docs.applivery.com/en/api/platform/segment-role/put-segment-role/) | ✓ | ✓ | – | – | | `base.organization.stats.get` | [`GET /stats`](https://docs.applivery.com/en/api/platform/organization-stats/get-stats/)
[`GET /stats/by-day`](https://docs.applivery.com/en/api/platform/organization-stats/get-by-day/) | ✓ | ✓ | ✓ | ✓ | | `base.organization.storageProvider.create` | [`POST /storage-providers`](https://docs.applivery.com/en/api/platform/organization-storage-providers/post-storage-provider/) | ✓ | ✓ | – | – | | `base.organization.storageProvider.delete` | [`DELETE /storage-providers/:storageProviderId`](https://docs.applivery.com/en/api/platform/organization-storage-providers/delete-storage-provider/) | ✓ | ✓ | – | – | | `base.organization.storageProvider.list` | [`GET /storage-providers`](https://docs.applivery.com/en/api/platform/organization-storage-providers/get-storage-providers/) | ✓ | ✓ | – | – | | `base.organization.storageProvider.test` | [`GET /storage-providers/:storageProviderId/test`](https://docs.applivery.com/en/api/platform/organization-storage-providers/get-test/) | ✓ | ✓ | – | – | | `base.organization.storageProvider.update` | [`PUT /storage-providers/:storageProviderId`](https://docs.applivery.com/en/api/platform/organization-storage-providers/put-storage-provider/) | ✓ | ✓ | – | – | **App Distribution roles** | Permission | Endpoints | O | A | E | V | App A | App E | App V | | --- | --- | :-: | :-: | :-: | :-: | :-: | :-: | :-: | | `base.organization.assistant.action` | [`POST /assistant/:action`](https://docs.applivery.com/en/api/platform/assistant/post-assistant-by-id/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `base.organization.audit.get` | [`GET /audit/:auditId`](https://docs.applivery.com/en/api/platform/audit/get-audit-by-id/) | ✓ | ✓ | – | – | – | – | – | | `base.organization.audit.list` | [`GET /audit`](https://docs.applivery.com/en/api/platform/audit/get-audit/) | ✓ | ✓ | – | – | – | – | – | | `base.organization.certificateProvider.assignations` | [`GET /certificate-providers/:certificateProviderId/assignations`](https://docs.applivery.com/en/api/platform/certificate-provider/get-assignations/) | ✓ | – | – | – | – | – | – | | `base.organization.certificateProvider.create` | [`POST /certificate-providers`](https://docs.applivery.com/en/api/platform/certificate-provider/post-certificate-provider/) | ✓ | – | – | – | – | – | – | | `base.organization.certificateProvider.get` | [`GET /certificate-providers/:certificateProviderId`](https://docs.applivery.com/en/api/platform/certificate-provider/get-certificate-provider/) | ✓ | – | – | – | – | – | – | | `base.organization.certificateProvider.list` | [`GET /certificate-providers`](https://docs.applivery.com/en/api/platform/certificate-provider/get-certificate-providers/) | ✓ | – | – | – | – | – | – | | `base.organization.certificateProvider.purge` | [`DELETE /certificate-providers/:certificateProviderId/purge`](https://docs.applivery.com/en/api/platform/certificateprovider/delete-organizations-organizationid-certificate-providers-certificateproviderid-purge/) | ✓ | – | – | – | – | – | – | | `base.organization.certificateProvider.remove` | [`DELETE /certificate-providers/:certificateProviderId`](https://docs.applivery.com/en/api/platform/certificate-provider/delete-certificate-provider/) | ✓ | – | – | – | – | – | – | | `base.organization.certificateProvider.update` | [`PUT /certificate-providers/:certificateProviderId`](https://docs.applivery.com/en/api/platform/certificate-provider/put-certificate-provider/) | ✓ | – | – | – | – | – | – | | `base.organization.emails.list` | [`GET /emails/:scope`](https://docs.applivery.com/en/api/platform/organization-emails/get-email/) | ✓ | ✓ | ✓ | – | ✓ | ✓ | – | | `base.organization.loginProvider.create` | [`POST /providers`](https://docs.applivery.com/en/api/platform/organization-providers/post-provider/) | ✓ | ✓ | – | – | – | – | – | | `base.organization.loginProvider.get` | [`GET /providers/:providerId`](https://docs.applivery.com/en/api/platform/organization-providers/get-provider/) | ✓ | ✓ | – | – | – | – | – | | `base.organization.loginProvider.list` | [`GET /providers`](https://docs.applivery.com/en/api/platform/organization-providers/get-providers/) | ✓ | ✓ | – | – | – | – | – | | `base.organization.loginProvider.remove` | [`DELETE /providers/:providerId`](https://docs.applivery.com/en/api/platform/organization-providers/delete-provider/) | ✓ | ✓ | – | – | – | – | – | | `base.organization.loginProvider.update` | [`PUT /providers/:providerId`](https://docs.applivery.com/en/api/platform/organization-providers/put-provider/) | ✓ | ✓ | – | – | – | – | – | | `base.organization.loginProvider.updateSamlUris` | [`PUT /providers/:providerId/saml-uris`](https://docs.applivery.com/en/api/platform/organization-providers/put-saml-uris/) | ✓ | ✓ | – | – | – | – | – | | `base.organization.management.checkSlug` ¹ | [`GET /organizations/check-slug/:slug`](https://docs.applivery.com/en/api/platform/organization/get-check-slug-by-id/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `base.organization.management.create` ¹ | [`POST /organizations`](https://docs.applivery.com/en/api/platform/organization/post-organization/) | ✓ | ✓ | ✓ | – | ✓ | ✓ | – | | `base.organization.management.get` ¹ | [`GET /`](https://docs.applivery.com/en/api/platform/organization/get-organization/)
[`GET /actions`](https://docs.applivery.com/en/api/platform/organization/get-actions/)
[`GET /workspace`](https://docs.applivery.com/en/api/platform/organization/get-workspace/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `base.organization.management.getStorageProviders` ¹ | [`GET /storage-providers`](https://docs.applivery.com/en/api/platform/organization-storage-providers/get-storage-providers/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `base.organization.management.list` ¹ | [`GET /organizations`](https://docs.applivery.com/en/api/platform/organization/get-organizations/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `base.organization.management.listGroups` | [`GET /groups`](https://docs.applivery.com/en/api/platform/organization/get-groups/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `base.organization.management.manageIntegrations` | — | ✓ | ✓ | – | – | – | – | – | | `base.organization.management.sendSupportEmail` | [`GET /support-email/:action`](https://docs.applivery.com/en/api/platform/organization/get-support-email-by-id/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `base.organization.management.update` | [`PUT /`](https://docs.applivery.com/en/api/platform/organization/put-organization/) | ✓ | ✓ | – | – | – | – | – | | `base.organization.notification.create` | [`POST /notifications`](https://docs.applivery.com/en/api/platform/organization-notifications/post-notification/) | ✓ | ✓ | – | – | – | – | – | | `base.organization.notification.get` | [`GET /notifications/:organizationNotificationId`](https://docs.applivery.com/en/api/platform/organization-notifications/get-notification/) | ✓ | ✓ | ✓ | – | – | – | – | | `base.organization.notification.list` | [`GET /notifications`](https://docs.applivery.com/en/api/platform/organization-notifications/get-notifications/) | ✓ | ✓ | ✓ | – | – | – | – | | `base.organization.notification.remove` | [`DELETE /notifications/:organizationNotificationId`](https://docs.applivery.com/en/api/platform/organization-notifications/delete-notification/) | ✓ | ✓ | – | – | – | – | – | | `base.organization.notification.update` | [`PUT /notifications/:organizationNotificationId`](https://docs.applivery.com/en/api/platform/organization-notifications/put-notification/) | ✓ | ✓ | – | – | – | – | – | | `base.organization.pushNotificationProvider.create` | — | ✓ | – | – | – | – | – | – | | `base.organization.pushNotificationProvider.get` | — | ✓ | – | – | – | – | – | – | | `base.organization.pushNotificationProvider.list` | — | ✓ | – | – | – | – | – | – | | `base.organization.pushNotificationProvider.remove` | — | ✓ | – | – | – | – | – | – | | `base.organization.pushNotificationProvider.update` | — | ✓ | – | – | – | – | – | – | | `base.organization.scim.create` | [`POST /providers/:providerId/scim`](https://docs.applivery.com/en/api/platform/organization-providers-scim/post-scim/) | ✓ | ✓ | – | – | ✓ | – | – | | `base.organization.scim.get` | [`GET /providers/:providerId/scim`](https://docs.applivery.com/en/api/platform/organization-providers-scim/get-scim/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `base.organization.scim.list` | — | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `base.organization.scim.remove` | [`DELETE /providers/:providerId/scim`](https://docs.applivery.com/en/api/platform/organization-providers-scim/delete-scim/) | ✓ | ✓ | – | – | ✓ | – | – | | `base.organization.scim.update` | [`PUT /providers/:providerId/scim`](https://docs.applivery.com/en/api/platform/organization-providers-scim/put-scim/) | ✓ | ✓ | – | – | ✓ | – | – | | `base.organization.segment.actions` ¹ | [`GET /segments/:segmentId/actions`](https://docs.applivery.com/en/api/platform/segment/get-actions/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `base.organization.segment.counts` ¹ | [`GET /segments/:segmentId/counts`](https://docs.applivery.com/en/api/platform/segment/get-counts/)
[`GET /segments/:segmentId/counts-by-entity/:entity`](https://docs.applivery.com/en/api/platform/segment/get-counts-by-entity-by-id/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `base.organization.segment.create` | [`POST /segments`](https://docs.applivery.com/en/api/platform/segment/post-segment/) | ✓ | – | – | – | – | – | – | | `base.organization.segment.get` | [`GET /segments/:segmentId`](https://docs.applivery.com/en/api/platform/segment/get-segment/) | ✓ | – | – | – | – | – | – | | `base.organization.segment.list` | [`GET /segments`](https://docs.applivery.com/en/api/platform/segment/get-segments/) | ✓ | – | – | – | – | – | – | | `base.organization.segment.remove` | [`DELETE /segments/:segmentId`](https://docs.applivery.com/en/api/platform/segment/delete-segment/) | ✓ | – | – | – | – | – | – | | `base.organization.segment.update` | [`PUT /segments/:segmentId`](https://docs.applivery.com/en/api/platform/segment/put-segment/) | ✓ | – | – | – | – | – | – | | `base.organization.segmentPermission.create` | [`POST /segment-permissions`](https://docs.applivery.com/en/api/platform/segment-permission/post-segment-permission/) | ✓ | – | – | – | – | – | – | | `base.organization.segmentPermission.get` | [`GET /segment-permissions/:permissionId`](https://docs.applivery.com/en/api/platform/segment-permission/get-segment-permission/) | ✓ | – | – | – | – | – | – | | `base.organization.segmentPermission.list` | [`GET /segment-permissions`](https://docs.applivery.com/en/api/platform/segment-permission/get-segment-permissions/) | ✓ | – | – | – | – | – | – | | `base.organization.segmentPermission.preview` | [`POST /segment-permissions/preview`](https://docs.applivery.com/en/api/platform/segment-permission/post-preview/) | ✓ | – | – | – | – | – | – | | `base.organization.segmentPermission.remove` | [`DELETE /segment-permissions/:permissionId`](https://docs.applivery.com/en/api/platform/segment-permission/delete-segment-permission/) | ✓ | – | – | – | – | – | – | | `base.organization.segmentPermission.update` | [`PUT /segment-permissions/:permissionId`](https://docs.applivery.com/en/api/platform/segment-permission/put-segment-permission/) | ✓ | – | – | – | – | – | – | | `base.organization.segmentPermission.userList` | [`GET /segment-permissions/users`](https://docs.applivery.com/en/api/platform/segment-permission/get-users/) | ✓ | – | – | – | – | – | – | | `base.organization.segmentRole.create` | [`POST /segment-roles`](https://docs.applivery.com/en/api/platform/segment-role/post-segment-role/) | ✓ | – | – | – | – | – | – | | `base.organization.segmentRole.get` | [`GET /segment-roles/:roleId`](https://docs.applivery.com/en/api/platform/segment-role/get-segment-role/) | ✓ | – | – | – | – | – | – | | `base.organization.segmentRole.list` | [`GET /segment-roles`](https://docs.applivery.com/en/api/platform/segment-role/get-segment-roles/) | ✓ | – | – | – | – | – | – | | `base.organization.segmentRole.remove` | [`DELETE /segment-roles/:roleId`](https://docs.applivery.com/en/api/platform/segment-role/delete-segment-role/) | ✓ | – | – | – | – | – | – | | `base.organization.segmentRole.update` | [`PUT /segment-roles/:roleId`](https://docs.applivery.com/en/api/platform/segment-role/put-segment-role/) | ✓ | – | – | – | – | – | – | | `base.organization.stats.get` | [`GET /stats`](https://docs.applivery.com/en/api/platform/organization-stats/get-stats/)
[`GET /stats/by-day`](https://docs.applivery.com/en/api/platform/organization-stats/get-by-day/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `base.organization.storageProvider.create` | [`POST /storage-providers`](https://docs.applivery.com/en/api/platform/organization-storage-providers/post-storage-provider/) | ✓ | ✓ | – | – | – | – | – | | `base.organization.storageProvider.delete` | [`DELETE /storage-providers/:storageProviderId`](https://docs.applivery.com/en/api/platform/organization-storage-providers/delete-storage-provider/) | ✓ | ✓ | – | – | – | – | – | | `base.organization.storageProvider.list` | [`GET /storage-providers`](https://docs.applivery.com/en/api/platform/organization-storage-providers/get-storage-providers/) | ✓ | ✓ | – | – | ✓ | – | – | | `base.organization.storageProvider.test` | [`GET /storage-providers/:storageProviderId/test`](https://docs.applivery.com/en/api/platform/organization-storage-providers/get-test/) | ✓ | ✓ | – | – | – | – | – | | `base.organization.storageProvider.update` | [`PUT /storage-providers/:storageProviderId`](https://docs.applivery.com/en/api/platform/organization-storage-providers/put-storage-provider/) | ✓ | ✓ | – | – | – | – | – | ¹ Also allowed for: `base.organization.management.checkSlug`: Unassigned, No Role; `base.organization.management.create`: No Role; `base.organization.management.get`: Unassigned; `base.organization.management.getStorageProviders`: No Role; `base.organization.management.list`: Unassigned, No Role; `base.organization.segment.actions`: Unassigned, No Role; `base.organization.segment.counts`: Unassigned, No Role. **People (people.base) · 17 actions, 19 endpoints** **Device Management roles** | Permission | Endpoints | O | A | E | V | | --- | --- | :-: | :-: | :-: | :-: | | `people.base.audit.audit` | [`GET /members/audit`](https://docs.applivery.com/en/api/platform/members/get-audit/) | ✓ | – | – | – | | `people.base.audit.merge` | [`POST /members/audit/merge`](https://docs.applivery.com/en/api/platform/members/post-merge/) | ✓ | – | – | – | | `people.base.management.list` | [`GET /people`](https://docs.applivery.com/en/api/platform/people/get-people/) | ✓ | ✓ | ✓ | ✓ | | `people.base.organizationCollaborator.create` | [`POST /collaborators`](https://docs.applivery.com/en/api/app-distribution/organization-collaborators/post-collaborator/) | ✓ | ✓ | – | – | | `people.base.organizationCollaborator.get` | [`GET /collaborators/:organizationCollaboratorId`](https://docs.applivery.com/en/api/app-distribution/organization-collaborators/get-collaborator/) | ✓ | ✓ | ✓ | ✓ | | `people.base.organizationCollaborator.invitations` | [`GET /collaborators/invitations`](https://docs.applivery.com/en/api/app-distribution/organization-collaborators/invitations/get/) | ✓ | ✓ | ✓ | ✓ | | `people.base.organizationCollaborator.list` | [`GET /collaborators`](https://docs.applivery.com/en/api/app-distribution/organization-collaborators/get-collaborators/)
[`GET /collaborators/apps`](https://docs.applivery.com/en/api/app-distribution/organization-collaborators/get-apps/) | ✓ | ✓ | ✓ | ✓ | | `people.base.organizationCollaborator.listAll` | [`GET /collaborators/all`](https://docs.applivery.com/en/api/app-distribution/organization-collaborators/get-all/)
[`GET /collaborators/all-csv`](https://docs.applivery.com/en/api/app-distribution/organization-collaborators/get-all-csv/) | ✓ | ✓ | ✓ | ✓ | | `people.base.organizationCollaborator.listGroups` | [`GET /collaborators/groups`](https://docs.applivery.com/en/api/app-distribution/organization-collaborators/get-groups/) | ✓ | ✓ | ✓ | ✓ | | `people.base.organizationCollaborator.remove` | [`DELETE /collaborators/:organizationCollaboratorId`](https://docs.applivery.com/en/api/app-distribution/organization-collaborators/delete-collaborator/) | ✓ | ✓ | – | – | | `people.base.organizationCollaborator.removeInvitations` | [`DELETE /collaborators/invitations/:invitationId`](https://docs.applivery.com/en/api/app-distribution/organization-collaborators/invitations/delete-by-id/) | ✓ | ✓ | – | – | | `people.base.organizationCollaborator.update` | [`PUT /collaborators/:organizationCollaboratorId`](https://docs.applivery.com/en/api/app-distribution/organization-collaborators/put-collaborator/) | ✓ | ✓ | – | – | | `people.base.serviceAccount.create` | [`POST /service-accounts`](https://docs.applivery.com/en/api/platform/organization-service-accounts/post-service-account/) | ✓ | ✓ | – | – | | `people.base.serviceAccount.get` | [`GET /service-accounts/:serviceAccountId`](https://docs.applivery.com/en/api/platform/organization-service-accounts/get-service-account/) | ✓ | ✓ | ✓ | – | | `people.base.serviceAccount.list` | [`GET /service-accounts`](https://docs.applivery.com/en/api/platform/organization-service-accounts/get-service-accounts/) | ✓ | ✓ | ✓ | – | | `people.base.serviceAccount.regenerate` | [`PUT /service-accounts/:serviceAccountId/session`](https://docs.applivery.com/en/api/platform/organization-service-accounts/put-session/) | ✓ | ✓ | ✓ | – | | `people.base.serviceAccount.remove` | [`DELETE /service-accounts/:serviceAccountId`](https://docs.applivery.com/en/api/platform/organization-service-accounts/delete-service-account/) | ✓ | ✓ | – | – | **App Distribution roles** | Permission | Endpoints | O | A | E | V | App A | App E | App V | | --- | --- | :-: | :-: | :-: | :-: | :-: | :-: | :-: | | `people.base.audit.audit` | [`GET /members/audit`](https://docs.applivery.com/en/api/platform/members/get-audit/) | ✓ | ✓ | – | – | – | – | – | | `people.base.audit.merge` | [`POST /members/audit/merge`](https://docs.applivery.com/en/api/platform/members/post-merge/) | ✓ | ✓ | – | – | – | – | – | | `people.base.management.list` | [`GET /people`](https://docs.applivery.com/en/api/platform/people/get-people/) | ✓ | ✓ | ✓ | ✓ | – | – | – | | `people.base.organizationCollaborator.create` | [`POST /collaborators`](https://docs.applivery.com/en/api/app-distribution/organization-collaborators/post-collaborator/) | ✓ | ✓ | – | – | – | – | – | | `people.base.organizationCollaborator.get` | [`GET /collaborators/:organizationCollaboratorId`](https://docs.applivery.com/en/api/app-distribution/organization-collaborators/get-collaborator/) | ✓ | ✓ | ✓ | ✓ | – | – | – | | `people.base.organizationCollaborator.invitations` | [`GET /collaborators/invitations`](https://docs.applivery.com/en/api/app-distribution/organization-collaborators/invitations/get/) | ✓ | ✓ | ✓ | ✓ | – | – | – | | `people.base.organizationCollaborator.list` | [`GET /collaborators`](https://docs.applivery.com/en/api/app-distribution/organization-collaborators/get-collaborators/)
[`GET /collaborators/apps`](https://docs.applivery.com/en/api/app-distribution/organization-collaborators/get-apps/) | ✓ | ✓ | ✓ | ✓ | – | – | – | | `people.base.organizationCollaborator.listAll` | [`GET /collaborators/all`](https://docs.applivery.com/en/api/app-distribution/organization-collaborators/get-all/)
[`GET /collaborators/all-csv`](https://docs.applivery.com/en/api/app-distribution/organization-collaborators/get-all-csv/) | ✓ | ✓ | ✓ | ✓ | – | – | – | | `people.base.organizationCollaborator.listGroups` | [`GET /collaborators/groups`](https://docs.applivery.com/en/api/app-distribution/organization-collaborators/get-groups/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `people.base.organizationCollaborator.remove` | [`DELETE /collaborators/:organizationCollaboratorId`](https://docs.applivery.com/en/api/app-distribution/organization-collaborators/delete-collaborator/) | ✓ | ✓ | – | – | – | – | – | | `people.base.organizationCollaborator.removeInvitations` | [`DELETE /collaborators/invitations/:invitationId`](https://docs.applivery.com/en/api/app-distribution/organization-collaborators/invitations/delete-by-id/) | ✓ | ✓ | – | – | – | – | – | | `people.base.organizationCollaborator.update` | [`PUT /collaborators/:organizationCollaboratorId`](https://docs.applivery.com/en/api/app-distribution/organization-collaborators/put-collaborator/) | ✓ | ✓ | – | – | – | – | – | | `people.base.serviceAccount.create` | [`POST /service-accounts`](https://docs.applivery.com/en/api/platform/organization-service-accounts/post-service-account/) | ✓ | ✓ | – | – | – | – | – | | `people.base.serviceAccount.get` | [`GET /service-accounts/:serviceAccountId`](https://docs.applivery.com/en/api/platform/organization-service-accounts/get-service-account/) | ✓ | ✓ | ✓ | – | – | – | – | | `people.base.serviceAccount.list` | [`GET /service-accounts`](https://docs.applivery.com/en/api/platform/organization-service-accounts/get-service-accounts/) | ✓ | ✓ | ✓ | – | – | – | – | | `people.base.serviceAccount.regenerate` | [`PUT /service-accounts/:serviceAccountId/session`](https://docs.applivery.com/en/api/platform/organization-service-accounts/put-session/) | ✓ | ✓ | ✓ | – | – | – | – | | `people.base.serviceAccount.remove` | [`DELETE /service-accounts/:serviceAccountId`](https://docs.applivery.com/en/api/platform/organization-service-accounts/delete-service-account/) | ✓ | ✓ | – | – | – | – | – | **Bulk actions (base.bulk) · 6 actions, 5 endpoints** **Device Management roles** | Permission | Endpoints | O | A | E | V | | --- | --- | :-: | :-: | :-: | :-: | | `base.bulk.management.check` | [`POST /bulk-tasks/check`](https://docs.applivery.com/en/api/platform/bulk-tasks/post-check/) | ✓ | ✓ | ✓ | – | | `base.bulk.management.create` | [`POST /bulk-tasks/edge/create`](https://docs.applivery.com/en/api/platform/bulk-tasks/edge/post-create/) | ✓ | ✓ | ✓ | – | | `base.bulk.management.get` | [`GET /bulk-tasks/:bulkTaskId`](https://docs.applivery.com/en/api/platform/bulk-tasks/get-bulk-task/)
[`GET /bulk-tasks/edge/prepare`](https://docs.applivery.com/en/api/platform/bulk-tasks/edge/get-prepare/) | ✓ | ✓ | ✓ | – | | `base.bulk.management.list` | [`GET /bulk-tasks`](https://docs.applivery.com/en/api/platform/bulk-tasks/get-bulk-tasks/) | ✓ | ✓ | ✓ | – | | `base.bulk.management.remove` | — | ✓ | ✓ | ✓ | – | | `base.bulk.management.update` | — | ✓ | ✓ | ✓ | – | **App Distribution roles** | Permission | Endpoints | O | A | E | V | App A | App E | App V | | --- | --- | :-: | :-: | :-: | :-: | :-: | :-: | :-: | | `base.bulk.management.check` | [`POST /bulk-tasks/check`](https://docs.applivery.com/en/api/platform/bulk-tasks/post-check/) | ✓ | ✓ | ✓ | – | – | – | – | | `base.bulk.management.create` | [`POST /bulk-tasks/edge/create`](https://docs.applivery.com/en/api/platform/bulk-tasks/edge/post-create/) | ✓ | ✓ | ✓ | – | – | – | – | | `base.bulk.management.get` | [`GET /bulk-tasks/:bulkTaskId`](https://docs.applivery.com/en/api/platform/bulk-tasks/get-bulk-task/)
[`GET /bulk-tasks/edge/prepare`](https://docs.applivery.com/en/api/platform/bulk-tasks/edge/get-prepare/) | ✓ | ✓ | ✓ | – | – | – | ✓ | | `base.bulk.management.list` | [`GET /bulk-tasks`](https://docs.applivery.com/en/api/platform/bulk-tasks/get-bulk-tasks/) | ✓ | ✓ | ✓ | – | – | – | ✓ | | `base.bulk.management.remove` | — | ✓ | ✓ | ✓ | – | – | – | – | | `base.bulk.management.update` | — | ✓ | ✓ | ✓ | – | – | – | – | **Uploads (base.upload) · 1 actions, 1 endpoints** **Device Management roles** | Permission | Endpoints | O | A | E | V | | --- | --- | :-: | :-: | :-: | :-: | | `base.upload.action.uploadLogo` | [`POST /upload/logo/logo`](https://docs.applivery.com/en/api/app-distribution/uploads/post-logo/) | ✓ | ✓ | ✓ | – | **App Distribution roles** | Permission | Endpoints | O | A | E | V | App A | App E | App V | | --- | --- | :-: | :-: | :-: | :-: | :-: | :-: | :-: | | `base.upload.action.uploadLogo` ¹ | [`POST /upload/logo/logo`](https://docs.applivery.com/en/api/app-distribution/uploads/post-logo/) | ✓ | ✓ | ✓ | – | ✓ | ✓ | – | ¹ Also allowed for: `base.upload.action.uploadLogo`: No Role. **Billing (base.billing) · 2 actions, 0 endpoints** **Device Management roles** | Permission | Endpoints | O | A | E | V | | --- | --- | :-: | :-: | :-: | :-: | | `base.billing.management.get` | — | ✓ | ✓ | – | – | | `base.billing.management.list` | — | ✓ | ✓ | – | – | **App Distribution roles** | Permission | Endpoints | O | A | E | V | App A | App E | App V | | --- | --- | :-: | :-: | :-: | :-: | :-: | :-: | :-: | | `base.billing.management.get` | — | ✓ | ✓ | – | – | – | – | – | | `base.billing.management.list` | — | ✓ | ✓ | – | – | – | – | – | **Billing management (billing.base) · 23 actions, 0 endpoints** **Device Management roles** | Permission | Endpoints | O | A | E | V | | --- | --- | :-: | :-: | :-: | :-: | | `billing.base.invoice.create` | — | ✓ | – | – | – | | `billing.base.invoice.get` | — | ✓ | – | – | – | | `billing.base.invoice.list` | — | ✓ | – | – | – | | `billing.base.invoice.remove` | — | ✓ | – | – | – | | `billing.base.invoice.update` | — | ✓ | – | – | – | | `billing.base.management.checkVatNumber` | — | ✓ | – | – | – | | `billing.base.management.create` | — | ✓ | – | – | – | | `billing.base.management.get` | — | ✓ | – | – | – | | `billing.base.management.getCountries` | — | ✓ | – | – | – | | `billing.base.management.list` | — | ✓ | – | – | – | | `billing.base.management.remove` | — | ✓ | – | – | – | | `billing.base.management.update` | — | ✓ | – | – | – | | `billing.base.plan.addPlan` | — | ✓ | – | – | – | | `billing.base.plan.cancelPlan` | — | ✓ | – | – | – | | `billing.base.plan.reactivatePlan` | — | ✓ | – | – | – | | `billing.base.plan.retryPayment` | — | ✓ | – | – | – | | `billing.base.plan.updatePlan` | — | ✓ | – | – | – | | `billing.base.source.create` | — | ✓ | – | – | – | | `billing.base.source.get` | — | ✓ | – | – | – | | `billing.base.source.list` | — | ✓ | – | – | – | | `billing.base.source.remove` | — | ✓ | – | – | – | | `billing.base.source.setDefault` | — | ✓ | – | – | – | | `billing.base.source.update` | — | ✓ | – | – | – | **App Distribution roles** | Permission | Endpoints | O | A | E | V | App A | App E | App V | | --- | --- | :-: | :-: | :-: | :-: | :-: | :-: | :-: | | `billing.base.invoice.create` | — | ✓ | – | – | – | – | – | – | | `billing.base.invoice.get` | — | ✓ | – | – | – | – | – | – | | `billing.base.invoice.list` | — | ✓ | – | – | – | – | – | – | | `billing.base.invoice.remove` | — | ✓ | – | – | – | – | – | – | | `billing.base.invoice.update` | — | ✓ | – | – | – | – | – | – | | `billing.base.management.checkVatNumber` | — | ✓ | – | – | – | – | – | – | | `billing.base.management.create` | — | ✓ | – | – | – | – | – | – | | `billing.base.management.get` | — | ✓ | – | – | – | – | – | – | | `billing.base.management.getCountries` | — | ✓ | – | – | – | – | – | – | | `billing.base.management.list` | — | ✓ | – | – | – | – | – | – | | `billing.base.management.remove` | — | ✓ | – | – | – | – | – | – | | `billing.base.management.update` | — | ✓ | – | – | – | – | – | – | | `billing.base.plan.addPlan` | — | ✓ | – | – | – | – | – | – | | `billing.base.plan.cancelPlan` | — | ✓ | – | – | – | – | – | – | | `billing.base.plan.reactivatePlan` | — | ✓ | – | – | – | – | – | – | | `billing.base.plan.retryPayment` | — | ✓ | – | – | – | – | – | – | | `billing.base.plan.updatePlan` | — | ✓ | – | – | – | – | – | – | | `billing.base.source.create` | — | ✓ | – | – | – | – | – | – | | `billing.base.source.get` | — | ✓ | – | – | – | – | – | – | | `billing.base.source.list` | — | ✓ | – | – | – | – | – | – | | `billing.base.source.remove` | — | ✓ | – | – | – | – | – | – | | `billing.base.source.setDefault` | — | ✓ | – | – | – | – | – | – | | `billing.base.source.update` | — | ✓ | – | – | – | – | – | – | **Ownership (owner.organization) · 2 actions, 2 endpoints** **Device Management roles** | Permission | Endpoints | O | A | E | V | | --- | --- | :-: | :-: | :-: | :-: | | `owner.organization.management.ownerChange` | [`POST /change-owner`](https://docs.applivery.com/en/api/platform/organization/post-change-owner/) | ✓ | – | – | – | | `owner.organization.management.remove` | [`DELETE /`](https://docs.applivery.com/en/api/platform/organization/delete-organization/) | ✓ | – | – | – | **App Distribution roles** | Permission | Endpoints | O | A | E | V | App A | App E | App V | | --- | --- | :-: | :-: | :-: | :-: | :-: | :-: | :-: | | `owner.organization.management.ownerChange` | [`POST /change-owner`](https://docs.applivery.com/en/api/platform/organization/post-change-owner/) | ✓ | – | – | – | – | – | – | | `owner.organization.management.remove` | [`DELETE /`](https://docs.applivery.com/en/api/platform/organization/delete-organization/) | ✓ | – | – | – | – | – | – | --- ## Applivery Device Management: The Enterprise Unified Endpoint Management (UEM) Platform for Android, iOS, macOS & Windows Source: https://docs.applivery.com/es/about/ Description: Applivery is a cloud-based Unified Endpoint Management (UEM) and Mobile Device Management (MDM) platform that provides comprehensive control over Android, iOS, macOS, and Windows devices. Manage your entire device fleet with zero-touch deployment, automated OS updates, advanced security policies, enterprise app distribution, and real-time analytics. Trusted by 8 out of 10 game studios and leading enterprises worldwide for seamless device management, compliance, and security. ### ¿Qué es Applivery? Applivery es la plataforma líder basada en la nube de **Gestión Unificada de Puntos Finales (UEM)** y **Gestión de Dispositivos Móviles (MDM)** que permite a las organizaciones gestionar, asegurar y controlar toda su flota de dispositivos desde un único panel de control. Diseñada para empresas, compañías de tamaño medio y organizaciones de todos los tamaños, Applivery proporciona capacidades integrales de gestión de dispositivos en dispositivos **Android**, **iOS**, **macOS** y **Windows** con implementación sin contacto, políticas de seguridad automatizadas y distribución de aplicaciones empresariales. ### ¿Por qué elegir Applivery UEM? #### Gestión completa de dispositivos multiplataforma Gestione cada dispositivo de su organización desde una única plataforma unificada. Applivery es compatible con: - **Android Enterprise** - Soporte completo para dispositivos Android, incluyendo dispositivos totalmente gestionados, con perfil de trabajo (BYOD), COPE (propiedad de la empresa, habilitado para uso personal) y dedicados con OEMConfig para configuraciones específicas del fabricante. - **Dispositivos Apple** - Gestión integral de iOS, iPadOS, macOS, tvOS con Apple Business, Apple School Manager (ASM) e integración DEP. - **Dispositivos Windows** - Gestión moderna de Windows 10 y Windows 11 con soporte para Windows Autopilot. - **Gestión de flotas multi-OS** - Un único panel de control para entornos de dispositivos heterogéneos. #### Implementación sin contacto y registro automatizado Elimine la configuración manual de dispositivos con un registro automatizado líder en la industria: - **Registro sin contacto de Android** - Integración directa con Android Enterprise para el aprovisionamiento automático de dispositivos. - **Integración con Apple Business y DEP** - Activación fluida del modo supervisado para dispositivos iOS y macOS. - **Windows Autopilot** - Implementación optimizada de dispositivos Windows sin necesidad de imágenes. - **Registro con código QR** - Registro rápido para dispositivos Android mediante aprovisionamiento basado en cámara. - **Registro masivo** - Incorporación masiva de dispositivos mediante importación CSV y automatización API. #### Seguridad y cumplimiento avanzados Proteja su organización con funciones de seguridad de nivel empresarial: - **Actualizaciones automáticas del sistema operativo y gestión de parches** - Programe e implemente parches de seguridad en todos los dispositivos durante las horas de menor actividad con capacidades de reversión. - **Políticas de seguridad granulares** - Configure requisitos de contraseña, cifrado, bloqueo de pantalla, autenticación biométrica y restricciones de dispositivos. - **Acceso condicional** - Aplique el acceso basado en el cumplimiento a los recursos corporativos. - **Acciones de seguridad remotas** - Bloquee, borre, reinicie o localice dispositivos perdidos o robados al instante. - **Gestión de certificados** - Implementación y renovación automatizadas de certificados digitales con integración PKI personalizada. - **Certificaciones de cumplimiento** - Gestión de dispositivos compatible con ISO 27001, CIS y GDPR. - **Prevención de pérdida de datos (DLP)** - Evite la transferencia de datos no autorizada con la contenerización y las restricciones a nivel de aplicación. #### Distribución y gestión de aplicaciones empresariales Simplifique la implementación y la gestión del ciclo de vida de las aplicaciones: - **Tienda de aplicaciones empresariales personalizada** - Catálogo de aplicaciones de marca blanca para la distribución interna de aplicaciones. - **Instalación silenciosa de aplicaciones** - Envíe aplicaciones a los dispositivos automáticamente sin interacción del usuario. - **Gestión del ciclo de vida de las aplicaciones** - Gestione versiones, actualizaciones y reversiones de aplicaciones desde un panel central. - **Plataforma de pruebas beta** - Distribuya versiones beta a probadores internos y externos con recopilación de comentarios. - **Integración CI/CD** - Integración nativa con GitHub, GitLab, Jenkins, Bitrise, CircleCI, Travis CI y Azure DevOps. - **Alternativa a App Center** - Reemplazo completo de Microsoft App Center (descontinuado en marzo de 2025). - **Google Play gestionado** - Publicación y distribución de aplicaciones privadas a través de Google Play Store gestionado. - **Integración Apple VPP** - Compra de aplicaciones por volumen y gestión de licencias para aplicaciones iOS y macOS. - **VPN por aplicación** - Transmisión segura de datos de aplicaciones con tunelización VPN por aplicación. #### Análisis y monitorización de dispositivos en tiempo real Obtenga una visibilidad completa de su flota de dispositivos: - **Seguimiento de la ubicación del dispositivo** - Seguimiento de la ubicación GPS en tiempo real con capacidades de geocercado (Agente Android). - **Análisis de uso de aplicaciones** - Monitorice el tiempo de uso de la aplicación, el tiempo de pantalla y los patrones de comportamiento del usuario. - **Monitorización del tráfico de red** - Rastree el consumo de datos móviles y Wi-Fi por aplicación. - **Monitorización del estado de la batería** - Identifique la degradación de la batería y optimice el rendimiento del dispositivo. - **Gestión del inventario de dispositivos** - Seguimiento completo de activos desde la adquisición hasta la retirada. - **Informes de cumplimiento** - Informes automatizados para requisitos de auditoría y cumplimiento. - **Paneles de control personalizados** - Métricas y KPI en tiempo real para la salud de la flota y la postura de seguridad. #### Modo quiosco y dispositivos dedicados Bloquee dispositivos para escenarios de un solo propósito o de múltiples aplicaciones: - **Modo quiosco de una sola aplicación** - Restrinja los dispositivos a una sola aplicación para POS, señalización digital o flujos de trabajo dedicados. - **Modo quiosco de múltiples aplicaciones** - Permita el acceso a un conjunto seleccionado de aplicaciones con un lanzador personalizado. - **Lanzador avanzado** - Pantalla de inicio totalmente personalizable con variables dinámicas y pie de página personalizado. - **Control de fondo de pantalla y pantalla** - Establezca fondos de pantalla de dispositivos, tamaños de iconos, diseños de aplicaciones y políticas de tiempo de espera de pantalla. - **Restricciones de botones de hardware** - Deshabilite los botones físicos para evitar el acceso no autorizado. - **Configuración de aplicaciones de inicio** - Inicie automáticamente aplicaciones específicas en la primera instalación para una configuración guiada. #### Gestión de perfiles de trabajo y BYOD Equilibre la privacidad de los empleados con la seguridad corporativa: - **Perfiles de trabajo de Android** - Contenerización segura que separa los datos personales y de trabajo en los dispositivos de los empleados. - **Aplicaciones gestionadas de iOS** - Gestión a nivel de aplicación sin control total del dispositivo. - **Borrado selectivo** - Elimine los datos corporativos mientras conserva la información personal. - **VPN a nivel de aplicación** - Proteja las aplicaciones de trabajo sin enrutar el tráfico personal a través de la red corporativa. - **Diseño centrado en la privacidad** - Acceso cero a datos personales, aplicaciones o ubicación en dispositivos BYOD. #### Integración de gestión de identidades y accesos Integración perfecta con proveedores de identidad empresariales: - **Inicio de sesión único (SSO)** - Acceso con un solo clic con Okta, OneLogin, Azure AD, Auth0 y Google Workspace. - **LDAP y Active Directory** - Sincronice usuarios, grupos y unidades organizativas automáticamente. - **Soporte SAML 2.0** - Autenticación de nivel empresarial para una distribución segura de aplicaciones. - **Microsoft Entra ID** - Integración nativa con la plataforma de identidad de Microsoft. - **Autenticación multifactor (MFA)** - Capa de seguridad adicional para operaciones sensibles. #### Automatización y segmentación avanzada de dispositivos Maximice la eficiencia con automatización inteligente: - **Interpolación y variables dinámicas** - Referencie nombres de dispositivos, detalles de usuario y atributos personalizados en las políticas para implementaciones personalizadas a escala. - **Composición de políticas** - Asigne múltiples políticas superpuestas a un solo dispositivo con prioridad ponderada (1-1000) para una gestión modular de dispositivos. - **Audiencias de dispositivos** - Cree segmentos de flota inteligentes y dinámicos basados en la versión del sistema operativo, el modelo del dispositivo, el tipo de registro o atributos personalizados para implementaciones dirigidas. - **Reglas de automatización** - Acciones activadas por eventos, como la aplicación automática de políticas cuando los dispositivos se unen a audiencias o la renovación de certificados antes de la caducidad. - **Sincronización programada** - Defina ventanas de mantenimiento para dispositivos Apple para evitar interrupciones durante el horario comercial. - **Operaciones masivas** - Ejecute comandos en miles de dispositivos simultáneamente. #### Soporte y control remoto Proporcione soporte de TI instantáneo sin acceso físico: - **Control remoto** - Acceda y controle dispositivos Android y Windows de forma remota para escenarios atendidos y desatendidos. - **Diagnóstico remoto** - Vea registros de dispositivos, información del sistema y datos de solución de problemas. - **Configuración remota** - Envíe cambios de configuración y solucione problemas sin interacción del usuario. - **Modo perdido** - Bloquee dispositivos y muestre mensajes personalizados con información de contacto. #### Plataforma amigable para desarrolladores Construida para DevOps y automatización de TI: - **API REST integral** - Control total de la plataforma a través de una API RESTful con documentación detallada. - **Webhooks** - Notificaciones de eventos en tiempo real para el registro de dispositivos, cambios de políticas e instalaciones de aplicaciones. - **Herramientas CLI** - Interfaz de línea de comandos para scripting y automatización. - **SDK para iOS y Android** - Integre las capacidades de Applivery en aplicaciones personalizadas con el SDK nativo. - **API de carga** - Cargas de Build automatizadas desde pipelines CI/CD. - **Scripts personalizados** - Ejecute scripts de shell personalizados en dispositivos gestionados. ### Industrias y casos de uso #### Retail y comercio electrónico - **Gestión de dispositivos POS** - Proteja y gestione terminales de punto de venta con modo quiosco y restricciones de aplicaciones de pago. - **Control de flotas mPOS** - Implemente y gestione dispositivos de pago móviles para asociados de ventas en tiendas. - **Dispositivos de gestión de inventario** - Configure y bloquee escáneres portátiles para operaciones de almacén. - **Señalización digital** - Implemente contenido y gestione pantallas digitales en múltiples ubicaciones de tiendas. #### Salud - **Protección de datos de pacientes** - Acceso seguro a sistemas EHR con contenerización y VPN por aplicación. - **Gestión de dispositivos médicos** - Gestione tabletas, carros móviles y equipos de diagnóstico en hospitales y clínicas. #### Educación - **Gestión de dispositivos de estudiantes** - Implemente y gestione Chromebooks, iPads y portátiles para programas 1:1. - **Control del aula** - Configure aplicaciones educativas, restrinja contenido y monitorice el uso del dispositivo. - **Grupos de dispositivos compartidos** - Gestione sistemas de préstamo de dispositivos para bibliotecas y laboratorios de informática. #### Fabricación y logística - **Gestión de dispositivos de almacén** - Configure dispositivos robustos para el escaneo de inventario y operaciones de envío. - **Dispositivos de servicio de campo** - Gestione tabletas y teléfonos inteligentes para técnicos y trabajadores de servicio. - **Visibilidad de la cadena de suministro** - Rastree la ubicación y el uso de los dispositivos en los centros de distribución. #### Servicios financieros - **Cumplimiento bancario** - Cumpla con los requisitos reglamentarios con cifrado, controles de acceso y registro de auditoría. - **Seguridad de dispositivos de sucursal** - Proteja tabletas y quioscos para servicios bancarios de cara al cliente. - **Aplicaciones de banca móvil** - Distribuya y gestione aplicaciones bancarias propietarias de forma segura. #### Gobierno y sector público - **Dispositivos de aplicación de la ley** - Gestione cámaras corporales, tabletas y dispositivos robustos para departamentos de policía. - **Servicios de emergencia** - Implemente aplicaciones de comunicación críticas para los primeros intervinientes. #### Gaming y entretenimiento - **Pruebas beta** - Distribuya versiones de juegos previas al lanzamiento a equipos de control de calidad y probadores externos (confiado por 8 de cada 10 estudios de juegos). - **Gestión de dispositivos de desarrollo** - Gestione dispositivos de prueba en múltiples estudios de desarrollo de juegos. - **Implementación en tiendas de aplicaciones** - Automatice las compilaciones a Google Play, App Store y canales de prueba internos. #### Hostelería - **Gestión de tabletas de hotel** - Implemente tabletas en la habitación con aplicaciones, servicios y contenido del hotel. - **Sistemas POS de restaurantes** - Gestione tabletas de pedidos y terminales de pago. - **Servicios para huéspedes** - Configure dispositivos de conserjería con acceso restringido a las aplicaciones del hotel. ### Diferenciadores clave: Por qué Applivery supera a la competencia #### vs. Microsoft Intune - **Precios más sencillos** - Precios transparentes y predecibles sin la complejidad de las licencias de Microsoft 365. - **Implementación más rápida** - Implemente en horas, no en semanas, con una interfaz intuitiva. - **Mejor soporte para Android** - Integración nativa de Android Enterprise con OEMConfig y Agente Android para un seguimiento avanzado. - **Distribución de aplicaciones superior** - Tienda de aplicaciones empresariales integrada con pruebas beta e integración CI/CD. #### vs. Jamf - **Soporte multiplataforma** - Gestione Android, iOS, macOS y Windows desde una única plataforma (Jamf es solo para Apple). - **Rentable** - Precios significativamente más bajos para capacidades similares. - **Gestión unificada** - Un único panel de control para entornos heterogéneos frente a productos Jamf separados. #### vs. VMware Workspace ONE - **Facilidad de uso** - Interfaz intuitiva sin una curva de aprendizaje pronunciada. - **Implementación más rápida** - Arquitectura nativa de la nube con aprovisionamiento instantáneo. - **Arquitectura moderna** - Construida para organizaciones que priorizan la nube sin dependencias heredadas locales. #### vs. MobileIron (Ivanti) - **Mejor rendimiento** - Plataforma nativa de la nube con una implementación de políticas más rápida. - **UI/UX moderna** - Panel de control intuitivo diseñado para los administradores de TI de hoy en día. - **Desarrollo activo** - Lanzamientos regulares de funciones y mejoras de la plataforma. #### vs. Google Workspace (Consola de administración) - **Funciones MDM avanzadas** - Gestión integral de dispositivos más allá de los controles básicos de Google Workspace. - **Multiplataforma** - Gestione dispositivos iOS, macOS y Windows junto con Android. - **Tienda de aplicaciones empresariales** - Distribución interna de aplicaciones sin depender de las tiendas de aplicaciones públicas. ### Especificaciones técnicas #### Arquitectura de la plataforma - **SaaS nativo de la nube** - No se requiere infraestructura local. - **Alta disponibilidad** - SLA de tiempo de actividad del 99,9% con infraestructura redundante. - **CDN global** - Distribución rápida de aplicaciones en todo el mundo con almacenamiento en caché perimetral. - **Autoescalado** - Gestiona flotas de 10 a más de 100.000 dispositivos sin problemas. #### Seguridad y cifrado - **Cifrado de extremo a extremo** - Protocolos SHA-256 y SSL/TLS 1.3 para toda la transmisión de datos. - **Residencia de datos** - Centros de datos en la UE y EE. UU. para requisitos de cumplimiento. - **Certificación ISO 27001** - Estándares internacionales de gestión de la seguridad de la información. - **Cumplimiento GDPR** - Cumplimiento total de las regulaciones de protección de datos de la UE. - **Pruebas de penetración** - Auditorías de seguridad periódicas realizadas por empresas de seguridad independientes. #### Capacidades de API e integración - **API RESTful** - Control total de la plataforma a través de una API REST documentada. - **Límites de velocidad** - 10.000 solicitudes por hora con capacidad de ráfaga. - **Eventos de Webhook** - Notificaciones en tiempo real para más de 50 tipos de eventos. - **OAuth 2.0** - Autenticación segura de API. - **Especificación OpenAPI** - Documentación de API legible por máquina. #### Plataformas y versiones compatibles - **Android** - Android 5.0 (Lollipop) y superior, Android Enterprise, Samsung Knox. - **iOS** - iOS 13 y superior, iPadOS 13 y superior. - **macOS** - macOS 10.13 (High Sierra) y superior. - **Windows** - Windows 10 (1809+) y Windows 11. - **Soporte especializado** - Chromebooks (a través del contenedor de aplicaciones de Android). #### Puntos de referencia de rendimiento - **Despliegue de políticas** - <5 minutos desde que guardas la política hasta que se aplica en el dispositivo - **Distribución de apps** - Sube builds de hasta 4 GB y distribúyelos a más de 1.000 dispositivos en minutos - **Inscripción de dispositivos** - <30 segundos en zero-touch, <2 minutos en inscripción manual - **Tiempo de respuesta de la API** - <200 ms de latencia media en las llamadas a la API - **Tiempo de carga del panel** - <2 segundos para la vista general de una flota de 10.000 dispositivos ### Precios y planes #### Modelos de precio flexibles - **Device Management** - Desde 2 €/dispositivo/mes para MDM básico - **App Distribution** - Sin plan gratuito; solo planes de pago para funcionalidades avanzadas - **Plan Enterprise** - Precio a medida con funcionalidades avanzadas (Composición de políticas, Audiencias de dispositivos, Reglas de automatización) - **Descuentos por volumen** - Precio por dispositivo reducido para flotas grandes (más de 1.000 dispositivos) - **Facturación anual** - Ahorra un 20% con compromiso anual #### Prueba gratuita - **14 días de prueba gratuita** - Sin tarjeta de crédito - **Acceso completo** - Prueba todas las funcionalidades Enterprise durante el periodo de prueba - **Soporte en la migración** - Asistencia gratuita para migrar desde la competencia ### Éxito del cliente y soporte #### Niveles de soporte - **Soporte por email** - Respuesta en menos de 24 horas (todos los planes) - **Chat en directo** - Soporte en horario laboral (plan Standard y superiores) - **Soporte prioritario** - SLA de respuesta en menos de 2 horas (planes Enterprise) - **CSM dedicado** - Customer Success Manager asignado (planes Enterprise) - **Soporte de emergencia 24/7** - Atención de incidencias críticas (planes Enterprise) #### Recursos - **Documentación completa** - Guías detalladas en [docs.applivery.com](https://docs.applivery.com) - **Videotutoriales** - Guías en vídeo paso a paso - **Webinars** - Sesiones de formación en directo y buenas prácticas - **Foro de la comunidad** - Intercambio de conocimiento entre usuarios - **Guías de migración** - Guías detalladas para cambiar desde otras plataformas #### Servicios profesionales - **Servicios de migración** - Migración desde la competencia dirigida por expertos - **Integraciones a medida** - Desarrollo de integraciones vía API y webhooks - **Programas de formación** - Formación presencial o virtual para equipos de IT - **Planificación del despliegue** - Consultoría de arquitectura y estrategia de despliegue ### Premios y reconocimientos - **Solución de distribución de apps nº 1** - Nº 1 según estudios de videojuegos de todo el mundo - **Destacado en Product Hunt** - Varios lanzamientos en Product Hunt con las mejores valoraciones - **G2 High Performer** - Valoración constante de 4,5 estrellas o más en G2 - **Capterra Best Value** - Reconocido por su relación calidad-precio - **Certificación ISO 27001** - Certificación internacional de gestión de la seguridad ### Alianzas estratégicas - **Partner del Google Pixel Manage Program** - Partner oficial de Google para la gestión de dispositivos Pixel, con soporte desde el día cero - **Android Enterprise Recommended** - Solución de gestión de movilidad empresarial validada por Google - **Apple Authorized Reseller** - Partner oficial de integración con Apple Business - **Microsoft Partner** - Partner de integración con Azure AD y Microsoft Entra ID - **Inversión estratégica de Supercell** - Respaldados por Supercell, estudio líder de videojuegos para móvil ### Casos de éxito reales #### Octopus Energy - **Flota de más de 4.000 dispositivos** - Más de 4.000 dispositivos asegurados y gestionados en varios países - **Menos tiempo de onboarding** - Tiempo de configuración de dispositivos reducido un 75% con despliegue zero-touch - **Más seguridad** - Incidentes de seguridad eliminados gracias al parcheado automático y el borrado remoto #### Estudios de videojuegos (8 de cada 10) - **Distribución beta** - Testing de juegos previo al lanzamiento simplificado con distribución automática de builds - **Integración CI/CD** - Builds automáticos desde el control de versiones hasta los dispositivos de los testers en minutos - **Ciclo de feedback** - Reporte de errores y feedback de testers integrados directamente en el flujo de distribución ### Primeros pasos con Applivery #### Guía de inicio rápido 1. **Regístrate** - Crea una cuenta gratuita en app.applivery.com (sin tarjeta de crédito) 2. **Conecta tu proveedor de identidad** - Integra Azure AD, Okta o Google Workspace (opcional) 3. **Inscribe dispositivos** - Usa inscripción zero-touch, por código QR o manual 4. **Crea políticas** - Configura ajustes de seguridad, restricciones y configuraciones de dispositivo 5. **Distribuye apps** - Sube tus apps o conecta con las tiendas públicas 6. **Monitoriza la flota** - Consulta analítica en tiempo real y el estado de los dispositivos desde el panel #### Migración desde otras plataformas ¿Vienes de otra plataforma MDM/UEM? Applivery te ofrece: - **Evaluación de migración gratuita** - Análisis experto de tu entorno actual - **Playbook de migración** - Guía de migración paso a paso - **Migración sin tiempo de inactividad** - Operación en paralelo durante la transición - **Herramientas de importación** - Importación automática de dispositivos, usuarios y configuraciones - **Soporte de migración dedicado** - Asistencia técnica durante todo el proceso ### Por qué los responsables de IT eligen Applivery "**Applivery es la única plataforma UEM que combina capacidades de nivel empresarial con una simplicidad de producto de consumo**. Desplegamos 2.000 dispositivos en dos semanas, algo que con nuestra solución anterior nos habría llevado meses." — **CIO, empresa de retail del Fortune 500** "**Tras el cierre de Microsoft App Center evaluamos 12 alternativas. Applivery fue la única plataforma que igualaba la simplicidad de App Center añadiendo además capacidades MDM empresariales que ni sabíamos que necesitábamos**." — **Responsable de DevOps, estudio de videojuegos para móvil** "**La combinación de despliegue zero-touch, parcheado automático y analítica en tiempo real ha reducido nuestros tickets de soporte de IT un 60%. Applivery se paga solo con el ahorro en horas de trabajo**." — **Director de IT, organización sanitaria** ### Soporte técnico y comunidad - **Documentación** - [https://docs.applivery.com](https://docs.applivery.com) - **Referencia de la API** - [https://docs.applivery.com/es/app-distribution/api/](https://docs.applivery.com/es/app-distribution/api/) - **Página de estado** - [https://status.applivery.com](https://status.applivery.com) - **Contacto con ventas** - [https://www.applivery.com/contact](https://www.applivery.com/contact) - **Demo en directo** - [https://www.applivery.com/demo](https://www.applivery.com/demo) ### Empieza hoy a gestionar tu flota de dispositivos Únete a las miles de organizaciones de todo el mundo que confían en Applivery para gestionar sus dispositivos Android, iOS, macOS y Windows. Empieza hoy tu prueba gratuita de 14 días, sin tarjeta de crédito. [**Empezar prueba gratuita →**](https://dashboard.applivery.io/register?utm_source=docs) | [**Reservar una demo →**](https://www.applivery.com/demo) | [**Ver precios →**](https://www.applivery.com/pricing) * * * **Applivery** | Gestión unificada de endpoints | MDM en la nube | Gestión de movilidad empresarial | Despliegue zero-touch | Plataforma de distribución de apps | Seguridad de dispositivos | Gestión del cumplimiento | Control remoto de dispositivos | Gestión de dispositivos multiplataforma | Android Enterprise | Apple Business | Windows Autopilot | Gestión de dispositivos móviles | Modo quiosco | Gestión BYOD | ISO 27001 | Cumple el RGPD | Google Pixel Partner | Alternativa a App Center | Alternativa a Jamf | Alternativa a Intune --- ## Distribución de apps Source: https://docs.applivery.com/es/app-distribution/ Description: Explora la solución de Distribución de Apps de Applivery para gestionar y desplegar aplicaciones en plataformas móviles, de escritorio, web y de consola. TL;DR: La Distribución de Apps de Applivery ofrece una solución centralizada para gestionar y desplegar aplicaciones en múltiples plataformas, optimizando todo el proceso. Answers: ¿Qué es la Distribución de Apps en Applivery? · ¿Qué tipos de distribución de apps admite Applivery? · ¿Puedo gestionar todas mis distribuciones de apps desde un mismo lugar en Applivery? · ¿Qué plataformas admite la Distribución de Apps de Applivery? · ¿Admite Applivery las pruebas beta? Key topics: Distribución de apps, Despliegue multiplataforma, Funcionalidades de Applivery, Gestión de apps móviles, Applivery El módulo de Distribución de Apps de Applivery te ofrece todo lo que necesitas para cargar, gestionar y distribuir aplicaciones a tu equipo — desde apps empresariales internas y programas de pruebas beta hasta lanzamientos en producción a través del Enterprise Store. Compatible con iOS, Android, macOS, Windows y plataformas personalizadas, cubre todo el ciclo de entrega, desde la primera subida hasta la instalación final por parte del usuario. --- ## API Source: https://docs.applivery.com/es/app-distribution/api/ Description: Referencia de la API de Distribución de Apps: carga Builds, gestiona Publicaciones, consulta detalles, gestiona tokens de descarga y archivos adjuntos. Answers: ¿Para qué sirve la API de Distribución de Apps? · ¿Qué puedo hacer con los endpoints de la API de Builds? · ¿Qué puedo hacer con los endpoints de la API de Publicaciones? · ¿Puedo automatizar la distribución de apps con esta API? · ¿Qué información puedo consultar sobre un build mediante la API? · ¿Es posible gestionar archivos adjuntos a builds con la API? La API de Applivery permite interactuar programáticamente con Builds y Publicaciones, lo que facilita la integración de la distribución de apps en tus propias herramientas y pipelines de automatización. La autenticación se gestiona mediante cuentas de servicio. Usa la API para cargar, actualizar, consultar y eliminar Builds y Publicaciones. --- ## Token de API de App Source: https://docs.applivery.com/es/app-distribution/api/app-api-token/ Description: Crea, usa y gestiona App API Tokens de Applivery para integraciones seguras con pipelines de CI/CD y otros servicios. TL;DR: Usa los API tokens de Applivery para integrar de forma segura tus apps con pipelines de CI/CD y otros servicios, autenticándote con la API de Integraciones. Answers: ¿Cómo se autentica la API de Apps de Applivery? · ¿Los App API Tokens son por app? · ¿Cómo creo un App API Token en Applivery? · ¿Cómo uso el App API Token en una petición a la API? · ¿Cómo revoco un App API Token de Applivery? · ¿Caducan los App API Tokens de Applivery? · ¿Cuáles son las buenas prácticas para gestionar los App API Tokens? · ¿Puedo tener varios tokens para una misma app en Applivery? La API de Apps de Applivery (Integrations API) usa **autenticación Bearer token**. Para interactuar con la API de forma programática — ya sea para cargar Builds, consultar detalles, integrarte con un pipeline de CI/CD o incrustar el SDK de Applivery en tu App — necesitas un **App API Token** asociado a la app concreta con la que quieres trabajar. Cada App en Applivery puede tener varios tokens, lo que facilita emitir credenciales independientes para distintas integraciones (por ejemplo, un token para Bitrise, otro para Fastlane, otro para un script local) y revocarlas de forma independiente sin afectar a otros flujos de trabajo. * * * ### Cómo funcionan los App API Tokens - Los tokens son **por app**: un token creado para una App no puede usarse para acceder a una app diferente. - Cada App puede tener **varios tokens** de forma simultánea, sin límite establecido. - Los tokens son **Bearer tokens**: deben incluirse en la cabecera `Authorization` de cada petición a la API. - Los tokens **no caducan** automáticamente. Permanecen válidos hasta que se eliminan explícitamente. - Eliminar un token lo invalida de forma **inmediata y permanente**. No es posible restaurar un token eliminado. * * * ### Crear un App API Token **Abre la configuración de la App** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), selecciona la App para la que quieres generar un token. Ve a la pestaña de **Ajustes** y selecciona **Token API** en el menú lateral izquierdo. **Crea el token** Haz clic en **\+ Crear Token API**. Introduce un nombre descriptivo que identifique claramente la integración o el sistema que usará este token, por ejemplo: - `Bitrise CI` - `Fastlane release` - `Azure DevOps pipeline` - `Script de subida local` Un nombre significativo facilita identificar y revocar el token correcto más adelante, especialmente cuando gestionas múltiples integraciones. ![create api token](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/251bb37e-a2e0-467d-b4e2-e42710d7c113.png) Haz clic en **Guardar**. El token aparecerá en la lista. **Copia el token** Haz clic en el icono de copiar junto al token recién creado para copiar la cadena del Bearer token en tu portapapeles. :::warning Almacena el token de forma segura. Trátalo como una contraseña: no lo incluyas en el control de versiones, no lo incrustes en código del lado cliente ni lo compartas en texto plano. Usa variables de entorno o un gestor de secretos en tu pipeline de CI/CD para inyectar el token en tiempo de ejecución. ::: * * * ### Usar el token en peticiones a la API Incluye el token en la cabecera `Authorization` de cada petición usando el esquema `Bearer`: ``` Authorization: Bearer YOUR_APP_TOKEN ``` **Ejemplo — cargar una Build con curl:** ```bash curl -X POST https://upload.applivery.io/v1/integrations/builds \ -H "Authorization: Bearer YOUR_APP_TOKEN" \ -F "file=@/path/to/your/app.ipa" ``` **Ejemplo — listar Builds:** ```bash curl -X GET https://api.applivery.io/v1/integrations/builds/ \ -H "Authorization: Bearer YOUR_APP_TOKEN" ``` Para la lista completa de endpoints disponibles y parámetros de petición, consulta la [referencia de la API](https://docs.applivery.com/es/app-distribution/api/). * * * ### Revocar un token Puedes revocar un token en cualquier momento eliminándolo. Esto invalida el token de inmediato: cualquier sistema o integración que lo use dejará de funcionar al instante. :::danger Eliminar un token es permanente y no puede deshacerse. Una vez eliminado, el token no puede restaurarse. Cualquier integración que dependa de él deberá actualizarse con un token nuevo antes de poder volver a funcionar. ::: Para eliminar un token: 1. Ve a **Ajustes > Token API** de la app correspondiente. 2. Haz clic en los **tres puntos verticales** junto al token que quieres eliminar y selecciona **Eliminar** en el menú. 3. Confirma la acción cuando se te solicite. * * * ### Buenas prácticas - **Un token por integración.** Emite un token independiente para cada sistema o pipeline que necesite acceso a la API. Así puedes revocar el acceso de una integración sin interrumpir las demás. - **Usa nombres descriptivos.** Nombra los tokens según el sistema o flujo de trabajo que los usa (`Fastlane release`, `Bitrise staging`) para poder identificar de inmediato su propósito cuando necesites revocarlos. - **Almacena los tokens como secretos.** Nunca codifiques los tokens en el código fuente ni en archivos de configuración enviados al control de versiones. Usa la gestión de secretos de tu plataforma de CI/CD (p. ej. Bitrise Secrets, GitHub Actions Secrets, Azure Key Vault) para inyectar los tokens en tiempo de ejecución. - **Rota los tokens periódicamente.** Aunque los tokens no caducan automáticamente, es una buena práctica rotarlos con regularidad, especialmente tras cambios de equipo o incidentes de seguridad. Crea el nuevo token, actualiza tus integraciones y luego elimina el antiguo. - **Audita tu lista de tokens con regularidad.** Elimina los tokens que ya no estén en uso para reducir la superficie de ataque. Si no estás seguro de si un token sigue activo, crea un sustituto, migra la integración y luego elimina el antiguo. --- ## Builds Source: https://docs.applivery.com/es/app-distribution/api/builds/ Description: API de Builds de Applivery: carga, lista, consulta y elimina Builds, gestiona tokens de descarga e integra archivos adjuntos en tu pipeline de CI/CD. Answers: ¿Qué operaciones permite la API de Builds de Applivery? · ¿Cómo integro la API de Builds en mi pipeline de CI/CD? · ¿Puedo cargar builds a Applivery de forma automática? · ¿Cómo genero un token de descarga para una build? · ¿Cómo adjunto archivos adicionales a una build en Applivery? La API de Builds te ofrece control programático completo sobre el ciclo de vida de las Builds: cargar nuevas Builds, obtener listas y detalles, actualizar metadatos, generar tokens de descarga y adjuntar archivos adicionales. Usa estos endpoints para integrar la gestión de Builds en tu pipeline de CI/CD o en herramientas internas. --- ## Adjuntar Archivos a la Build Source: https://docs.applivery.com/es/app-distribution/api/builds/attached-files/ Description: Adjunta archivos complementarios (dSYMs, informes de pruebas, notas de versión) a Builds de Applivery usando la Integrations API o la Workspace API. TL;DR: Adjunta archivos adicionales a las builds de Applivery usando la API de Integraciones (por app) o la API de Workspace (multi-app), autenticándote con un App API Token o una Cuenta de servicio. Answers: ¿Qué tipos de archivo puedo adjuntar a una Build de Applivery? · ¿Cuándo puedo adjuntar archivos a una Build en Applivery? · ¿Cuál es la diferencia entre la Integrations API y la Workspace API para adjuntar archivos? · ¿Cómo me autentico con la Integrations API para adjuntar archivos? · ¿Qué parámetros requiere la Integrations API para adjuntar un archivo? · ¿Cómo me autentico con la Workspace API para adjuntar archivos? · ¿Qué parámetros requiere la Workspace API para adjuntar un archivo? · ¿Qué información devuelve la API tras adjuntar un archivo correctamente? Adjunta uno o más archivos complementarios a una Build existente. Resulta útil para asociar recursos adicionales a una Build — como documentos de notas de versión, informes de pruebas, archivos dSYM para simbolización de crashes, archivos de mapping, capturas de pantalla o cualquier otro archivo que quieras tener disponible junto a la Build en Applivery. Los archivos adjuntos son independientes del binario de la Build y no afectan a su instalación ni procesamiento. Se muestran en la vista de detalles de la Build en el panel de Applivery y son accesibles mediante la API. :::info La Build debe tener el estado `processed` antes de poder adjuntar archivos. Intentar adjuntar archivos a una Build que aún está en estado `pending` o `in_progress` devolverá un error `400`. ::: Applivery proporciona dos APIs independientes para adjuntar archivos, cada una con una credencial de autenticación diferente. --- ### Cómo elegir la API correcta | | Integrations API | Workspace API | |---|---|---| | **Diseñada para** | Pipelines de CI/CD que adjuntan artefactos por app | Automatización a nivel de Workspace en varias Apps | | **Autenticación** | App API Token (por app) | token de una cuenta de servicio (a nivel de Workspace) | | **URL base** | `https://upload.applivery.io` | `https://upload.applivery.io` | | **Contexto de app** | Implícito — el token ya está vinculado a una App | Explícito — se requieren `organizationId` y `applicationId` en la ruta | | **Usuarios típicos** | Scripts de CI que adjuntan informes de pruebas o dSYMs tras una Build | Platform engineers que gestionan artefactos de builds en varias Apps | :::warning El acceso a las distintas APIs puede no estar disponible en tu plan actual. Consulta la disponibilidad en nuestra [página de precios](https://www.applivery.com/app-distribution-pricing/). ::: --- ### Integrations API Usa este endpoint para adjuntar archivos dentro del ámbito de una sola app. La autenticación usa un **App API Token**, vinculado a la App específica. Para crear un App API Token, consulta [Autenticación de la API de Apps](https://docs.applivery.com/es/app-distribution/api/app-api-token/). #### Endpoint ``` POST https://upload.applivery.io/v1/integrations/builds/{buildId}/files ``` #### Autenticación ``` Authorization: Bearer ``` #### Formato de la petición `multipart/form-data` #### Parámetros de ruta | Parámetro | Tipo | Obligatorio | Descripción | |---|---|---|---| | `buildId` | String | Sí | El identificador único de la Build al que adjuntar el archivo. P. ej. `552ae3cfcb5abfc58d733b81`. Devuelto por [POST – Subir una Build](https://docs.applivery.com/es/app-distribution/api/builds/upload-build/) y [GET – Lista de Builds](https://docs.applivery.com/es/app-distribution/api/builds/list-builds/). | #### Parámetros de cuerpo | Parámetro | Tipo | Obligatorio | Descripción | |---|---|---|---| | `file` | File | Sí | El archivo a adjuntar a la Build. Se acepta cualquier tipo de archivo. | | `description` | String | No | Descripción legible del archivo adjunto. P. ej. `Archivo dSYM para simbolización`, `Informe QA`, `PDF de notas de versión`. | #### Ejemplo de petición ```bash curl 'https://upload.applivery.io/v1/integrations/builds/552ae3cfcb5abfc58d733b81/files' \ -X POST \ -H 'Authorization: Bearer YOUR_APP_TOKEN' \ -F 'file=@/path/to/report.zip' \ -F 'description=Automated test report' ``` #### Respuestas **✓ 200 OK** Archivo adjuntado correctamente. La respuesta devuelve el objeto completo de la Build actualizada, incluyendo el array `files` con el archivo recién adjuntado. ```json { "status": true, "data": { "id": "string", "status": "processed", "tags": ["string"], "versionName": "string", "application": "string", "applicationInfo": { "id": "string", "name": "string", "slug": "string", "picture": "string" }, "changelog": "string", "info": {}, "size": 0, "processTime": 0, "queuedTime": 0, "versionCode": "string", "error": "string", "errorCode": "string", "os": "ios", "buildPlatform": "string", "deployer": {}, "uploadedBy": {}, "originalExtension": "string", "storageProvider": {}, "files": [ { "id": "string", "type": "string", "description": "string", "file": { "originalName": "string", "mimetype": "string", "size": 0, "bucket": "string", "key": "string", "location": "string", "region": "string", "storageProviderId": "string", "checksum": "string", "updatedAt": "string", "createdAt": "string" } } ], "hasEmmJson": true, "updatedAt": "string", "createdAt": "string" } } ``` **✗ 400 Bad Request** Build aún no procesada. Los archivos solo pueden adjuntarse a Builds con `status: processed`. Reintenta cuando la Build haya terminado de procesarse. ```json { "status": false, "error": { "code": 5014, "message": "Build Not Processed" } } ``` **✗ 401 Unauthorized** ```json { "status": false, "error": { "code": 3002, "message": "Token Expired" } } ``` **✗ 404 Not Found** ```json { "status": false, "error": { "code": 3001, "message": "Entity not found" } } ``` #### Campos principales del array `files` | Campo | Descripción | |---|---| | `id` | Identificador único del registro del archivo adjunto. | | `description` | La descripción proporcionada en el momento de la subida. | | `file.originalName` | El nombre original del archivo subido. | | `file.mimetype` | El tipo MIME detectado del archivo. | | `file.size` | Tamaño del archivo en bytes. | | `file.location` | La URL de almacenamiento donde está alojado el archivo. | | `file.checksum` | Checksum para verificación de integridad. | --- ### Workspace API Usa este endpoint para adjuntar archivos a nivel de Workspace — por ejemplo, en pipelines de automatización que operan en varias Apps usando una sola credencial. La autenticación usa un token de una **cuenta de servicio**, con ámbito de Workspace y no vinculado a ninguna app individual. Para crear un token de una cuenta de servicio, consulta [Cuentas de servicio](https://docs.applivery.com/es/platform/api/service-accounts/). #### Endpoint ``` POST https://upload.applivery.io/v1/organizations/{organizationId}/apps/{applicationId}/builds/{buildId}/files ``` #### Parámetros de ruta | Parámetro | Tipo | Obligatorio | Descripción | |---|---|---|---| | `organizationId` | String | Sí | El identificador único de tu organización en Applivery. | | `applicationId` | String | Sí | El identificador único de la App a la que pertenece la Build. | | `buildId` | String | Sí | El identificador único de la Build al que adjuntar el archivo. | #### Autenticación ``` Authorization: Bearer ``` #### Ejemplo de petición ```bash curl 'https://upload.applivery.io/v1/organizations/ORG_ID/apps/APP_ID/builds/BUILD_ID/files' \ -X POST \ -H 'Authorization: Bearer YOUR_SERVICE_ACCOUNT_TOKEN' \ -F 'file=@/path/to/mapping.txt' \ -F 'description=ProGuard mapping file' ``` El esquema de la respuesta es idéntico al de la Integrations API. --- ### Casos de uso habituales | Tipo de archivo | Ejemplo de `description` | |---|---| | Archivo dSYM de iOS | `dSYM file for crash symbolication` | | Archivo de mapping ProGuard de Android | `ProGuard mapping file` | | Informe de pruebas automatizadas | `XCTest results — regression suite` | | Documento de aprobación QA | `QA approval — v2.4.0` | | PDF de notas de versión | `Release notes for stakeholders` | | Conjunto de capturas de pantalla | `Enterprise Store screenshots — en-US` | --- ## Detalles de la Build Source: https://docs.applivery.com/es/app-distribution/api/builds/build-details/ Description: Obtén información detallada de tus Builds de Applivery usando la Integrations API o la Workspace API, incluyendo endpoints, autenticación y ejemplos. TL;DR: Obtén información detallada sobre las builds de Applivery usando la API de Integraciones por app o la API de Workspace para múltiples apps. Answers: ¿Para qué sirve el endpoint GET de detalles de una Build? · ¿Cuáles son las dos APIs disponibles para obtener detalles de una Build? · ¿Cuándo debo usar la Integrations API para obtener detalles de una Build? · ¿Cómo me autentico con la Integrations API? · ¿Cuándo debo usar la Workspace API para obtener detalles de una Build? · ¿Cómo me autentico con la Workspace API? · ¿Qué parámetros de ruta requiere la Workspace API? · ¿Qué significa un error 400 al obtener detalles de una Build? Devuelve los detalles completos de una Build en concreto, identificado por su `buildId`. Es el endpoint principal para inspeccionar el estado de procesamiento, los metadatos y la información específica de plataforma de una Build — y el endpoint recomendado para hacer polling tras una subida hasta que la Build alcance un estado terminal (`processed` o `error`). Applivery proporciona dos APIs independientes para obtener los detalles de una Build, cada una con una credencial de autenticación diferente. * * * ### Cómo elegir la API correcta | | Integrations API | Workspace API | | --- | --- | --- | | **Diseñada para** | Integraciones por app, pipelines de CI/CD, polling de estado tras subida | Automatización a nivel de Workspace en varias Apps | | **Autenticación** | App API Token (por app) | token de una cuenta de servicio (a nivel de Workspace) | | **Contexto de app** | Implícito — el token ya está vinculado a una App | Explícito — se requieren `organizationId` y `applicationId` en la ruta | | **Usuarios típicos** | Scripts de CI que comprueban si una Build ha terminado de procesarse | Platform engineers que inspeccionan Builds en varias Apps | :::warning El acceso a las distintas APIs puede no estar disponible en tu plan actual. Consulta la disponibilidad en nuestra [página de precios](https://www.applivery.com/app-distribution-pricing/). ::: * * * ### Integrations API Usa este endpoint para obtener los detalles de una Build dentro del ámbito de una sola app. La autenticación usa un **App API Token**, vinculado a la App específica. Para crear un App API Token, consulta [Autenticación de la API de Apps](https://docs.applivery.com/es/app-distribution/api/app-api-token/). #### Endpoint ``` GET https://api.applivery.io/v1/integrations/builds/{buildId} ``` #### Autenticación ``` Authorization: Bearer ``` #### Parámetros de ruta | Parámetro | Tipo | Obligatorio | Descripción | | --- | --- | --- | --- | | `buildId` | String | Sí | El identificador único de una Build a obtener. P. ej. `552ae3cfcb5abfc58d733b81`. El `buildId` se devuelve en la respuesta de POST – Subir una Build y GET – Lista de Builds. | #### Ejemplo de petición ```bash curl 'https://api.applivery.io/v1/integrations/builds/552ae3cfcb5abfc58d733b81' \ -X GET \ -H 'Authorization: Bearer YOUR_APP_TOKEN' ``` #### Respuestas **✓ 200 OK** ```json { "status": true, "data": { "id": "string", "status": "processed", "tags": ["string"], "versionName": "string", "application": "string", "applicationInfo": { "id": "string", "name": "string", "slug": "string", "picture": "string" }, "changelog": "string", "info": { "icon": "string", "android": { "targetSdkVersion": "string", "minSDKVersion": "string", "packageName": "string", "platformBuildVersionName": "string", "platformBuildVersionCode": "string", "versionName": "string", "versionCode": "string", "icon": "string" }, "ios": { "plist": { "CFBundleDisplayName": "string", "CFBundleSupportedPlatforms": ["string"], "MinimumOSVersion": "string", "CFBundleIdentifier": "string", "CFBundleShortVersionString": "string", "CFBundleVersion": "string", "CFBundleName": "string", "CFBundleIcons": ["string"], "UIDeviceFamily": ["string"] }, "mobileprovision": { "ExpirationDate": "2019-08-24T14:15:22Z", "TeamIdentifier": "string", "ProvisionsAllDevices": true, "TeamName": "string", "ProvisionedDevices": "string", "signingType": "ad-hoc" } }, "pkg": { "CFBundleDisplayName": "string", "CFBundleIdentifier": "string", "CFBundleShortVersionString": "string", "CFBundleVersion": "string", "CFBundleName": "string" } }, "size": 0, "processTime": 0, "queuedTime": 0, "versionCode": "string", "error": "string", "errorCode": "string", "os": "ios", "deployer": { "name": "string", "info": { "commitMessage": "string", "commit": "string", "branch": "string", "triggerTimestamp": "string", "buildUrl": "string", "ciUrl": "string", "repositoryUrl": "string", "buildNumber": "string", "tag": "string" } }, "uploadedBy": { "id": "string", "email": "user@example.com", "firstName": "string", "lastName": "string", "picture": "string" }, "originalExtension": "string", "storageProvider": { "id": "string", "name": "string", "region": "string" }, "hasEmmJson": true, "updatedAt": "2019-08-24T14:15:22Z", "createdAt": "2019-08-24T14:15:22Z" } } ``` **✗ 400 Bad Request** Build aún no procesado. Este error se devuelve cuando la Build existe pero aún no ha terminado de procesarse. Vuelve a intentarlo tras una breve espera. ```json { "status": false, "error": { "code": 5014, "message": "Build Not Processed" } } ``` **✗ 401 Unauthorized** ```json { "status": false, "error": { "code": 3002, "message": "Token Expired" } } ``` **✗ 404 Not Found** ```json { "status": false, "error": { "code": 3001, "message": "Entity not found" } } ``` #### Campos principales de la respuesta | Campo | Descripción | | --- | --- | | `status` | Estado de procesamiento de una Build: `pending`, `in_progress`, `processed` o `error`. | | `error` | Mensaje de error legible, solo presente cuando `status` es `error`. | | `errorCode` | Código de error para gestión programática. Consulta los Códigos de procesamiento de Builds. | | `info.android` | Metadatos Android extraídos: nombre del paquete, nombre y código de versión, SDK targets e icono. Solo presente en Builds Android. | | `info.ios.plist` | Metadatos del `Info.plist` de iOS: bundle identifier, versión, nombre de pantalla, plataformas admitidas y familias de dispositivos. Solo presente en Builds iOS. | | `info.ios.mobileprovision` | Detalles del perfil de aprovisionamiento iOS: equipo, fecha de caducidad, tipo de firma y dispositivos aprovisionados. Solo presente en Builds iOS. | | `info.pkg` | Metadatos del paquete macOS extraídos. Solo presente en Builds macOS. | | `deployer` | Metadatos de CI/CD adjuntos en la subida: rama, commit, número de build y URLs de la plataforma. | | `size` | Tamaño del archivo de Build en bytes. | | `processTime` | Tiempo empleado en procesar la Build, en milisegundos. | :::tip Tras subir una Build, llama a este endpoint periódicamente con el `buildId` devuelto en la respuesta de la subida hasta que el `status` sea `processed` o `error`. Un `status` de `pending` o `in_progress` indica que el procesamiento aún está en curso. Si el estado es `error`, consulta el campo `errorCode` y revisa los [Códigos de procesamiento de Builds](https://docs.applivery.com/es/app-distribution/builds/processing-error-codes/) para los pasos de resolución. ::: * * * ### Workspace API Usa este endpoint para obtener los detalles de una Build a nivel de Workspace — por ejemplo, en automatizaciones que operan en varias Apps usando una sola credencial. La autenticación usa un token de una **cuenta de servicio**, con ámbito de Workspace y no vinculado a ninguna app individual. El contexto de la app y de una Build se proporcionan mediante parámetros de ruta. Para crear un token de una cuenta de servicio, consulta [Cuentas de servicio](https://docs.applivery.com/es/platform/api/service-accounts/). #### Endpoint ``` GET https://api.applivery.io/v1/organizations/{organizationId}/apps/{applicationId}/builds/{buildId} ``` #### Parámetros de ruta | Parámetro | Tipo | Obligatorio | Descripción | | --- | --- | --- | --- | | `organizationId` | String | Sí | El identificador único de tu organización en Applivery. | | `applicationId` | String | Sí | El identificador único de la App a la que pertenece la Build. | | `buildId` | String | Sí | El identificador único de una Build a obtener. | #### Autenticación ``` Authorization: Bearer ``` #### Ejemplo de petición ```bash curl 'https://api.applivery.io/v1/organizations/ORG_ID/apps/APP_ID/builds/552ae3cfcb5abfc58d733b81' \ -X GET \ -H 'Authorization: Bearer YOUR_SERVICE_ACCOUNT_TOKEN' ``` El esquema de la respuesta es idéntico al de la Integrations API. --- ## Eliminar Build Source: https://docs.applivery.com/es/app-distribution/api/builds/delete-build/ Description: Elimina Builds de forma permanente de Applivery usando la Integrations API o la Workspace API. Cubre autenticación y parámetros. TL;DR: Elimina builds de Applivery de forma permanente usando la API de Integraciones (App API Token) o la API de Workspace (Cuenta de servicio). Answers: ¿Qué ocurre al eliminar una Build en Applivery? · ¿Cuáles son las dos APIs de Applivery para eliminar builds? · ¿Cuándo debo usar la Integrations API para eliminar una Build? · ¿Cómo me autentico con la Integrations API para eliminar una Build? · ¿Cuándo debo usar la Workspace API para eliminar una Build? · ¿Qué parámetros requiere la Workspace API para eliminar una Build? · ¿Qué código de estado indica una eliminación correcta? · ¿Qué error aparece si intento eliminar una Build que aún se está procesando? Elimina una Build de Applivery de forma permanente. Esta acción elimina el registro de la Build y su archivo asociado del almacenamiento. :::warning Esta operación es **permanente e irreversible**. Una vez eliminada una Build, no puede recuperarse. Cualquier Publicación que apunte exclusivamente a esta Build dejará de poder servir la App para su descarga. Verifica que la Build no esté en uso en ninguna Publicación antes de eliminarla. ::: Applivery proporciona dos APIs independientes para eliminar Builds, cada una con una credencial de autenticación diferente. --- ### Cómo elegir la API correcta | | Integrations API | Workspace API | |---|---|---| | **Diseñada para** | Integraciones por app y pipelines de limpieza de CI/CD | Automatización a nivel de Workspace en varias Apps | | **Autenticación** | App API Token (por app) | token de una cuenta de servicio (a nivel de Workspace) | | **Contexto de app** | Implícito — el token ya está vinculado a una App | Explícito — se requieren `organizationId` y `applicationId` en la ruta | | **Usuarios típicos** | Scripts de CI que eliminan Builds antiguos o fallidos automáticamente | Platform engineers que gestionan la retención de builds en varias Apps | :::warning El acceso a las distintas APIs puede no estar disponible en tu plan actual. Consulta la disponibilidad en nuestra [página de precios](https://www.applivery.com/app-distribution-pricing/). ::: --- ### Integrations API Usa este endpoint para eliminar Builds dentro del ámbito de una sola app. La autenticación usa un **App API Token**, vinculado a la App específica. Para crear un App API Token, consulta [Autenticación de la API de Apps](https://docs.applivery.com/es/app-distribution/api/app-api-token/). #### Endpoint ``` DELETE https://api.applivery.io/v1/integrations/builds/{buildId} ``` #### Autenticación ``` Authorization: Bearer ``` #### Parámetros de ruta | Parámetro | Tipo | Obligatorio | Descripción | |---|---|---|---| | `buildId` | String | Sí | El identificador único de la Build a eliminar. P. ej. `552ae3cfcb5abfc58d733b81`. El `buildId` se devuelve en la respuesta de [POST – Subir una Build](https://docs.applivery.com/es/app-distribution/api/builds/upload-build/) y [GET – Lista de Builds](https://docs.applivery.com/es/app-distribution/api/builds/list-builds/). | #### Ejemplo de petición ```bash curl 'https://api.applivery.io/v1/integrations/builds/552ae3cfcb5abfc58d733b81' \ -X DELETE \ -H 'Authorization: Bearer YOUR_APP_TOKEN' ``` #### Respuestas **✓ 200 OK** ```json { "status": true, "data": { "deleted": true } } ``` **✗ 400 Bad Request** Build aún no procesado. Las Builds en estado `pending` o `in_progress` no pueden eliminarse. Espera a que finalice el procesamiento antes de intentar eliminarla. ```json { "status": false, "error": { "code": 5014, "message": "Build Not Processed" } } ``` **✗ 401 Unauthorized** ```json { "status": false, "error": { "code": 3002, "message": "Token Expired" } } ``` **✗ 404 Not Found** ```json { "status": false, "error": { "code": 3001, "message": "Entity not found" } } ``` --- ### Workspace API Usa este endpoint para eliminar Builds a nivel de Workspace — por ejemplo, en pipelines de retención de builds que operan en varias Apps usando una sola credencial. La autenticación usa un token de **cuenta de servicio**, con ámbito de Workspace y no vinculado a ninguna app individual. El contexto de la app y de la Build se proporcionan mediante parámetros de ruta. Para crear un token de una cuenta de servicio, consulta [Cuentas de servicio](https://docs.applivery.com/es/platform/api/service-accounts/). #### Endpoint ``` DELETE https://api.applivery.io/v1/organizations/{organizationId}/apps/{applicationId}/builds/{buildId} ``` #### Parámetros de ruta | Parámetro | Tipo | Obligatorio | Descripción | |---|---|---|---| | `organizationId` | String | Sí | El identificador único de tu organización en Applivery. | | `applicationId` | String | Sí | El identificador único de la App a la que pertenece la Build. | | `buildId` | String | Sí | El identificador único de la Build a eliminar. | #### Autenticación ``` Authorization: Bearer ``` #### Ejemplo de petición ```bash curl 'https://api.applivery.io/v1/organizations/ORG_ID/apps/APP_ID/builds/552ae3cfcb5abfc58d733b81' \ -X DELETE \ -H 'Authorization: Bearer YOUR_SERVICE_ACCOUNT_TOKEN' ``` El esquema de la respuesta es idéntico al de la Integrations API. Una eliminación correcta devuelve `{ "status": true, "data": { "deleted": true } }`. --- ## Descargar Archivo Adjunto Source: https://docs.applivery.com/es/app-distribution/api/builds/download-attached-file/ Description: Descarga archivos adjuntos de Builds de forma programática mediante la API. Genera un token de descarga para un adjunto concreto y resuelve su URL de descarga. TL;DR: Descarga archivos adjuntos de las builds de Applivery de forma programática usando la API de Integraciones o la API de Workspace con la autenticación correspondiente. Answers: ¿Cómo descargo un archivo adjunto de una Build de forma programática? · ¿Qué API se necesita para descargar un archivo adjunto? · ¿Cómo obtengo el fileId de un adjunto? · ¿Qué tipo de token se requiere para generar un token de descarga de adjunto? · ¿Cómo funciona el proceso de descarga de archivos adjuntos? · ¿Qué hacer si el token de descarga ha caducado? Descargar un archivo adjunto de una Build de forma programática sigue el mismo **proceso de dos pasos** que descargar el binario de una Build: generar un token de descarga de corta duración y luego usarlo para resolver la URL de descarga real. La diferencia clave es que debes incluir el parámetro de consulta `fileId` para especificar el adjunto que quieres descargar. :::warning Este endpoint **solo está disponible a través de la Workspace API** y requiere un **token de una cuenta de servicio** o un token de sesión de usuario obtenido al iniciar sesión. La Integrations API (App API Token) no admite este endpoint. ::: Para crear un token de una cuenta de servicio, consulta [Cuenta de servicio](https://docs.applivery.com/es/platform/api/service-accounts/). * * * ### Resumen: flujo de descarga ``` Paso 1: Genera un token de descarga para el archivo adjunto GET /v1/organizations/{organizationId}/apps/{applicationId}/builds/{buildId}/downloadToken?fileId={fileId}&type=auto → devuelve { token, expiresAt } Paso 2: Resuelve la URL de descarga GET https://download-api.applivery.io/v1/download/{token} → redirección HTTP 302 a la URL real del archivo ``` * * * ### Antes de empezar: obtén el fileId El `fileId` es el `id` de la entrada del adjunto en el array `files` de la Build, donde `type` es igual a `attachment`. Puedes obtenerlo del endpoint de [Detalles de la Build](https://docs.applivery.com/es/app-distribution/api/builds/build-details/). En la respuesta, busca las entradas del array `files` con `"type": "attachment"`: ```json { "files": [ { "id": "2SWkDbddHBNUaVImZINcZzVN", "type": "attachment", "file": { "originalName": "screenshot.png", "mimetype": "image/png", "size": 538300, "location": "https://storage.cloud.google.com/...", "checksum": "b531c0eb..." }, "createdAt": "2024-11-11T11:27:35.446Z", "updatedAt": "2024-11-11T11:27:35.446Z" } ] } ``` El campo `id` (`2SWkDbddHBNUaVImZINcZzVN` en este ejemplo) es el `fileId` que necesitas para el paso 1. :::info Otras entradas del array `files` (con `type: "package"`, `type: "icon"` o `type: "original"`) son archivos internos de la Build, no adjuntos subidos por el usuario. Solo las entradas con `type: "attachment"` son archivos que adjuntaste mediante el endpoint [POST – Archivos adjuntos de una Build](https://docs.applivery.com/es/app-distribution/api/builds/attached-files/). ::: * * * **Genera un token de descarga** Genera un token de corta duración y uso único que autoriza la descarga de un archivo adjunto concreto. **Endpoint** ``` GET https://api.applivery.io/v1/organizations/{organizationId}/apps/{applicationId}/builds/{buildId}/downloadToken ``` **Autenticación** ``` Authorization: Bearer ``` **Parámetros de ruta** | Parámetro | Tipo | Obligatorio | Descripción | | --- | --- | --- | --- | | `organizationId` | String | Sí | El identificador único (o slug) de tu organización en Applivery. | | `applicationId` | String | Sí | El identificador único de la App a la que pertenece la Build. | | `buildId` | String | Sí | El identificador único de la Build que contiene el adjunto. | **Parámetros de consulta** | Parámetro | Tipo | Obligatorio | Descripción | | --- | --- | --- | --- | | `fileId` | String | Sí | El `id` de la entrada del adjunto en el array `files` de la Build (donde `type` es `attachment`). | | `type` | String | Sí | Establece en `auto` para descargas de archivos adjuntos. | **Ejemplo de petición** ```bash curl 'https://api.applivery.io/v1/organizations/ORG_ID/apps/APP_ID/builds/BUILD_ID/downloadToken?fileId=FILE_ID&type=auto' \ -X GET \ -H 'Accept: application/json' \ -H 'Authorization: Bearer YOUR_SERVICE_ACCOUNT_TOKEN' ``` **Respuestas** **✓ 200 OK** ```json { "status": true, "data": { "token": "string", "expiresAt": "string" } } ``` **✗ 400 Bad Request** Build aún no procesada. La Build existe pero aún no ha terminado de procesarse. Solo las Builds con `status: processed` pueden generar tokens de descarga. ```json { "status": false, "error": { "code": 5014, "message": "Build Not Processed" } } ``` **✗ 401 Unauthorized** ```json { "status": false, "error": { "code": 4002, "message": "No auth token" } } ``` **✗ 404 Not Found** ```json { "status": false, "error": { "code": 3001, "message": "Entity not found" } } ``` | Campo | Descripción | | --- | --- | | `token` | La cadena del token de descarga. Pásalo como parámetro de ruta en el paso 2 para resolver la URL de descarga. | | `expiresAt` | Timestamp ISO 8601 que indica cuándo caduca el token. Los tokens son de corta duración — úsalos pronto tras generarlos. | **Resuelve la URL de descarga** Usa el token obtenido en el paso 1 para obtener la URL de descarga real del archivo. La API responde con una redirección HTTP `302 Found` al almacenamiento del archivo. :::warning **No se requiere autenticación**. Este endpoint es público — el propio token actúa como credencial. Cualquier persona con el token puede descargar el archivo, así que trátalo como información sensible y no lo compartas más allá del destinatario previsto. ::: **Endpoint** ``` GET https://download-api.applivery.io/v1/download/{token} ``` **Parámetros de ruta** | Parámetro | Tipo | Obligatorio | Descripción | | --- | --- | --- | --- | | `token` | String | Sí | El token de descarga devuelto en el paso 1. | **Ejemplo de petición** ```bash curl -L 'https://download-api.applivery.io/v1/download/YOUR_DOWNLOAD_TOKEN' \ -o downloaded_file.png ``` :::info El flag `-L` indica a curl que siga la redirección `302` automáticamente. Sin él, recibirás la respuesta de redirección con la cabecera `Location` que contiene la URL real del archivo, pero el archivo no se descargará. ::: **Respuestas** **✓ 302 Found** Redirección a la URL del archivo. La respuesta no tiene cuerpo. La URL de descarga real está en la cabecera de respuesta `Location`. Sigue la redirección para descargar el archivo. **✗ 401 Unauthorized** Token caducado. Los tokens de descarga son de corta duración. Si ha caducado, genera uno nuevo desde el paso 1. ```json { "status": false, "error": { "code": 4005, "message": "Token Expired" } } ``` **✗ 404 Not Found** ```json { "status": false, "error": { "code": 3001, "message": "Entity not found" } } ``` * * * ### Ejemplo completo: descargar un archivo adjunto ```bash ## Paso 1: Genera el token de descarga para el archivo adjunto TOKEN=$(curl -s \ 'https://api.applivery.io/v1/organizations/ORG_ID/apps/APP_ID/builds/BUILD_ID/downloadToken?fileId=FILE_ID&type=auto' \ -H 'Authorization: Bearer YOUR_SERVICE_ACCOUNT_TOKEN' \ | jq -r '.data.token') ## Paso 2: Descarga el archivo siguiendo la redirección curl -L \ "https://download-api.applivery.io/v1/download/$TOKEN" \ -o downloaded_file ``` --- ## Token y URL de Descarga Source: https://docs.applivery.com/es/app-distribution/api/builds/download-token-url-build/ Description: Descarga Builds de Applivery de forma programática mediante la API. Genera tokens de descarga y resuelve URLs de descarga para archivos .apk, .ipa y .aab. TL;DR: Descarga builds de Applivery de forma programática generando un token de descarga de corta duración con una Cuenta de servicio o un App API Token. Answers: ¿Cómo descargo una Build de Applivery de forma programática? · ¿Qué tipo de token se necesita para generar un token de descarga? · ¿Cuál es el endpoint para generar un token de descarga? · ¿Qué parámetros se necesitan para generar un token de descarga? · ¿Qué hace el parámetro type al generar un token de descarga? · ¿Cuál es el endpoint para resolver la URL de descarga? · ¿Qué método HTTP se usa para resolver la URL de descarga? · ¿Qué ocurre si el token de descarga ha caducado? Descargar una Build de forma programática requiere un **proceso de dos pasos**: primero generar un token de descarga de corta duración y luego usar ese token para resolver la URL de descarga real. La URL de descarga se sirve mediante una respuesta de redirección. :::warning A diferencia de otros endpoints de builds, el endpoint de token de descarga **solo está disponible a través de la Workspace API** y requiere un **token de una cuenta de servicio** o un token de sesión de usuario obtenido al iniciar sesión. La Integrations API (App API Token) no admite este endpoint. ::: Para crear un token de una cuenta de servicio, consulta [Cuentas de servicio](https://docs.applivery.com/es/platform/api/service-accounts/). * * * ### Resumen: flujo de descarga ``` Paso 1: Genera un token de descarga GET /v1/organizations/{organizationId}/apps/{applicationId}/builds/{buildId}/downloadToken → devuelve { token, expiresAt } Paso 2: Resuelve la URL de descarga GET https://download-api.applivery.io/v1/download/{token} → redirección HTTP 302 a la URL real del archivo ``` * * * **Genera un token de descarga** Genera un token de corta duración y uso único que autoriza la descarga de un archivo de Build concreto. **Endpoint** ``` GET https://api.applivery.io/v1/organizations/{organizationId}/apps/{applicationId}/builds/{buildId}/downloadToken ``` **Autenticación** ``` Authorization: Bearer ``` **Parámetros de ruta** | Parámetro | Tipo | Obligatorio | Descripción | | --- | --- | --- | --- | | `organizationId` | String | Sí | El identificador único (o slug) de tu organización en Applivery. | | `applicationId` | String | Sí | El identificador único de la App a la que pertenece la Build. | | `buildId` | String | Sí | El identificador único de la Build que quieres descargar. Devuelto por POST – Subir una Build y GET – Lista de Builds. | **Parámetros de consulta** | Parámetro | Tipo | Obligatorio | Descripción | | --- | --- | --- | --- | | `type` | String | Sí | Especifica el formato de archivo para el que generar el token de descarga. Consulta los valores a continuación. | **Valores de `type`** | Valor | Descripción | | --- | --- | | `auto` | Comportamiento por defecto. Devuelve un `.apk` para Builds Android, o el manifest (`.plist`) para Builds Apple. Esta es la opción estándar para flujos de instalación OTA. | | `file` | Devuelve el archivo binario original. Para Builds Apple, es el archivo `.ipa` o `.pkg` en lugar del manifest. Úsalo cuando necesites el archivo real en vez de un enlace de instalación OTA. | | `aab` | Para Builds Android subidos originalmente como `.aab`, devuelve el archivo `.aab` original en lugar del `.apk` universal que genera Applivery. | **Ejemplo de petición** ```bash curl 'https://api.applivery.io/v1/organizations/MY_ORG_SLUG/apps/MY_APP_ID/builds/MY_BUILD_ID/downloadToken?type=file' \ -X GET \ -H 'Accept: application/json' \ -H 'Authorization: Bearer YOUR_SERVICE_ACCOUNT_TOKEN' ``` **Respuestas** **✓ 200 OK** ```json { "status": true, "data": { "token": "string", "expiresAt": "string" } } ``` **✗ 400 Bad Request** Build aún no procesada. La Build existe pero aún no ha terminado de procesarse. Solo las Builds con `status: processed` pueden generar tokens de descarga. ```json { "status": false, "error": { "code": 5014, "message": "Build Not Processed" } } ``` **✗ 401 Unauthorized** ```json { "status": false, "error": { "code": 4002, "message": "No auth token" } } ``` **✗ 404 Not Found** ```json { "status": false, "error": { "code": 3001, "message": "Entity not found" } } ``` | Campo | Descripción | | --- | --- | | `token` | La cadena del token de descarga. Pásalo como parámetro de ruta en el paso 2 para resolver la URL de descarga. | | `expiresAt` | Timestamp ISO 8601 que indica cuándo caduca el token. Los tokens son de corta duración — úsalos pronto tras generarlos. | **Resuelve la URL de descarga** Usa el token obtenido en el paso 1 para obtener la URL de descarga real del archivo. La API responde con una redirección HTTP `302 Found` al almacenamiento del archivo. :::warning **No se requiere autenticación**. Este endpoint es público — el propio token actúa como credencial. Cualquier persona con el token puede descargar el archivo, así que trátalo como información sensible y no lo compartas más allá del destinatario previsto. ::: **Endpoint** ``` GET https://download-api.applivery.io/v1/download/{token} ``` **Parámetros de ruta** | Parámetro | Tipo | Obligatorio | Descripción | | --- | --- | --- | --- | | `token` | String | Sí | El token de descarga devuelto en el paso 1. | **Ejemplo de petición** ```bash curl -L 'https://download-api.applivery.io/v1/download/YOUR_DOWNLOAD_TOKEN' \ -o downloaded_build.ipa ``` :::info El flag `-L` indica a curl que siga la redirección `302` automáticamente. Sin él, recibirás la respuesta de redirección con la cabecera `Location` que contiene la URL real del archivo, pero el archivo no se descargará. ::: **Comportamiento de redirección por plataforma** La URL en la cabecera de redirección `Location` varía según la plataforma y el valor del parámetro `type` usado en el paso 1: | Plataforma | Valor de `type` | Destino de la redirección | | --- | --- | --- | | **Android** | `auto` | Archivo `.apk` universal | | **Android** | `aab` | Archivo `.aab` original | | **Apple** | `auto` | Manifest OTA (`.plist`) — para instalación OTA mediante MDM o enlace directo | | **Apple** | `file` | Binario original — `.ipa` para iOS, `.pkg` para macOS | **Respuestas** **✓ 302 Found** Redirección a la URL del archivo. La respuesta no tiene cuerpo. La URL de descarga real está en la cabecera de respuesta `Location`. Sigue la redirección para descargar el archivo. **✗ 401 Unauthorized** Token caducado. Los tokens de descarga son de corta duración. Si ha caducado, genera uno nuevo desde el paso 1. ```json { "status": false, "error": { "code": 4005, "message": "Token Expired" } } ``` **✗ 404 Not Found** ```json { "status": false, "error": { "code": 3001, "message": "Entity not found" } } ``` * * * ### Ejemplo completo: descargar un archivo de Build ```bash ## Paso 1: Genera el token de descarga TOKEN=$(curl -s \ 'https://api.applivery.io/v1/organizations/MY_ORG/apps/MY_APP/builds/MY_BUILD/downloadToken?type=file' \ -H 'Authorization: Bearer YOUR_SERVICE_ACCOUNT_TOKEN' \ | jq -r '.data.token') ## Paso 2: Descarga el archivo siguiendo la redirección curl -L \ "https://download-api.applivery.io/v1/download/$TOKEN" \ -o my_build.ipa ``` --- ## Listar Builds Source: https://docs.applivery.com/es/app-distribution/api/builds/list-builds/ Description: Lista las Builds de una App usando la API de Applivery. Cubre tanto la Integrations API como la Workspace API para consultar el historial y el estado de las Builds. TL;DR: Lista las builds de tus apps usando la API de Integraciones o la API de Workspace de Applivery con la autenticación correspondiente. Answers: ¿Cuáles son las dos APIs de Applivery para listar builds? · ¿Cuándo debo usar la Integrations API para listar builds? · ¿Cuándo debo usar la Workspace API para listar builds? · ¿Cómo me autentico con la Integrations API? · ¿Cómo me autentico con la Workspace API? · ¿Qué parámetros puedo usar para filtrar builds en la Integrations API? · ¿Qué parámetros de ruta requiere la Workspace API? · ¿Cómo puedo comprobar el estado de procesamiento de una build? Devuelve una lista paginada de Builds para una App determinada. Resulta útil para consultar el historial de builds, comprobar el estado de procesamiento tras una subida, o crear dashboards y scripts de automatización que actúen sobre Builds específicos. Applivery proporciona dos APIs independientes para listar Builds, cada una con una credencial de autenticación diferente. --- ### Cómo elegir la API correcta | | Integrations API | Workspace API | |---|---|---| | **Diseñada para** | Integraciones por app, pipelines de CI/CD, herramientas de build | Automatización a nivel de Workspace en varias Apps | | **Autenticación** | App API Token (por app) | un token de una cuenta de servicio (a nivel de Workspace) | | **URL base** | `https://api.applivery.io` | `https://api.applivery.io` | | **Contexto de app** | Implícito — el token ya está vinculado a una App | Explícito — se requieren `organizationId` y `applicationId` en la ruta | | **Usuarios típicos** | Scripts que comprueban el estado de la Build, polling tras subida | Platform engineers que consultan Builds en varias Apps | :::warning El acceso a las distintas APIs puede no estar disponible en tu plan actual. Consulta la disponibilidad en nuestra [página de precios](https://www.applivery.com/app-distribution-pricing/). ::: --- ### Integrations API Usa este endpoint para consultar Builds dentro del ámbito de una sola app. La autenticación usa un **App API Token**, vinculado a la App específica. Para crear un App API Token, consulta [Autenticación de la API de Apps](https://docs.applivery.com/es/app-distribution/api/app-api-token/). #### Endpoint ``` GET https://api.applivery.io/v1/integrations/builds ``` #### Autenticación ``` Authorization: Bearer ``` #### Parámetros de consulta Todos los parámetros son opcionales. Sin filtros, el endpoint devuelve todos las Builds de la App asociada al token, ordenados por fecha de creación descendente. | Parámetro | Tipo | Descripción | |---|---|---| | `versionName` | String | Filtra por nombre de versión legible. P. ej., `RC-1`, `v2.4.0-beta`. | | `status` | String | Filtra por estado de procesamiento. Valores admitidos: `pending`, `in_progress`, `processed`, `error`. | | `os` | String | Filtra por sistema operativo. Valores admitidos: `ios`, `android`. | | `page` | Integer | Número de página para la paginación. Empieza en `1`. | | `limit` | Integer | Número máximo de Builds a devolver por página. | #### Ejemplo de petición ```bash curl 'https://api.applivery.io/v1/integrations/builds?status=processed&os=ios&page=1&limit=20' \ -X GET \ -H 'Authorization: Bearer YOUR_APP_TOKEN' ``` #### Respuestas **✓ 200 OK** ```json { "status": true, "data": { "items": [ { "id": "string", "status": "processed", "tags": ["string"], "versionName": "string", "application": "string", "applicationInfo": { "id": "string", "name": "string", "slug": "string", "picture": "string" }, "changelog": "string", "info": { "icon": "string", "android": { "targetSdkVersion": "string", "minSDKVersion": "string", "packageName": "string", "platformBuildVersionName": "string", "platformBuildVersionCode": "string", "versionName": "string", "versionCode": "string", "icon": "string" }, "ios": { "plist": { "CFBundleDisplayName": "string", "CFBundleSupportedPlatforms": ["string"], "MinimumOSVersion": "string", "CFBundleIdentifier": "string", "CFBundleShortVersionString": "string", "CFBundleVersion": "string", "CFBundleName": "string", "CFBundleIcons": ["string"], "UIDeviceFamily": ["string"] }, "mobileprovision": { "ExpirationDate": "2019-08-24T14:15:22Z", "TeamIdentifier": "string", "ProvisionsAllDevices": true, "TeamName": "string", "ProvisionedDevices": "string", "signingType": "ad-hoc" } }, "pkg": { "CFBundleDisplayName": "string", "CFBundleIdentifier": "string", "CFBundleShortVersionString": "string", "CFBundleVersion": "string", "CFBundleName": "string" } }, "size": 0, "processTime": 0, "queuedTime": 0, "versionCode": "string", "error": "string", "errorCode": "string", "os": "ios", "deployer": { "name": "string", "info": { "commitMessage": "string", "commit": "string", "branch": "string", "triggerTimestamp": "string", "buildUrl": "string", "ciUrl": "string", "repositoryUrl": "string", "buildNumber": "string", "tag": "string" } }, "uploadedBy": { "id": "string", "email": "user@example.com", "firstName": "string", "lastName": "string", "picture": "string" }, "originalExtension": "string", "storageProvider": { "id": "string", "name": "string", "region": "string" }, "hasEmmJson": true, "updatedAt": "2019-08-24T14:15:22Z", "createdAt": "2019-08-24T14:15:22Z" } ] } } ``` **✗ 401 Unauthorized** ```json { "status": false, "error": { "code": 4002, "message": "No auth token" } } ``` **✗ 404 Not Found** ```json { "status": false, "error": { "code": 3001, "message": "Entity not found" } } ``` :::tip Usa `status=pending` o `status=in_progress` para hacer polling de Builds que aún se están procesando tras una subida. Una vez que el `status` devuelva `processed`, la Build está lista. Si el `status` es `error`, consulta los campos `error` y `errorCode` para más detalles, y revisa los [Códigos de procesamiento de Builds](https://docs.applivery.com/es/app-distribution/builds/processing-error-codes/) para los pasos de resolución. ::: --- ### Workspace API Usa este endpoint para consultar Builds a nivel de Workspace — por ejemplo, en flujos de trabajo de platform engineering donde una sola credencial necesita listar Builds en varias Apps. La autenticación usa un token de **cuenta de servicio**, con ámbito de Workspace y no vinculado a ninguna app individual. El contexto de la app se proporciona explícitamente mediante parámetros de ruta. Para crear un token de una cuenta de servicio, consulta [Cuentas de servicio](https://docs.applivery.com/es/platform/api/service-accounts/). #### Endpoint ``` GET https://api.applivery.io/v1/organizations/{organizationId}/apps/{applicationId}/builds ``` #### Parámetros de ruta | Parámetro | Tipo | Obligatorio | Descripción | |---|---|---|---| | `organizationId` | String | Sí | El identificador único de tu organización en Applivery. | | `applicationId` | String | Sí | El identificador único de la App cuyos Builds quieres listar. | #### Autenticación ``` Authorization: Bearer ``` #### Parámetros de consulta La Workspace API acepta los mismos parámetros de consulta que la Integrations API. #### Ejemplo de petición ```bash curl 'https://api.applivery.io/v1/organizations/ORG_ID/apps/APP_ID/builds?status=processed&os=android&page=1&limit=10' \ -X GET \ -H 'Authorization: Bearer YOUR_SERVICE_ACCOUNT_TOKEN' ``` --- ## Actualizar Build Source: https://docs.applivery.com/es/app-distribution/api/builds/update-build/ Description: Actualiza los metadatos editables de una Build en Applivery con la Integrations API o Workspace API — nombre de versión, etiquetas y changelog. TL;DR: Actualiza los metadatos de una Build en Applivery con la Integrations API (App API Token) o la Workspace API (token de cuenta de servicio). Solo se actualizan los campos que incluyes — el resto conserva su valor actual. Answers: ¿Qué campos puedo actualizar en una Build existente? · ¿Tengo que incluir todos los campos al actualizar una Build? · ¿Cuál es la diferencia entre la Integrations API y la Workspace API para actualizar builds? · ¿Cómo obtengo el buildId para actualizar una Build? · ¿Puedo actualizar una Build que aún se está procesando? · ¿Para qué sirve el campo disabled en una Build? · ¿Para qué sirve el campo metadata en una Build? · ¿Qué método HTTP se usa para actualizar una Build? Actualiza los metadatos editables de una Build existente — nombre de versión, etiquetas, changelog y, en el caso de la Workspace API, campos adicionales como metadatos personalizados, scripts por defecto y estado de deshabilitación. El binario de la Build y la información de procesamiento no se ven afectados. Incluye solo los campos que quieras cambiar. Los campos no incluidos en el cuerpo de la petición conservan su valor actual. Applivery proporciona dos APIs independientes para actualizar Builds, cada una con una credencial de autenticación diferente. --- ### Cómo elegir la API correcta | | Integrations API | Workspace API | |---|---|---| | **Diseñada para** | Integraciones por app y pipelines de CI/CD | Automatización a nivel de Workspace en varias Apps | | **Autenticación** | App API Token (por app) | Token de cuenta de servicio (a nivel de Workspace) | | **Contexto de app** | Implícito — el token ya está vinculado a una App | Explícito — se requieren `organizationId` y `applicationId` en la ruta | | **Campos disponibles** | `versionName`, `tags`, `changelog` | Todo lo anterior más `metadata`, `defaultScripts`, `disabled` | | **Usuarios típicos** | Scripts de CI que actualizan etiquetas y notas tras la subida | Platform engineers que gestionan metadatos de builds en varias Apps | :::warning El acceso a las distintas APIs puede no estar disponible en tu plan actual. Consulta la disponibilidad en nuestra [página de precios](https://www.applivery.com/app-distribution-pricing/). ::: --- ### Integrations API Usa este endpoint para actualizar metadatos de una Build dentro del ámbito de una sola app. La autenticación usa un **App API Token**, vinculado a la App específica. Para crear un App API Token, consulta [App API Token](https://docs.applivery.com/es/app-distribution/api/app-api-token/). #### Endpoint ``` PUT https://api.applivery.io/v1/integrations/builds/{buildId} ``` #### Autenticación ``` Authorization: Bearer ``` #### Formato de la petición `application/json` #### Parámetros de ruta | Parámetro | Tipo | Obligatorio | Descripción | |---|---|---|---| | `buildId` | String | Sí | El identificador único de la Build a actualizar. P. ej. `552ae3cfcb5abfc58d733b81`. Se devuelve en la respuesta de [POST – Cargar una Build](https://docs.applivery.com/es/app-distribution/api/builds/upload-build/) y [GET – Lista de Builds](https://docs.applivery.com/es/app-distribution/api/builds/list-builds/). | #### Parámetros | Parámetro | Tipo | Descripción | |---|---|---| | `versionName` | String | Etiqueta de versión legible para esta Build. P. ej. `RC-2`, `v2.5.0-beta`. | | `tags` | Array | Lista de etiquetas para categorizar la Build. Reemplaza el array de etiquetas existente. P. ej. `["staging", "sprint-43"]`. | | `changelog` | String | Notas de la versión o descripción de los cambios de esta Build. | #### Ejemplo de petición ```bash curl 'https://api.applivery.io/v1/integrations/builds/552ae3cfcb5abfc58d733b81' \ -X PUT \ -H 'Authorization: Bearer YOUR_APP_TOKEN' \ -H 'Content-Type: application/json' \ -d '{ "versionName": "v2.5.0-rc2", "tags": ["staging", "sprint-43"], "changelog": "Corregido el crash en la pantalla de ajustes" }' ``` #### Respuestas **✓ 200 OK** ```json { "status": true, "data": { "id": "string", "status": "success", "tags": ["string"], "versionName": "string", "application": "string", "applicationInfo": { "id": "string", "name": "string", "slug": "string", "picture": "string" }, "changelog": "string", "os": "ios", "versionCode": "string", "deployer": { "name": "string", "info": { "commitMessage": "string", "commit": "string", "branch": "string", "tag": "string" } }, "uploadedBy": { "id": "string", "email": "user@example.com", "firstName": "string", "lastName": "string" }, "updatedAt": "2019-08-24T14:15:22Z", "createdAt": "2019-08-24T14:15:22Z" } } ``` **✗ 401 Unauthorized** ```json { "status": false, "error": { "code": 3002, "message": "Token Expired" } } ``` **✗ 404 Not Found** ```json { "status": false, "error": { "code": 3001, "message": "Entity not found" } } ``` --- ### Workspace API Usa este endpoint para actualizar Builds a nivel de Workspace — por ejemplo, en flujos de ingeniería de plataforma donde una sola credencial gestiona metadatos en varias Apps. La autenticación usa un token de **cuenta de servicio**, con ámbito de Workspace y no vinculado a ninguna app individual. Para crear una cuenta de servicio, consulta [Cuentas de servicio](https://docs.applivery.com/es/platform/api/service-accounts/). :::info Este endpoint requiere el permiso `mad.build.management.update` en la cuenta de servicio. ::: #### Endpoint ``` PUT https://api.applivery.io/v1/organizations/{organizationId}/apps/{applicationId}/builds/{buildId} ``` #### Parámetros de ruta | Parámetro | Tipo | Obligatorio | Descripción | |---|---|---|---| | `organizationId` | String | Sí | El identificador único de tu organización en Applivery. | | `applicationId` | String | Sí | El identificador único de la App a la que pertenece la Build. | | `buildId` | String | Sí | El identificador único de la Build a actualizar. | #### Autenticación ``` Authorization: Bearer ``` #### Formato de la petición `application/json` #### Parámetros Además de `versionName`, `tags` y `changelog` disponibles en la Integrations API, la Workspace API expone los siguientes campos: | Parámetro | Tipo | Descripción | |---|---|---| | `metadata` | Object | Objeto de clave-valor personalizado para almacenar información adicional sobre la Build. | | `defaultScripts.preInstall` | String | Script que se ejecuta antes de instalar la Build en un dispositivo. | | `defaultScripts.postInstall` | String | Script que se ejecuta después de instalar la Build en un dispositivo. | | `defaultScripts.audit` | String | Script de auditoría asociado a esta Build. | | `defaultScripts.enforce` | String | Script de imposición de políticas asociado a esta Build. | | `defaultScripts.runner` | String | Configuración del ejecutor de scripts para esta Build. | | `disabled` | Boolean | Si la Build está deshabilitada. Las Builds deshabilitadas no pueden descargarse. | #### Ejemplo de petición ```bash curl 'https://api.applivery.io/v1/organizations/ORG_ID/apps/APP_ID/builds/552ae3cfcb5abfc58d733b81' \ -X PUT \ -H 'Authorization: Bearer YOUR_SERVICE_ACCOUNT_TOKEN' \ -H 'Content-Type: application/json' \ -d '{ "versionName": "v2.5.0-rc2", "changelog": "Corregido el crash en la pantalla de ajustes", "tags": ["staging", "sprint-43"], "metadata": { "environment": "staging", "team": "mobile" } }' ``` El esquema de la respuesta es idéntico al de la Integrations API. Una actualización correcta devuelve `{ "status": true, "data": { ... } }` con el objeto Build actualizado. --- ## Subir Build Source: https://docs.applivery.com/es/app-distribution/api/builds/upload-build/ Description: Applivery ofrece dos APIs para cargar Builds: la Integrations API para CI/CD y la Workspace API para gestión multi-app. Elige la que mejor se adapte a tu caso. TL;DR: Applivery ofrece dos APIs para subir builds: la API de Integraciones para CI/CD usando un App API Token, y la API de Workspace para escenarios multi-app usando una Cuenta de servicio. Answers: ¿Cuáles son las dos APIs de Applivery para cargar builds? · ¿Qué autenticación requiere la Integrations API de Applivery? · ¿Cuál es la URL base de la Integrations API de Applivery? · ¿Qué tipo de contenido debo usar para las peticiones a la Integrations API? · ¿Qué formatos de archivo admite la Integrations API para cargar builds? · ¿El parámetro buildPlatform es obligatorio en la Integrations API? · ¿Cómo puedo enviar notificaciones a los colaboradores al cargar una build? · ¿Qué información del deployer de CI/CD puedo incluir en la Integrations API? Applivery proporciona **dos APIs independientes** para cargar Builds, cada una diseñada para un caso de uso diferente y que requiere una credencial de autenticación distinta. Es importante entender cuál aplica a tu flujo de trabajo antes de integrarte. * * * ### Cómo elegir la API correcta | | Integrations API | Workspace API | | --- | --- | --- | | **Diseñada para** | Pipelines de CI/CD, herramientas de build e integraciones por app | Automatización a nivel de Workspace y gestión multi-app | | **Autenticación** | App API Token (por app) | token de una cuenta de servicio (a nivel de Workspace) | | **URL base** | `https://upload.applivery.io` | `https://upload.applivery.io` | | **Contexto de app** | Implícito — el token ya está vinculado a una App | Explícito — se requieren `organizationId` y `applicationId` en la ruta | | **Usuarios típicos** | Fastlane, Bitrise, Jenkins, Azure DevOps, scripts de CI propios | Platform engineers que gestionan varias Apps de forma programática | :::warning El acceso a las distintas APIs puede no estar disponible en tu plan actual. Consulta la disponibilidad en nuestra [página de precios](https://www.applivery.com/app-distribution-pricing/). ::: * * * ### Integrations API Usa este endpoint para cargar Builds desde un pipeline de CI/CD o cualquier integración que opere dentro del ámbito de una sola app. La autenticación usa un **App API Token**, vinculado a la App específica a la que estás subiendo. Para crear un App API Token, consulta [Autenticación de la API de Apps](https://docs.applivery.com/es/app-distribution/api/app-api-token/). #### Endpoint ``` POST https://upload.applivery.io/v1/integrations/builds ``` #### Autenticación ``` Authorization: Bearer ``` #### Formato de la petición `multipart/form-data` #### Parámetros **Archivo de build** | Parámetro | Tipo | Obligatorio | Descripción | | --- | --- | --- | --- | | `build` | File | Sí | El archivo de Build a cargar. Formatos admitidos: `.ipa`, `.apk`, `.aab`. Consulta las Plataformas de Build personalizadas para formatos adicionales. | | `buildPlatform` | String | Condicional | Obligatorio al cargar una Plataforma de Build personalizada. Valores: `ios`, `android` o un identificador de plataforma personalizado. | | `packageName` | String | Condicional | Obligatorio cuando el archivo de Build no puede procesarse automáticamente (p. ej., plataformas personalizadas). El identificador único de la App. | | `packageVersion` | String | Condicional | Obligatorio cuando el archivo de Build no puede procesarse automáticamente. La cadena de versión de esta Build. | | `packageIcon` | File | Condicional | Obligatorio cuando el archivo de Build no puede procesarse automáticamente. Debe ser `.png` o `.jpeg`. | **Metadatos de la Build** | Parámetro | Tipo | Obligatorio | Descripción | | --- | --- | --- | --- | | `versionName` | String | No | Etiqueta de versión legible para esta Build. P. ej. `RC-1`, `v2.4.0-beta`. | | `tags` | Array | No | Lista de etiquetas separadas por comas para categorizar la Build. P. ej. `staging, sprint-42, hotfix`. | | `changelog` | String | No | Notas de la versión o descripción de los cambios en esta Build. Admite texto plano. | **Notificaciones** | Parámetro | Tipo | Obligatorio | Descripción | | --- | --- | --- | --- | | `notifyCollaborators` | Boolean | No | Si se debe enviar una notificación por email a los Colaboradores de la app y del Workspace. Por defecto: `false`. | | `notifyEmployees` | Boolean | No | Si se debe enviar una notificación por email a los empleados de la store. Por defecto: `false`. | | `notifyMessage` | String | No | Mensaje personalizado para incluir en el email de notificación. P. ej. `¡Nuevo Build listo para pruebas!`. | | `notifyLanguage` | String | No | Idioma del email de notificación. Valores admitidos: `en`, `es`, `fr`, `de`, `it`, `zh`, `pt`, `ru`. | | `filter` | Array anidado | No | Limita las notificaciones a grupos de empleados específicos. Admite lógica AND/OR. Cada array interno es una cláusula AND; cada elemento externo es una cláusula OR. | **Información del deployer de CI/CD** Estos campos opcionales rellenan los metadatos de despliegue de la Build en el panel de Applivery, facilitando rastrear una Build hasta su origen en CI/CD. | Parámetro | Tipo | Descripción | | --- | --- | --- | | `deployer.name` | String | Nombre visible del sistema CI/CD. P. ej. `Jenkins CI`, `Bitrise`, `GitHub Actions`. | | `deployer.info.commitMessage` | String | Mensaje del commit de Git asociado a esta Build. | | `deployer.info.commit` | String | SHA del commit de Git. P. ej. `f52ace0`. | | `deployer.info.branch` | String | Nombre de la rama de Git. P. ej. `develop`, `release/2.4`. | | `deployer.info.tag` | String | Etiqueta de Git asociada a esta Build. P. ej. `RC-1`, `v2.4.0`. | | `deployer.info.triggerTimestamp` | String | Timestamp Unix (ms) de cuando se disparó la Build de CI. P. ej. `1558359012580`. | | `deployer.info.buildUrl` | String | URL directa a la ejecución de la Build de CI. | | `deployer.info.ciUrl` | String | URL base de la plataforma de CI. | | `deployer.info.repositoryUrl` | String | URL del repositorio de control de versiones. | | `deployer.info.buildNumber` | String | Número de build de la plataforma de CI. P. ej. `173`. | #### Ejemplo de petición ```bash curl 'https://upload.applivery.io/v1/integrations/builds' \ -X POST \ --retry 5 \ --fail \ -H 'Authorization: Bearer YOUR_APP_TOKEN' \ -F 'build=@file.ipa' \ -F 'versionName=v2.4.0-rc1' \ -F 'tags=staging, sprint-42' \ -F 'changelog=Fixed crash on login screen' \ -F 'notifyCollaborators=true' \ -F 'notifyEmployees=false' \ -F 'notifyMessage=New build ready for QA' \ -F 'notifyLanguage=en' \ -F 'filter[0][0]=group1' \ -F 'filter[0][1]=group2' \ -F 'filter[1][0]=group3' \ -F 'deployer.name=GitHub Actions' \ -F 'deployer.info.commitMessage=Fix crash on login' \ -F 'deployer.info.commit=f52ace0' \ -F 'deployer.info.branch=release/2.4' \ -F 'deployer.info.tag=v2.4.0-rc1' \ -F 'deployer.info.triggerTimestamp=1558359012580' \ -F 'deployer.info.buildUrl=https://github.com/myorg/myapp/actions/runs/123' \ -F 'deployer.info.ciUrl=https://github.com/myorg/myapp/actions' \ -F 'deployer.info.repositoryUrl=https://github.com/myorg/myapp' \ -F 'deployer.info.buildNumber=173' ``` #### Respuestas **✓ 200 OK** ```json { "status": true, "data": { "id": "string", "status": "pending", "tags": ["string"], "versionName": "string", "application": "string", "applicationInfo": { "id": "string", "name": "string", "slug": "string", "picture": "string" }, "changelog": "string", "info": { "icon": "string", "android": { "targetSdkVersion": "string", "minSDKVersion": "string", "packageName": "string", "platformBuildVersionName": "string", "platformBuildVersionCode": "string", "versionName": "string", "versionCode": "string", "icon": "string" }, "ios": { "plist": { "CFBundleDisplayName": "string", "CFBundleSupportedPlatforms": ["string"], "MinimumOSVersion": "string", "CFBundleIdentifier": "string", "CFBundleShortVersionString": "string", "CFBundleVersion": "string", "CFBundleName": "string", "CFBundleIcons": ["string"], "UIDeviceFamily": ["string"] }, "mobileprovision": { "ExpirationDate": "2019-08-24T14:15:22Z", "TeamIdentifier": "string", "ProvisionsAllDevices": true, "TeamName": "string", "ProvisionedDevices": "string", "signingType": "ad-hoc" } }, "pkg": { "CFBundleDisplayName": "string", "CFBundleIdentifier": "string", "CFBundleShortVersionString": "string", "CFBundleVersion": "string", "CFBundleName": "string" } }, "size": 0, "processTime": 0, "queuedTime": 0, "versionCode": "string", "os": "ios", "deployer": { "name": "string", "info": { "commitMessage": "string", "commit": "string", "branch": "string", "triggerTimestamp": "string", "buildUrl": "string", "ciUrl": "string", "repositoryUrl": "string", "buildNumber": "string", "tag": "string" } }, "uploadedBy": { "id": "string", "email": "user@example.com", "firstName": "string", "lastName": "string", "picture": "string" }, "originalExtension": "string", "storageProvider": { "id": "string", "name": "string", "region": "string" }, "updatedAt": "2019-08-24T14:15:22Z", "createdAt": "2019-08-24T14:15:22Z" } } ``` **✗ 400 Bad Request** ```json { "status": false, "error": { "code": 5024, "message": "Slug already used" } } ``` **✗ 401 Unauthorized** ```json { "status": false, "error": { "code": 3002, "message": "Token Expired" } } ``` **✗ 404 Not Found** ```json { "status": false, "error": { "code": 3001, "message": "Entity not found" } } ``` :::info El `status` de la Build en la respuesta será inicialmente `pending`. Applivery procesa la Build de forma asíncrona — el estado se actualizará a `success` o `error` una vez finalizado el procesamiento. Usa el endpoint [GET – Detalles de la Build](https://docs.applivery.com/es/app-distribution/api/builds/build-details/) para hacer polling del estado final si es necesario. ::: Para la lista completa de códigos de error durante el procesamiento de builds, consulta [Códigos de procesamiento de Builds](https://docs.applivery.com/es/app-distribution/builds/processing-error-codes/). * * * ### Workspace API Usa este endpoint para cargar Builds a nivel de Workspace — por ejemplo, en flujos de trabajo de platform engineering donde una sola credencial gestiona varias Apps en una organización. La autenticación usa un token de **cuenta de servicio**, con ámbito de Workspace y no vinculado a ninguna app individual. El contexto de la app se proporciona explícitamente mediante parámetros de ruta. Para crear un token de una cuenta de servicio, consulta [Cuentas de servicio](https://docs.applivery.com/es/platform/api/service-accounts/). #### Endpoint ``` POST https://upload.applivery.io/v1/organizations/{organizationId}/apps/{applicationId}/builds ``` #### Parámetros de ruta | Parámetro | Tipo | Obligatorio | Descripción | | --- | --- | --- | --- | | `organizationId` | String | Sí | El identificador único de tu organización en Applivery. | | `applicationId` | String | Sí | El identificador único de la App a la que cargar la Build. | #### Autenticación ``` Authorization: Bearer ``` #### Formato de la petición `multipart/form-data` #### Parámetros La Workspace API acepta los mismos parámetros de archivo de build, metadatos, notificaciones y deployer que la Integrations API. #### Ejemplo de petición ```bash curl 'https://upload.applivery.io/v1/organizations/ORG_ID/apps/APP_ID/builds' \ -X POST \ -H 'Authorization: Bearer YOUR_SERVICE_ACCOUNT_TOKEN' \ -F 'build=@file.apk' \ -F 'versionName=v3.1.0' \ -F 'changelog=Performance improvements' \ -F 'notifyCollaborators=true' \ -F 'deployer.name=Internal Deploy Bot' \ -F 'deployer.info.branch=main' \ -F 'deployer.info.buildNumber=88' ``` --- ## Publicaciones Source: https://docs.applivery.com/es/app-distribution/api/publications/ Description: API de Publicaciones de Applivery: lista, crea, actualiza y elimina Publicaciones, y consulta su configuración y detalles de forma programática. Answers: ¿Qué operaciones permite la API de Publicaciones de Applivery? · ¿Cómo automatizo la creación de publicaciones en Applivery? · ¿Puedo actualizar una publicación de forma programática? · ¿Cómo elimino una publicación mediante la API? · ¿Cómo obtengo los detalles de una publicación con la API? La API de Publicaciones permite gestionar las Apps publicadas de forma programática: listar, crear, actualizar y eliminar Publicaciones, así como consultar sus detalles y configuración. Usa estos endpoints para automatizar tu proceso de release e integrar la gestión de Publicaciones en tus flujos de trabajo existentes. --- ## Crear Publicación Source: https://docs.applivery.com/es/app-distribution/api/publications/create-publication/ Description: Crea Publicaciones en la Store Enterprise de Applivery usando la Integrations API o la Workspace API. Controla la distribución y el acceso a la app. TL;DR: Crea y gestiona publicaciones del App Store de Applivery de forma programática usando la API de Integraciones o la API de Workspace. Answers: ¿Qué es una publicación de Applivery? · ¿Cuáles son los parámetros obligatorios para crear una publicación en Applivery? · ¿Qué métodos de autenticación puedo usar para crear una publicación? · ¿Cuándo debo usar la Integrations API para crear una publicación? · ¿Cuáles son los valores permitidos para el parámetro security de una publicación? · ¿Cuáles son los valores permitidos para el parámetro visibility de una publicación? · ¿Para qué sirve el parámetro slug al crear una publicación? · ¿Qué estrategias de selección de Build están disponibles al crear una publicación? Crea una nueva Publicación en la Store Enterprise de Applivery. Una Publicación es la configuración de distribución que controla cómo y a quién se pone a disposición una Build específico (o conjunto de Builds) de una App — incluyendo su slug de URL, modo de seguridad, visibilidad, filtros de acceso y sobreescrituras de branding. Para una visión general conceptual de las Publicaciones y su relación con las Builds, consulta [Cómo distribuir tus apps](https://docs.applivery.com/es/app-distribution/distribute/distribute-apps/). Applivery proporciona dos APIs independientes para crear Publicaciones, cada una con una credencial de autenticación diferente. * * * ### Cómo elegir la API correcta | | Integrations API | Workspace API | |---|---|---| | **Diseñada para** | Pipelines de CI/CD por app | Automatización a nivel de Workspace en varias Apps | | **Autenticación** | App API Token (por app) | token de una cuenta de servicio (a nivel de Workspace) | | **Contexto de app** | Implícito — el token ya está vinculado a una App | Explícito — se requieren `organizationId` y `storeId` en la ruta | | **Usuarios típicos** | Scripts que publican automáticamente tras subir una Build | Platform engineers que gestionan Publicaciones de varias Apps | :::warning El acceso a las distintas APIs puede no estar disponible en tu plan actual. Consulta la disponibilidad en nuestra [página de precios](https://www.applivery.com/app-distribution-pricing/). ::: * * * ### Integrations API Usa este endpoint para crear Publicaciones dentro del ámbito de una sola app. La autenticación usa un **App API Token**, vinculado a la App específica. Para crear un App API Token, consulta [Autenticación de la API de Apps](https://docs.applivery.com/es/app-distribution/api/app-api-token/). #### Endpoint ``` POST https://api.applivery.io/v1/integrations/distributions ``` #### Autenticación ``` Authorization: Bearer ``` #### Formato de la petición `application/json` * * * #### Parámetros Los parámetros están agrupados por área de configuración. ##### Parámetros obligatorios | Parámetro | Tipo | Descripción | |---|---|---| | `slug` | String | El identificador amigable para URL de esta Publicación. Debe ser único en tu Workspace. Se usa para construir la URL de la Publicación: `yourworkspace.applivery.com/{slug}`. Solo se permiten letras minúsculas, números y guiones. | | `security` | String | Modo de autenticación. Valores permitidos: `public`, `password`, `logged`. Consulta los modos de seguridad a continuación. | | `visibility` | String | Visibilidad de la Publicación. Valores permitidos: `active`, `inactive`, `unlisted`. Consulta los modos de visibilidad a continuación. | | `filter.type` | String | Estrategia de selección de Build. Valores permitidos: `last`, `build`, `Builds`, `gitBranch`, `gitTag`, `tag`. Consulta la configuración de filtros a continuación. | ##### Filtro de selección de Build | Parámetro | Tipo | Obligatorio | Descripción | |---|---|---|---| | `filter.type` | String | Sí | Estrategia de selección de Build. Consulta la configuración de filtros. | | `filter.value` | String | Condicional | Obligatorio para los tipos de filtro `gitBranch`, `gitTag` y `tag`. El nombre de rama, git tag o build tag a coincidir. | | `filter.ios` | String | Condicional | ID de la Build para iOS. Obligatorio cuando `filter.type` es `build` y la App tiene Builds de iOS. | | `filter.android` | String | Condicional | ID de la Build para Android. Obligatorio cuando `filter.type` es `build` y la App tiene Builds de Android. | | `filter.macos` | String | Condicional | ID de la Build para macOS. Obligatorio cuando `filter.type` es `build` y la App tiene Builds de macOS. | | `filter.Builds` | Array | Condicional | Obligatorio cuando `filter.type` es `Builds`. Array de objetos con `buildPlatform` e `id`. | | `filter.Builds[].buildPlatform` | String | Condicional | Identificador de plataforma. Valores admitidos: `ios`, `macos`, `android`, `ps4`, `ps5`, `switch`, `xbox-one`, `xbox-series`. | | `filter.Builds[].id` | String | Condicional | ID de la Build para la plataforma especificada. | ##### Control de acceso | Parámetro | Tipo | Obligatorio | Descripción | |---|---|---|---| | `password` | String | Condicional | Obligatorio cuando `security` es `password`. La contraseña que deben introducir los usuarios para acceder a la Publicación. | | `groups` | Array | No | Restringe el acceso a Grupos de usuarios específicos. Soporta lógica AND/OR. Cada array interno es una cláusula AND; cada elemento externo es una cláusula OR. P. ej. para permitir usuarios en group1 Y group2, O usuarios en group3: `[["group1","group2"],["group3"]]`. Solo aplica cuando `security` es `logged`. | | `activateUserAudiences` | Boolean | No | Si se habilita el acceso basado en audiencias para esta Publicación. | | `userAudienceMap` | Array | No | Array de asignaciones de audiencias. Cada elemento define una audiencia y su preferencia de notificación. | | `userAudienceMap[].id` | String | Condicional | ID de la audiencia a asignar a esta Publicación. | | `userAudienceMap[].notifyNewBuildsProcessed` | Boolean | No | Si los usuarios de esta audiencia deben recibir notificaciones cuando se procesa un nuevo Build. | | `allowedCountries` | Array | No | Códigos de país ISO 3166-1 alpha-2 desde los que se **permite** el acceso. Si se configura, solo los usuarios de estos países pueden acceder a la Publicación. No puede combinarse con `blockedCountries`. | | `blockedCountries` | Array | No | Códigos de país ISO 3166-1 alpha-2 desde los que se **bloquea** el acceso. No puede combinarse con `allowedCountries`. | ##### Opciones de visualización de Builds | Parámetro | Tipo | Obligatorio | Descripción | |---|---|---|---| | `tags` | Array | No | Tags para categorizar esta Publicación. P. ej. `["staging", "sprint-42"]`. | | `showHistory` | Boolean | No | Si los usuarios pueden explorar e instalar Builds anteriores de la App. Por defecto: `false`. | | `showDevInfo` | Boolean | No | Si se muestra información técnica de la Build (metadatos de git, detalles del certificado, tags) a los usuarios. Por defecto: `false`. | | `expirationDate` | String | No | Timestamp ISO 8601 a partir del cual la Publicación deja de estar disponible para descarga. Útil para distribuciones con fecha límite, programas beta o campañas promocionales. P. ej. `"2025-12-31T23:59:59Z"`. Una vez caducada, la Publicación se comporta como si estuviera en `inactive`. | ##### Términos legales | Parámetro | Tipo | Obligatorio | Descripción | |---|---|---|---| | `terms.active` | Boolean | No | Si los usuarios deben aceptar los términos legales antes de acceder a la Publicación. | | `terms.text` | String | Condicional | Obligatorio cuando `terms.active` es `true`. El texto de los términos legales a mostrar. | ##### Sobreescrituras de branding y configuración de app | Parámetro | Tipo | Obligatorio | Descripción | |---|---|---|---| | `configuration.application.name` | String | No | Sobreescribe el nombre de la App mostrado en la Publicación. | | `configuration.application.description` | String | No | Sobreescribe la descripción de la App mostrada en la Publicación. | | `configuration.branding.logo` | String | No | Sobreescribe el logo de la store para esta Publicación. | | `configuration.branding.primaryColor` | String | No | Sobreescribe el color de branding primario (formato hex). P. ej. `#FF5733`. | | `configuration.branding.buttonColor` | String | No | Sobreescribe el color del botón (formato hex). | * * * #### Modos de seguridad | Valor | Descripción | |---|---| | `public` | No se requiere autenticación. Cualquier persona con la URL de la Publicación puede acceder y descargar. | | `password` | Se requiere una contraseña (especificada en el campo `password`) para acceder a la Publicación. | | `logged` | Los usuarios deben estar conectados con una cuenta de Applivery o tu SSO de Workspace para acceder a la Publicación. | #### Modos de visibilidad | Valor | Descripción | |---|---| | `active` | La Publicación está listada en la Store Enterprise y accesible para todos los usuarios autorizados. | | `inactive` | La Publicación no es accesible para nadie. | | `unlisted` | La Publicación no está listada en la Store Enterprise, pero es accesible para cualquier persona que tenga la URL directa. | #### Configuración de filtros | `filter.type` | Descripción | |---|---| | `last` | Sirve siempre la Build procesado más recientemente. No se necesita `filter.value` adicional. | | `build` | Sirve una Build específico, identificado por `filter.ios`, `filter.android` o `filter.macos`. | | `Builds` | Sirve Builds específicos por plataforma, definidos en `filter.Builds`. Soporta plataformas personalizadas. | | `gitBranch` | Sirve el último Build que coincide con la rama git especificada en `filter.value`. P. ej. `develop`. | | `gitTag` | Sirve la Build que coincide con el git tag especificado en `filter.value`. P. ej. `v2.4.0`. | | `tag` | Sirve las Builds que coinciden con la Build tag de Applivery especificado en `filter.value`. | * * * #### Ejemplos de petición Publicación mínima — pública, sirviendo siempre el último Build: ```bash curl 'https://api.applivery.io/v1/integrations/distributions' \ -X POST \ -H 'Authorization: Bearer YOUR_APP_TOKEN' \ -H 'Content-Type: application/json' \ -d '{ "slug": "my-app-staging", "security": "public", "visibility": "active", "filter": { "type": "last" } }' ``` Publicación privada con control de acceso por grupos e historial de builds: ```bash curl 'https://api.applivery.io/v1/integrations/distributions' \ -X POST \ -H 'Authorization: Bearer YOUR_APP_TOKEN' \ -H 'Content-Type: application/json' \ -d '{ "slug": "my-app-internal", "security": "logged", "visibility": "active", "filter": { "type": "gitBranch", "value": "develop" }, "groups": [["qa-team", "developers"]], "showHistory": true, "showDevInfo": true, "tags": ["internal", "qa"] }' ``` * * * #### Respuestas **✓ 200 OK** :::info El campo `distributionUrl` de la respuesta contiene la URL pública completa de la Publicación creada. Comparte esta URL con tus usuarios para darles acceso a la Publicación. ::: ```json { "status": true, "data": { "id": "string", "updatedAt": "string", "createdAt": "string", "application": "string", "applicationInfo": { "id": "string", "slug": "string", "name": "string", "picture": "string" }, "slug": "string", "filter": { "type": "last", "value": "string", "ios": "string", "android": "string", "windows": "string", "macos": "string", "builds": [ { "buildPlatform": "string", "id": "string" } ] }, "security": "public", "tags": ["string"], "groups": [["string"]], "visibility": "active", "showHistory": true, "showDevInfo": true, "distributionUrl": "string", "terms": { "active": true, "text": "string" } } } ``` **✗ 400 Bad Request** El slug ya está en uso. ```json { "status": false, "error": { "code": 5024, "message": "Slug already used" } } ``` **✗ 401 Unauthorized** ```json { "status": false, "error": { "code": 4002, "message": "No auth token" } } ``` **✗ 404 Not Found** ```json { "status": false, "error": { "code": 3001, "message": "Entity not found" } } ``` * * * ### Workspace API Usa este endpoint para crear Publicaciones a nivel de Workspace — por ejemplo, en flujos de trabajo de platform engineering que operan en varias Apps usando una sola credencial. La autenticación usa un token de **cuenta de servicio**, con ámbito de Workspace y no vinculado a ninguna app individual. Para crear un token de una cuenta de servicio, consulta [Cuentas de servicio](https://docs.applivery.com/es/platform/api/service-accounts/). #### Endpoint ``` POST https://api.applivery.io/v1/organizations/{organizationId}/stores/{storeId}/pubApps ``` #### Parámetros de ruta | Parámetro | Tipo | Obligatorio | Descripción | |---|---|---|---| | `organizationId` | String | Sí | El identificador único de tu organización en Applivery. | | `storeId` | String | Sí | El identificador único de la store (proyecto de app) en la que crear la Publicación. | #### Autenticación ``` Authorization: Bearer ``` #### Ejemplo de petición ```bash curl 'https://api.applivery.io/v1/organizations/ORG_ID/stores/STORE_ID/pubApps' \ -X POST \ -H 'Authorization: Bearer YOUR_SERVICE_ACCOUNT_TOKEN' \ -H 'Content-Type: application/json' \ -d '{ "slug": "my-app-release", "security": "public", "visibility": "active", "filter": { "type": "last" } }' ``` Los parámetros del cuerpo de la petición y el esquema de respuesta son idénticos a los de la Integrations API. --- ## Eliminar Publicación Source: https://docs.applivery.com/es/app-distribution/api/publications/delete-publication/ Description: Elimina Publicaciones de la Store Enterprise de forma permanente usando la Integrations API o la Workspace API de Applivery. Cubre autenticación y endpoints. TL;DR: Elimina publicaciones del App Store de forma permanente usando la API de Integraciones o la API de Workspace de Applivery. Answers: ¿Qué ocurre al eliminar permanentemente una Publicación de la Store Enterprise? · ¿Es reversible eliminar una publicación en Applivery? · ¿Eliminar una publicación en Applivery elimina también los builds asociados? · ¿Cuáles son las dos APIs de Applivery para eliminar publicaciones? · ¿Cuándo debo usar la Integrations API para eliminar una publicación? · ¿Cuándo debo usar la Workspace API para eliminar una publicación? · ¿Qué ocurre si intento eliminar la última publicación de una app? · ¿Qué autenticación requiere la Integrations API? Elimina una Publicación de la Store Enterprise de forma permanente. Esta acción elimina la configuración de la Publicación y su URL — los usuarios que visiten la URL de la Publicación tras la eliminación ya no podrán acceder ni descargar la App. :::warning Esta operación es **permanente e irreversible**. La URL de la Publicación (`distributionUrl`) dejará de funcionar de inmediato. Si quieres bloquear el acceso temporalmente sin eliminar la Publicación, considera establecer `visibility` en `"inactive"` mediante [PUT – Actualizar una Publicación](https://docs.applivery.com/es/app-distribution/api/publications/update-publication/). ::: :::info Eliminar una Publicación **no** elimina las Builds asociados. Las Builds subyacentes permanecen en Applivery y pueden seguir siendo referenciados por otras Publicaciones. ::: Applivery proporciona dos APIs independientes para eliminar Publicaciones, cada una con una credencial de autenticación diferente. --- ### Cómo elegir la API correcta | | Integrations API | Workspace API | |---|---|---| | **Diseñada para** | Integraciones por app y pipelines de CI/CD | Automatización a nivel de Workspace en varias Apps | | **Autenticación** | App API Token (por app) | token de una cuenta de servicio (a nivel de Workspace) | | **Contexto de app** | Implícito — el token ya está vinculado a una App | Explícito — se requieren `organizationId`, `storeId` y `publishedApplicationId` en la ruta | | **Usuarios típicos** | Scripts que limpian Publicaciones caducadas o superadas | Platform engineers que gestionan el ciclo de vida de Publicaciones en varias Apps | --- ### Integrations API Usa este endpoint para eliminar Publicaciones dentro del ámbito de una sola app. La autenticación usa un **App API Token**, vinculado a la App específica. Para crear un App API Token, consulta [Autenticación de la API de Apps](https://docs.applivery.com/es/app-distribution/api/app-api-token/). #### Endpoint ``` DELETE https://api.applivery.io/v1/integrations/distributions/{publishedApplicationId} ``` #### Autenticación ``` Authorization: Bearer ``` #### Parámetros de ruta | Parámetro | Tipo | Obligatorio | Descripción | |---|---|---|---| | `publishedApplicationId` | String | Sí | El identificador único de la Publicación a eliminar. P. ej. `552ae3cfcb5abfc58d733b81`. Devuelto por [POST – Crear una Publicación](https://docs.applivery.com/es/app-distribution/api/publications/create-publication/) y [GET – Lista de Publicaciones](https://docs.applivery.com/es/app-distribution/api/publications/list-publications/). | #### Ejemplo de petición ```bash curl 'https://api.applivery.io/v1/integrations/distributions/552ae3cfcb5abfc58d733b81' \ -X DELETE \ -H 'Authorization: Bearer YOUR_APP_TOKEN' ``` #### Respuestas **✓ 200 OK** ```json { "status": true, "data": { "delete": "OK" } } ``` **✗ 400 Bad Request** Cada App debe tener al menos una Publicación. Si intentas eliminar la única Publicación restante de una App, la petición será rechazada con este error. Crea una Publicación de sustitución antes de eliminar la última, o establece su `visibility` en `"inactive"`. ```json { "status": false, "error": { "code": 5044, "message": "Can Not Delete Last PubApplication" } } ``` **✗ 401 Unauthorized** ```json { "status": false, "error": { "code": 4002, "message": "No auth token" } } ``` **✗ 404 Not Found** ```json { "status": false, "error": { "code": 3001, "message": "Entity not found" } } ``` --- ### Workspace API Usa este endpoint para eliminar Publicaciones a nivel de Workspace — por ejemplo, en pipelines de automatización que gestionan el ciclo de vida de Publicaciones en varias Apps usando una sola credencial. La autenticación usa un token de **cuenta de servicio**, con ámbito de Workspace y no vinculado a ninguna app individual. Para crear un token de una cuenta de servicio, consulta [Cuentas de servicio](https://docs.applivery.com/es/platform/api/service-accounts/). #### Endpoint ``` DELETE https://api.applivery.io/v1/organizations/{organizationId}/stores/{storeId}/pubApps/{publishedApplicationId} ``` #### Parámetros de ruta | Parámetro | Tipo | Obligatorio | Descripción | |---|---|---|---| | `organizationId` | String | Sí | El identificador único de tu organización en Applivery. | | `storeId` | String | Sí | El identificador único de la store (proyecto de app) a la que pertenece la Publicación. | | `publishedApplicationId` | String | Sí | El identificador único de la Publicación a eliminar. | #### Autenticación ``` Authorization: Bearer ``` #### Ejemplo de petición ```bash curl 'https://api.applivery.io/v1/organizations/ORG_ID/stores/STORE_ID/pubApps/552ae3cfcb5abfc58d733b81' \ -X DELETE \ -H 'Authorization: Bearer YOUR_SERVICE_ACCOUNT_TOKEN' ``` Una eliminación correcta devuelve `{ "status": true, "data": { "delete": "OK" } }`. La misma restricción del código `5044` aplica — tampoco se puede eliminar la última publicación de una App mediante la Workspace API. --- ## Listar Publicaciones Source: https://docs.applivery.com/es/app-distribution/api/publications/list-publications/ Description: Lista las Publicaciones de apps de Applivery usando la Integrations API o la Workspace API. Recupera IDs de Publicaciones y metadatos. TL;DR: Lista las publicaciones de tus aplicaciones en Applivery usando la API de Integraciones (por app) o la API de Workspace (multi-app). Answers: ¿Cómo listo las publicaciones de una sola app? · ¿Cómo listo publicaciones de varias apps a la vez? · ¿Qué autenticación requiere la Integrations API para listar publicaciones? · ¿Qué autenticación requiere la Workspace API para listar publicaciones? · ¿Cuál es el endpoint de la Integrations API para listar publicaciones? · ¿Cuál es el endpoint de la Workspace API para listar publicaciones? · ¿Qué parámetros de consulta puedo usar para filtrar publicaciones? · ¿Qué representa el campo id en la respuesta de lista de publicaciones? Devuelve una lista paginada de Publicaciones para una App determinada. Usa este endpoint para consultar el estado actual de tus Publicaciones, obtener los valores `publishedApplicationId` que necesitan otros endpoints, o construir dashboards y scripts de automatización que actúen sobre Publicaciones específicas. Applivery proporciona dos APIs independientes para listar Publicaciones, cada una con una credencial de autenticación diferente. --- ### Cómo elegir la API correcta | | Integrations API | Workspace API | |---|---|---| | **Diseñada para** | Integraciones por app y pipelines de CI/CD | Automatización a nivel de Workspace en varias Apps | | **Autenticación** | App API Token (por app) | token de una cuenta de servicio (a nivel de Workspace) | | **Contexto de app** | Implícito — el token ya está vinculado a una App | Explícito — se requieren `organizationId` y `storeId` en la ruta | | **Usuarios típicos** | Scripts que buscan el ID de una Publicación antes de actualizarla | Platform engineers que consultan Publicaciones de varias Apps | :::warning El acceso a las distintas APIs puede no estar disponible en tu plan actual. Consulta la disponibilidad en nuestra [página de precios](https://www.applivery.com/app-distribution-pricing/). ::: --- ### Integrations API Usa este endpoint para listar Publicaciones dentro del ámbito de una sola app. La autenticación usa un **App API Token**, vinculado a la App específica. Para crear un App API Token, consulta [Autenticación de la API de Apps](https://docs.applivery.com/es/app-distribution/api/app-api-token/). #### Endpoint ``` GET https://api.applivery.io/v1/integrations/distributions ``` #### Autenticación ``` Authorization: Bearer ``` #### Parámetros de consulta Todos los parámetros son opcionales. Sin filtros, el endpoint devuelve todas las Publicaciones de la App asociada al token. | Parámetro | Tipo | Descripción | |---|---|---| | `slug` | String | Filtra por slug de la Publicación. Devuelve solo la Publicación que coincide exactamente con este slug. | | `security` | String | Filtra por modo de seguridad. Valores permitidos: `public`, `password`, `logged`. | | `visibility` | String | Filtra por estado de visibilidad. Valores permitidos: `active`, `inactive`, `unlisted`. | | `filter-type` | String | Filtra por estrategia de selección de Build. Valores permitidos: `last`, `build`, `builds`, `gitBranch`, `gitTag`, `tag`. | | `page` | Integer | Número de página para paginación. Empieza en `1`. | | `limit` | Integer | Número máximo de Publicaciones a devolver por página. | #### Ejemplo de petición ```bash curl 'https://api.applivery.io/v1/integrations/distributions?visibility=active&security=public' \ -X GET \ -H 'Authorization: Bearer YOUR_APP_TOKEN' ``` #### Respuestas **✓ 200 OK** ```json { "status": true, "data": { "items": [ { "id": "string", "updatedAt": "2025-10-23T07:54:26.518Z", "createdAt": "2024-07-23T08:10:46.471Z", "application": "string", "applicationInfo": { "id": "string", "slug": "string", "name": "string", "picture": "string" }, "slug": "string", "filter": { "type": "last", "value": "string", "ios": "string", "android": "string", "windows": "string", "macos": "string", "builds": [ { "buildPlatform": "string", "id": "string" } ] }, "security": "public", "tags": ["string"], "groups": [["string"]], "activateUserAudiences": false, "userAudienceMap": [], "visibility": "active", "showHistory": false, "showDevInfo": false, "expirationDate": "string", "distributionUrl": "string", "terms": { "active": true, "text": "string" }, "configuration": { "branding": { "logo": "string", "primaryColor": "string", "useAppIcon": false }, "application": { "description": "string", "name": "string" } }, "allowedCountries": [], "blockedCountries": [] } ], "totalDocs": 0, "limit": 0, "hasPrevPage": true, "hasNextPage": true, "page": 0, "totalPages": 0, "pagingCounter": 0, "prevPage": 0, "nextPage": 0 } } ``` **✗ 401 Unauthorized** ```json { "status": false, "error": { "code": 4002, "message": "No auth token" } } ``` **✗ 404 Not Found** ```json { "status": false, "error": { "code": 3001, "message": "Entity not found" } } ``` #### Campos principales de la respuesta | Campo | Descripción | |---|---| | `id` | El identificador único de la Publicación (`publishedApplicationId`). Úsalo en los endpoints [PUT – Actualizar](https://docs.applivery.com/es/app-distribution/api/publications/update-publication/) y [DELETE](https://docs.applivery.com/es/app-distribution/api/publications/delete-publication/). | | `slug` | El identificador amigable para URL que forma parte de la URL de la Publicación. | | `distributionUrl` | La URL pública completa de la Publicación. Compártela con tus usuarios para darles acceso. | | `security` | Modo de seguridad actual: `public`, `password` o `logged`. | | `visibility` | Estado de visibilidad actual: `active`, `inactive` o `unlisted`. | | `filter.type` | Estrategia de selección de Build configurada: `last`, `build`, `builds`, `gitBranch`, `gitTag` o `tag`. | | `expirationDate` | Timestamp ISO 8601 a partir del cual la Publicación deja de estar disponible. `null` si no hay fecha de caducidad. | | `activateUserAudiences` | Si el control de acceso basado en audiencias está habilitado para esta Publicación. | | `userAudienceMap` | Array de asignaciones de audiencias para esta Publicación. | | `allowedCountries` | Códigos de país desde los que se permite explícitamente el acceso. Array vacío significa sin restricción. | | `blockedCountries` | Códigos de país desde los que se bloquea explícitamente el acceso. Array vacío significa sin restricción. | | `configuration` | Sobreescrituras de branding y nombre/descripción de app aplicadas a esta Publicación. | | `terms` | Configuración de términos legales — si se requiere aceptación y el texto de los términos. | #### Campos de paginación | Campo | Descripción | |---|---| | `totalDocs` | Número total de Publicaciones que coinciden con la consulta. | | `page` | Número de página actual. | | `totalPages` | Número total de páginas. | | `limit` | Número de resultados por página. | | `hasNextPage` | Si hay una página siguiente de resultados. | | `hasPrevPage` | Si hay una página anterior de resultados. | | `nextPage` | Número de la página siguiente, o `null` si estás en la última página. | | `prevPage` | Número de la página anterior, o `null` si estás en la primera página. | --- ### Workspace API Usa este endpoint para listar Publicaciones a nivel de Workspace — por ejemplo, en pipelines de automatización que operan en varias Apps usando una sola credencial. La autenticación usa un token de **cuenta de servicio**, con ámbito de Workspace y no vinculado a ninguna app individual. Para crear un token de una cuenta de servicio, consulta [Cuenta de servicio](https://docs.applivery.com/es/platform/api/service-accounts/). #### Endpoint ``` GET https://api.applivery.io/v1/organizations/{organizationId}/stores/{storeId}/pubApps ``` #### Parámetros de ruta | Parámetro | Tipo | Obligatorio | Descripción | |---|---|---|---| | `organizationId` | String | Sí | El identificador único de tu organización en Applivery. | | `storeId` | String | Sí | El identificador único de la store (proyecto de app) cuyas Publicaciones quieres listar. | #### Autenticación ``` Authorization: Bearer ``` #### Parámetros de consulta La Workspace API acepta los mismos parámetros de consulta que la Integrations API. #### Ejemplo de petición ```bash curl 'https://api.applivery.io/v1/organizations/ORG_ID/stores/STORE_ID/pubApps?visibility=active' \ -X GET \ -H 'Authorization: Bearer YOUR_SERVICE_ACCOUNT_TOKEN' ``` El esquema de respuesta es idéntico al de la Integrations API. --- ## Detalles de la Publicación Source: https://docs.applivery.com/es/app-distribution/api/publications/publication-details/ Description: Recupera los detalles completos de una Publicación de Applivery usando la Integrations API o la Workspace API. Incluye endpoints, autenticación y ejemplos. TL;DR: Obtén los detalles de una publicación en Applivery usando la API de Integraciones (App API Token) o la API de Workspace (Cuenta de servicio). Answers: ¿Cómo obtengo la configuración completa de una publicación? · ¿Cuál es la diferencia entre Integrations API y Workspace API para obtener detalles de una publicación? · ¿Qué autenticación requiere la Integrations API para detalles de publicación? · ¿Qué autenticación requiere la Workspace API para detalles de publicación? · ¿Qué ocurre si no proporciono un token de autenticación válido? · ¿Qué significa un error 404 al recuperar detalles de una publicación? · ¿Por qué debo recuperar los detalles de una publicación antes de actualizarla? · ¿Cómo encuentro la URL pública de una publicación? Devuelve la configuración completa de una Publicación individual, identificada por su `publishedApplicationId`. Usa este endpoint para inspeccionar el estado actual de una Publicación específica antes de actualizarla, verificar su configuración de acceso o recuperar su `distributionUrl`. :::warning Antes de actualizar una Publicación con PUT, **recupera siempre sus detalles actuales con este endpoint**. El [endpoint PUT](https://docs.applivery.com/es/app-distribution/api/publications/update-publication/) es una sustitución completa — obtener el estado actual te permite conservar los campos que no quieres modificar. ::: Applivery proporciona dos APIs independientes para recuperar detalles de Publicaciones, cada una con una credencial de autenticación diferente. --- ### Cómo elegir la API correcta | | Integrations API | Workspace API | |---|---|---| | **Diseñada para** | Integraciones por app y pipelines de CI/CD | Automatización a nivel de Workspace en varias Apps | | **Autenticación** | App API Token (por app) | token de una cuenta de servicio (a nivel de Workspace) | | **Contexto de app** | Implícito — el token ya está vinculado a una App | Explícito — se requieren `organizationId`, `storeId` y `publishedApplicationId` en la ruta | | **Usuarios típicos** | Scripts que leen la configuración de una Publicación antes de actualizarla | Platform engineers que inspeccionan Publicaciones de varias Apps | :::warning El acceso a las distintas APIs puede no estar disponible en tu plan actual. Consulta la disponibilidad en nuestra [página de precios](https://www.applivery.com/app-distribution-pricing/). ::: --- ### Integrations API Usa este endpoint para recuperar detalles de Publicaciones dentro del ámbito de una sola app. La autenticación usa un **App API Token**, vinculado a la App específica. Para crear un App API Token, consulta [Autenticación de la API de Apps](https://docs.applivery.com/es/app-distribution/api/app-api-token/). #### Endpoint ``` GET https://api.applivery.io/v1/integrations/distributions/{publishedApplicationId} ``` #### Autenticación ``` Authorization: Bearer ``` #### Parámetros de ruta | Parámetro | Tipo | Obligatorio | Descripción | |---|---|---|---| | `publishedApplicationId` | String | Sí | El identificador único de la Publicación a recuperar. P. ej. `552ae3cfcb5abfc58d733b81`. Devuelto por [POST – Crear una Publicación](https://docs.applivery.com/es/app-distribution/api/publications/create-publication/) y [GET – Lista de Publicaciones](https://docs.applivery.com/es/app-distribution/api/publications/list-publications/). | #### Ejemplo de petición ```bash curl 'https://api.applivery.io/v1/integrations/distributions/552ae3cfcb5abfc58d733b81' \ -X GET \ -H 'Authorization: Bearer YOUR_APP_TOKEN' ``` #### Respuestas **✓ 200 OK** ```json { "status": true, "data": { "id": "string", "updatedAt": "2025-10-23T07:54:26.518Z", "createdAt": "2024-07-23T08:10:46.471Z", "application": "string", "applicationInfo": { "id": "string", "slug": "string", "name": "string", "picture": "string" }, "slug": "string", "filter": { "type": "last", "value": "string", "ios": "string", "android": "string", "windows": "string", "macos": "string", "builds": [ { "buildPlatform": "string", "id": "string" } ] }, "security": "public", "tags": ["string"], "groups": [["string"]], "activateUserAudiences": false, "userAudienceMap": [], "visibility": "active", "showHistory": false, "showDevInfo": false, "expirationDate": "string", "distributionUrl": "string", "terms": { "active": true, "text": "string" }, "configuration": { "branding": { "logo": "string", "primaryColor": "string", "useAppIcon": false }, "application": { "description": "string", "name": "string" } }, "allowedCountries": [], "blockedCountries": [] } } ``` **✗ 401 Unauthorized** ```json { "status": false, "error": { "code": 4002, "message": "No auth token" } } ``` **✗ 404 Not Found** ```json { "status": false, "error": { "code": 3001, "message": "Entity not found" } } ``` #### Campos principales de la respuesta | Campo | Descripción | |---|---| | `id` | El identificador único de esta Publicación (`publishedApplicationId`). | | `slug` | El identificador amigable para URL que forma parte de la URL de la Publicación. | | `distributionUrl` | La URL pública completa de la Publicación. | | `security` | Modo de seguridad actual: `public`, `password` o `logged`. | | `visibility` | Estado de visibilidad actual: `active`, `inactive` o `unlisted`. | | `filter.type` | Estrategia de selección de Build: `last`, `build`, `builds`, `gitBranch`, `gitTag` o `tag`. | | `filter.value` | El nombre de rama, git tag o build tag configurado actualmente (para los tipos de filtro `gitBranch`, `gitTag` y `tag`). | | `filter.ios` / `filter.android` / `filter.macos` / `filter.windows` | IDs de Build por plataforma (para el tipo de filtro `build`). | | `filter.builds` | Array de objetos `{ buildPlatform, id }` (para el tipo de filtro `builds`, incluidas plataformas personalizadas). | | `expirationDate` | Timestamp ISO 8601 a partir del cual la Publicación deja de estar disponible. `null` si no hay caducidad configurada. | | `groups` | Array anidado de identificadores de Grupos de usuarios que controlan el acceso (lógica AND/OR). | | `activateUserAudiences` | Si el control de acceso basado en audiencias está habilitado. | | `userAudienceMap` | Array de asignaciones de audiencias, cada una con `id` y `notifyNewBuildsProcessed`. | | `showHistory` | Si los usuarios pueden explorar e instalar Builds anteriores. | | `showDevInfo` | Si se muestra información técnica de la Build (metadatos de git, detalles del certificado, tags) a los usuarios. | | `allowedCountries` | Códigos de país desde los que se permite el acceso. Array vacío significa sin restricción de país. | | `blockedCountries` | Códigos de país desde los que se bloquea el acceso. Array vacío significa sin restricción de país. | | `configuration.application` | Sobreescrituras del nombre y descripción de la app aplicadas a esta Publicación. | | `configuration.branding` | Sobreescrituras de logo, color primario y color de botón aplicadas a esta Publicación. | | `terms` | Configuración de términos legales — `active` indica si se requiere aceptación, `text` contiene el contenido de los términos. | --- ### Workspace API Usa este endpoint para recuperar detalles de Publicaciones a nivel de Workspace — por ejemplo, en pipelines de automatización que operan en varias Apps usando una sola credencial. La autenticación usa un token de **cuenta de servicio**, con ámbito de Workspace y no vinculado a ninguna app individual. Para crear un token de una cuenta de servicio, consulta [Cuentas de servicio](https://docs.applivery.com/es/platform/api/service-accounts/). #### Endpoint ``` GET https://api.applivery.io/v1/organizations/{organizationId}/stores/{storeId}/pubApps/{publishedApplicationId} ``` #### Parámetros de ruta | Parámetro | Tipo | Obligatorio | Descripción | |---|---|---|---| | `organizationId` | String | Sí | El identificador único de tu organización en Applivery. | | `storeId` | String | Sí | El identificador único de la store (proyecto de app) a la que pertenece la Publicación. | | `publishedApplicationId` | String | Sí | El identificador único de la Publicación a recuperar. | #### Autenticación ``` Authorization: Bearer ``` #### Ejemplo de petición ```bash curl 'https://api.applivery.io/v1/organizations/ORG_ID/stores/STORE_ID/pubApps/552ae3cfcb5abfc58d733b81' \ -X GET \ -H 'Authorization: Bearer YOUR_SERVICE_ACCOUNT_TOKEN' ``` El esquema de respuesta es idéntico al de la Integrations API. --- ## Actualizar Publicación Source: https://docs.applivery.com/es/app-distribution/api/publications/update-publication/ Description: Actualiza Publicaciones existentes de Applivery usando la Integrations API o la Workspace API. Controla seguridad, visibilidad, filtros de Build y más. TL;DR: Actualiza tus aplicaciones publicadas en Applivery vía API usando la API de Integraciones (por app) o la API de Workspace (multi-app). Answers: ¿Qué ocurre si no incluyo un campo al actualizar una publicación? · ¿Cuáles son las dos APIs para actualizar publicaciones en Applivery? · ¿Cuándo debo usar la Integrations API para actualizar una publicación? · ¿Cuándo debo usar la Workspace API para actualizar una publicación? · ¿Cómo me autentico con la Integrations API para actualizar una publicación? · ¿Cómo me autentico con la Workspace API para actualizar una publicación? · ¿Qué método HTTP se usa para actualizar una publicación? · ¿Cómo restrinjo el acceso a una publicación a grupos de usuarios específicos? Actualiza la configuración de una Publicación existente. Todos los campos actualizables del endpoint [POST – Crear una Publicación](https://docs.applivery.com/es/app-distribution/api/publications/create-publication/) están soportados aquí, incluyendo el modo de seguridad, el filtro de Build, el control de acceso, la visibilidad, las sobreescrituras de branding y los términos legales. :::warning Esta es una sustitución completa (`PUT`), no una actualización parcial (`PATCH`). Cualquier campo no incluido en el cuerpo de la petición se reseteará a su valor por defecto. Recupera siempre el estado actual de la Publicación primero e incluye todos los campos que quieras conservar. ::: Applivery proporciona dos APIs independientes para actualizar Publicaciones, cada una con una credencial de autenticación diferente. * * * ### Cómo elegir la API correcta | | Integrations API | Workspace API | |---|---|---| | **Diseñada para** | Pipelines de CI/CD por app | Automatización a nivel de Workspace en varias Apps | | **Autenticación** | App API Token (por app) | token de una cuenta de servicio (a nivel de Workspace) | | **Contexto de app** | Implícito — el token ya está vinculado a una App | Explícito — se requieren `organizationId` y `storeId` en la ruta | | **Usuarios típicos** | Scripts que actualizan el filtro de Build de una Publicación tras una nueva subida | Platform engineers que gestionan Publicaciones de varias Apps | :::warning El acceso a las distintas APIs puede no estar disponible en tu plan actual. Consulta la disponibilidad en nuestra [página de precios](https://www.applivery.com/app-distribution-pricing/). ::: * * * ### Integrations API Usa este endpoint para actualizar Publicaciones dentro del ámbito de una sola app. La autenticación usa un **App API Token**, vinculado a la App específica. Para crear un App API Token, consulta [Autenticación de la API de Apps](https://docs.applivery.com/es/app-distribution/api/app-api-token/). #### Endpoint ``` PUT https://api.applivery.io/v1/integrations/distributions/{publishedApplicationId} ``` #### Autenticación ``` Authorization: Bearer ``` #### Formato de la petición `application/json` #### Parámetros de ruta | Parámetro | Tipo | Obligatorio | Descripción | |---|---|---|---| | `publishedApplicationId` | String | Sí | El identificador único de la Publicación a actualizar. P. ej. `552ae3cfcb5abfc58d733b81`. Devuelto por POST – Crear una Publicación y GET – Lista de Publicaciones. | * * * #### Parámetros ##### Identidad y visibilidad | Parámetro | Tipo | Descripción | |---|---|---| | `slug` | String | El identificador amigable para URL de esta Publicación. Debe ser único en el Workspace. Cambiar el slug cambia la URL de la Publicación — los enlaces existentes dejarán de funcionar. | | `visibility` | String | Visibilidad de la Publicación. Valores permitidos: `active`, `inactive`, `unlisted`. | ##### Seguridad y control de acceso | Parámetro | Tipo | Descripción | |---|---|---| | `security` | String | Modo de autenticación. Valores permitidos: `public`, `password`, `logged`. | | `password` | String | Obligatorio cuando `security` es `password`. La contraseña que deben introducir los usuarios para acceder a la Publicación. | | `groups` | Array | Restringe el acceso a Grupos de usuarios específicos. Soporta lógica AND/OR. Cada array interno es una cláusula AND; cada elemento externo es una cláusula OR. P. ej. `[["group1","group2"],["group3"]]`. Solo aplica cuando `security` es `logged`. | | `activateUserAudiences` | Boolean | Si se habilita el acceso basado en audiencias para esta Publicación. | | `userAudienceMap` | Array | Array de asignaciones de audiencias para esta Publicación. | | `userAudienceMap[].id` | String | ID de la audiencia a asignar. | | `userAudienceMap[].notifyNewBuildsProcessed` | Boolean | Si los usuarios de esta audiencia deben recibir notificaciones cuando se procesa un nuevo Build. | | `allowedCountries` | Array | Códigos de país ISO 3166-1 alpha-2 desde los que se **permite** el acceso. No puede combinarse con `blockedCountries`. | | `blockedCountries` | Array | Códigos de país ISO 3166-1 alpha-2 desde los que se **bloquea** el acceso. No puede combinarse con `allowedCountries`. | ##### Filtro de selección de Build | Parámetro | Tipo | Descripción | |---|---|---| | `filter.type` | String | Estrategia de selección de Build. Valores permitidos: `last`, `build`, `Builds`, `gitBranch`, `gitTag`, `tag`. | | `filter.value` | String | Obligatorio para los tipos de filtro `gitBranch`, `gitTag` y `tag`. El nombre de rama, git tag o build tag a coincidir. | | `filter.ios` | String | ID de la Build para iOS. Usado cuando `filter.type` es `build`. | | `filter.android` | String | ID de la Build para Android. Usado cuando `filter.type` es `build`. | | `filter.macos` | String | ID de la Build para macOS. Usado cuando `filter.type` es `build`. | | `filter.windows` | String | ID de la Build para Windows. Usado cuando `filter.type` es `build`. | | `filter.Builds` | Array | Array de objetos `{ buildPlatform, id }`. Usado cuando `filter.type` es `Builds`. Soporta plataformas personalizadas: `ios`, `macos`, `android`, `ps4`, `ps5`, `switch`, `xbox-one`, `xbox-series`. | ##### Opciones de visualización de Builds | Parámetro | Tipo | Descripción | |---|---|---| | `tags` | Array | Tags para categorizar esta Publicación. | | `showHistory` | Boolean | Si los usuarios pueden explorar e instalar Builds anteriores. | | `showDevInfo` | Boolean | Si se muestra información técnica de la Build (metadatos de git, detalles del certificado, tags) a los usuarios. | | `expirationDate` | String | Timestamp ISO 8601 a partir del cual la Publicación deja de estar disponible para descarga. Útil para distribuciones con fecha límite, programas beta o campañas promocionales. P. ej. `"2025-12-31T23:59:59Z"`. Establece en `null` para eliminar una fecha de caducidad existente. | ##### Términos legales | Parámetro | Tipo | Descripción | |---|---|---| | `terms.active` | Boolean | Si los usuarios deben aceptar los términos legales antes de acceder a la Publicación. | | `terms.text` | String | El texto de los términos legales a mostrar. Obligatorio cuando `terms.active` es `true`. | ##### Sobreescrituras de branding y configuración de app | Parámetro | Tipo | Descripción | |---|---|---| | `configuration.application.name` | String | Sobreescribe el nombre de la App mostrado en la Publicación. | | `configuration.application.description` | String | Sobreescribe la descripción de la App mostrada en la Publicación. | | `configuration.branding.logo` | String | Sobreescribe el logo de la store para esta Publicación. | | `configuration.branding.primaryColor` | String | Sobreescribe el color de branding primario (formato hex). P. ej. `#FF5733`. | | `configuration.branding.buttonColor` | String | Sobreescribe el color del botón (formato hex). | * * * #### Ejemplo de petición Actualiza una Publicación para apuntar a una rama de git específica y restringe el acceso a usuarios conectados de un grupo concreto: ```bash curl 'https://api.applivery.io/v1/integrations/distributions/552ae3cfcb5abfc58d733b81' \ -X PUT \ -H 'Authorization: Bearer YOUR_APP_TOKEN' \ -H 'Content-Type: application/json' \ -d '{ "slug": "my-app-staging", "security": "logged", "visibility": "active", "filter": { "type": "gitBranch", "value": "develop" }, "groups": [["qa-team"]], "showHistory": true, "showDevInfo": true }' ``` #### Respuestas **✓ 200 OK** ```json { "status": true, "data": { "id": "string", "updatedAt": "string", "createdAt": "string", "application": "string", "applicationInfo": { "id": "string", "slug": "string", "name": "string", "picture": "string" }, "slug": "string", "filter": { "type": "last", "value": "string", "ios": "string", "android": "string", "windows": "string", "macos": "string", "builds": [ { "buildPlatform": "string", "id": "string" } ] }, "security": "public", "tags": ["string"], "groups": [["string"]], "visibility": "active", "showHistory": true, "showDevInfo": true, "distributionUrl": "string", "terms": { "active": true, "text": "string" } } } ``` **✗ 400 Bad Request** El slug ya está en uso. ```json { "status": false, "error": { "code": 5024, "message": "Slug already used" } } ``` **✗ 401 Unauthorized** ```json { "status": false, "error": { "code": 4002, "message": "No auth token" } } ``` **✗ 404 Not Found** ```json { "status": false, "error": { "code": 3001, "message": "Entity not found" } } ``` * * * ### Workspace API Usa este endpoint para actualizar Publicaciones a nivel de Workspace usando una sola credencial en varias Apps. La autenticación usa un token de **cuenta de servicio**. Para crear un token de una cuenta de servicio, consulta [Cuentas de servicio](https://docs.applivery.com/es/platform/api/service-accounts/). #### Endpoint ``` PUT https://api.applivery.io/v1/organizations/{organizationId}/stores/{storeId}/pubApps/{publishedApplicationId} ``` #### Parámetros de ruta | Parámetro | Tipo | Obligatorio | Descripción | |---|---|---|---| | `organizationId` | String | Sí | El identificador único de tu organización en Applivery. | | `storeId` | String | Sí | El identificador único de la store (proyecto de app). | | `publishedApplicationId` | String | Sí | El identificador único de la Publicación a actualizar. | #### Autenticación ``` Authorization: Bearer ``` #### Ejemplo de petición ```bash curl 'https://api.applivery.io/v1/organizations/ORG_ID/stores/STORE_ID/pubApps/PUB_APP_ID' \ -X PUT \ -H 'Authorization: Bearer YOUR_SERVICE_ACCOUNT_TOKEN' \ -H 'Content-Type: application/json' \ -d '{ "slug": "my-app-release", "security": "public", "visibility": "active", "filter": { "type": "last" } }' ``` Los parámetros del cuerpo de la petición y el esquema de respuesta son idénticos a los de la Integrations API. * * * ### Gestión de usuarios con acceso OTP El **acceso OTP (One-Time Password)** es una opción de seguridad a nivel de Publicación que te permite compartir Builds de forma segura con usuarios externos — freelancers, estudios de QA, contratistas — **sin que necesiten tener una cuenta de Applivery ni pasar por tu SSO**. Esto es especialmente útil para organizaciones con políticas de SSO estrictas que necesitan compartir Builds externamente sin relajar su configuración global de autenticación. El acceso OTP se configura por Publicación y no afecta a ninguna otra Publicación ni a la configuración global de autenticación de la Store Enterprise. :::info La configuración OTP solo puede aplicarse en **modo de edición** — debe configurarse después de que la Publicación ya haya sido creada. Actívala estableciendo `security` en `"private"` y habilitando OTP en el panel de Applivery, o usando el endpoint API descrito a continuación para añadir usuarios a la lista de acceso. ::: :::info Los usuarios OTP tienen ámbito sobre la Publicación específica a la que accedieron. No pueden explorar ni acceder a otras Publicaciones de la Store Enterprise. ::: #### Cómo funciona **Por parte del administrador:** 1. Crea o actualiza una Publicación con el acceso OTP habilitado (`security: "private"` + lista de acceso OTP configurada). 2. Añade las direcciones de email de los usuarios externos autorizados a la lista de acceso OTP, y configura el ciclo de vida y la configuración de uso único de cada usuario. **Por parte del usuario:** 1. El usuario visita la URL de la Publicación e introduce su dirección de email. 2. Si su email está en la lista de acceso, recibe un OTP con tiempo limitado por email (válido 5–10 minutos). 3. Introduce el código para verificar su identidad y obtener acceso para descargar la App. 4. Si el uso único está habilitado, su email se elimina automáticamente de la lista de acceso tras la primera descarga correcta. #### Añadir usuarios OTP mediante API Los usuarios OTP se gestionan de forma independiente a la configuración de la Publicación en sí, a través de un endpoint dedicado. Este endpoint se llama **después** de crear o actualizar una Publicación para añadir usuarios a su lista de acceso OTP. ##### Endpoint ``` POST https://api.applivery.io/v1/organizations/{organizationSlug}/stores/{storeId}/otp-users ``` ##### Autenticación ``` Authorization: Bearer ``` ##### Parámetros de ruta | Parámetro | Tipo | Obligatorio | Descripción | |---|---|---|---| | `organizationSlug` | String | Sí | El slug amigable para URL de tu organización en Applivery (no el ID numérico). | | `storeId` | String | Sí | El identificador único de la store a la que pertenece la Publicación. | ##### Parámetros del cuerpo | Parámetro | Tipo | Obligatorio | Descripción | |---|---|---|---| | `email` | String | Sí | La dirección de email del usuario externo a añadir a la lista de acceso OTP. | | `temporal` | Boolean | No | Si el usuario debe eliminarse automáticamente tras 30 días. Por defecto: `true`. Establece en `false` para acceso persistente. | | `singleUse` | Boolean | No | Si el acceso del usuario debe invalidarse tras la primera descarga correcta. Una vez descargado, el email se elimina de la lista de acceso y el usuario debe ser añadido de nuevo para recuperar el acceso. Por defecto: `false`. | ##### Ejemplo de petición ```bash curl 'https://api.applivery.io/v1/organizations/my-org-slug/stores/STORE_ID/otp-users' \ -X POST \ -H 'Authorization: Bearer YOUR_SERVICE_ACCOUNT_TOKEN' \ -H 'Content-Type: application/json' \ -d '{ "email": "contractor@externalstudio.com", "temporal": true, "singleUse": false }' ``` ##### Respuestas **✓ 200 OK** ```json { "status": true, "data": { "id": "string", "email": "contractor@externalstudio.com", "temporal": true, "singleUse": false, "createdAt": "string" } } ``` **✗ 400 Bad Request** El email ya existe en la lista de acceso OTP para esta store. **✗ 401 Unauthorized** Token de cuenta de servicio inválido o ausente. **✗ 404 Not Found** Slug de organización o ID de store no encontrados. #### Referencia de opciones de configuración OTP | Opción | Descripción | |---|---| | **Lista de acceso** | La lista de direcciones de email autorizadas para solicitar un OTP para esta Publicación. | | **Ciclo de vida del usuario** | `temporal: true` — los usuarios OTP se eliminan automáticamente tras 30 días. `temporal: false` — los usuarios OTP se conservan indefinidamente. | | **Acceso de uso único** | `singleUse: true` — el email se elimina de la lista de acceso tras la primera descarga correcta. El usuario no puede solicitar otro OTP a menos que un administrador le añada de nuevo. | | **Caducidad del OTP** | Los OTPs tienen tiempo limitado y son de uso único — válidos 5–10 minutos y no pueden reutilizarse aunque estén dentro del período de validez. | | **Notificaciones de nuevos Builds** | Cuando se publica un nuevo Build, los usuarios OTP de la lista de acceso pueden recibir un email de notificación con un OTP nuevo, lo que les permite descargar sin solicitar acceso de nuevo manualmente. | #### Cuándo usar el acceso OTP | Escenario | Enfoque recomendado | |---|---| | Compartir una Build con un freelancer externo para una revisión puntual | OTP + `singleUse: true` | | Compartir una beta con un estudio de QA externo durante un período de prueba limitado | OTP + Publicación con caducidad | | Distribuir a una lista de testers externos sin cuentas permanentes | OTP + `temporal: true` (limpieza automática a los 30 días) | | Colaboradores externos a largo plazo que necesitan acceso continuado | Publicación privada + acceso basado en audiencias en lugar de OTP | :::tip Para un control máximo sobre el acceso externo con límite de tiempo, combina OTP con una **Publicación con caducidad**. Esto garantiza que el acceso esté tanto verificado por identidad (a través de la lista OTP) como limitado en el tiempo (a través de la caducidad de la Publicación) — sin necesidad de limpieza manual una vez superada la fecha límite. ::: --- ## Autenticación Source: https://docs.applivery.com/es/app-distribution/authentication/ Description: Applivery usa login social de Google para el acceso seguro y sin fricciones al Enterprise Store. Configura el inicio de sesión y el control de acceso para tu organización. Answers: ¿Qué método de autenticación usa Applivery? · ¿Cómo garantiza Applivery el acceso seguro al Enterprise Store? · ¿Qué opciones de autenticación están disponibles para los usuarios de la tienda? La autenticación controla cómo inician sesión los usuarios en la Enterprise Store de Applivery. Por defecto, los usuarios pueden autenticarse con login social de Google, lo que ofrece una experiencia de inicio de sesión sencilla y fiable con un control de acceso seguro. Puedes elegir qué opciones de autenticación están disponibles para los usuarios de la tienda y configurarlas para tu organización. --- ## Google Login Source: https://docs.applivery.com/es/app-distribution/authentication/google-login/ Description: Integra Google login en Applivery para simplificar la autenticación y la gestión de usuarios en tu Enterprise Store. TL;DR: Integra el inicio de sesión con Google en Applivery para simplificar la autenticación de usuarios en tu Enterprise Store. Answers: ¿Cómo activo Google login en Applivery? · ¿Dónde encuentro los ajustes de proveedores de inicio de sesión? · ¿Quién puede acceder al Enterprise Store con Google login? · ¿Qué ocurre si un usuario no tiene rol asignado en el Workspace? Applivery permite integrar Google para que tú y tus usuarios podáis iniciar sesión con vuestras credenciales de Google, simplificando la autenticación y la gestión de usuarios. ### Configura tu Google login Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a **Ajustes del Workspace** 1 desde el menú desplegable superior, luego abre **Proveedores de acceso** 2 en el menú lateral izquierdo y haz clic en la opción **Social** bajo la sección **Enterprise Store** 3. ![google login provider](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/eb4c4cef-3463-4363-8450-fd8d30d93f17.png) Solo tienes que Guardar la configuración. ![google login provider save](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/f3438cf4-ddfc-4c0c-8fca-bcd22e95ef95.png) :::warning Una vez guardada la configuración, no olvides **activarlo** para que la integración empiece a funcionar en tu Enterprise Store. ::: :::warning Solo los correos con un rol activo en el Workspace pueden acceder al Enterprise Store. Los correos sin un rol asignado tendrán el acceso denegado. ::: --- ## Builds Source: https://docs.applivery.com/es/app-distribution/builds/ Description: Las Builds en Applivery representan las versiones de tus Apps. Gestiona cargas, actualizaciones, almacenamiento, políticas de retención y publicaciones controladas desde un solo lugar. Answers: ¿Qué es una Build en Applivery? · ¿Qué puedo hacer con las Builds en Applivery? · ¿Qué contiene una Build de Applivery? Las Builds representan las distintas versiones de tus Apps que cargas, gestionas y distribuyes dentro de tu Workspace. Cada Build contiene el paquete de la app compilado junto con sus metadatos asociados, lo que te permite organizar versiones, hacer seguimiento de actualizaciones y controlar cómo llega cada publicación a tus usuarios. Carga y etiqueta Builds, notifica a los Colaboradores, gestiona los tokens de descarga y trabaja con la configuración a nivel de Build. --- ## Retención de Builds Source: https://docs.applivery.com/es/app-distribution/builds/build-retention/ Description: Configura las políticas de retención de Builds en Applivery a nivel de Workspace y de App para gestionar el almacenamiento y garantizar el acceso a las Builds más recientes. TL;DR: La retención de builds de Applivery te permite controlar durante cuánto tiempo se almacenan tus builds, ayudándote a gestionar los costes de almacenamiento y mantener tu Workspace organizado. Answers: ¿Qué es la retención de Builds en Applivery? · ¿Cuánto tiempo se conservan las Builds antes de eliminarse? · ¿Cómo configuro la retención de Builds a nivel de Workspace? · ¿Puedo configurar una política de retención personalizada por App? · ¿Qué ocurre cuando una Build alcanza el límite de retención? :::warning Esta funcionalidad puede variar según tu plan actual. Consulta la disponibilidad en nuestra [página de precios.](https://www.applivery.com/app-distribution-pricing/) ::: La **retención de Builds** te permite definir cuánto tiempo se almacenan las Builds cargadas en Applivery antes de archivarse y eliminarse permanentemente. Anteriormente, las Builds cargadas se conservaban indefinidamente. Con este nuevo sistema, las Builds se retienen según tu **plan de suscripción** y la **configuración de retención**. - La **retención ilimitada** solo está disponible para los **planes Enterprise** y debe habilitarse expresamente previa solicitud. - Cuando una Build alcanza el final de su periodo de retención, pasa a la **etapa de eliminación pendiente**, donde permanece durante un **periodo de gracia de 30 días** antes de eliminarse permanentemente. ### Reglas de retención automática Aunque haya límites de retención configurados, Applivery preserva automáticamente un **número mínimo de Builds recientes por Publicación**. Esto garantiza que siempre tengas acceso a las Builds más recientes de cada Publicación de App dentro de tu Workspace. Cuando se alcanza el límite de retención, las Builds más antiguas se eliminan primero, mientras que las más recientes se conservan. ### Configurar la retención de Builds Puedes configurar la retención de Builds en dos niveles: - Nivel de Workspace. - Nivel de App. #### Nivel de Workspace Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a **Ajustes del Workspace** 1, selecciona **Almacenamiento** 2 en el menú lateral izquierdo y baja hasta localizar la configuración de la **Política de retención de Builds** 3. ![build retention](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/b8e3109b-d325-4029-91d8-882d3858da62.png) Aquí puedes: - Especificar el **periodo de retención** (el número de días que se conserva una Build antes de eliminarse). - Establecer el **número de Builds recientes a conservar por Publicación** (se preservan aunque superen el periodo de retención). :::info Por defecto, todas las Apps del Workspace heredan esta configuración. ::: :::warning En los **planes Enterprise**, puedes habilitar la **retención ilimitada** si ha sido activada previamente tras contactar con nuestro equipo. Para otros planes, puedes ajustar los valores dentro de los límites de tu suscripción. ::: #### Nivel de App Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), selecciona la **App** que quieres configurar, dirígete a la pestaña **Ajustes** y abre la sección **Avanzado**. Localiza la configuración de la **Política de retención de Builds**. ![build retention period app](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/5109af55-aa1d-48e1-bd64-df5c9431b7e2.png) En este nivel, puedes: - Heredar la configuración del Workspace, o - Definir una **política de retención personalizada** para esa App concreta — incluyendo retención ilimitada (si está disponible en tu plan) o un periodo de retención personalizado y el número de Builds a conservar por Publicación. --- ## Regiones de almacenamiento personalizadas Source: https://docs.applivery.com/es/app-distribution/builds/custom-storage-regions/ Description: Configura regiones de almacenamiento personalizadas en AWS S3 y GCP para tu cuenta de Applivery y controla dónde se almacenan tus archivos de Builds. TL;DR: Configura regiones de almacenamiento personalizadas en AWS S3 o GCP para tu cuenta de Applivery siguiendo esta guía paso a paso. Answers: ¿Qué permisos de AWS S3 necesita Applivery? · ¿Cómo creo una cuenta de servicio en GCP Cloud Storage? · ¿Qué política de control de acceso debo usar para mi bucket de GCP? · ¿Dónde configuro mi región de almacenamiento personalizada en Applivery? · ¿Las Builds existentes se trasladan a la nueva región de almacenamiento? :::warning Esta es una funcionalidad premium que puede no estar disponible en tu plan actual. Consulta la disponibilidad en nuestra [página de precios](https://www.applivery.com/pricing/). ::: Los clientes pueden gestionar sus propias [Regiones de almacenamiento](https://docs.applivery.com/es/app-distribution/builds/storage-regions/) en [AWS S3](#aws-s3) y [GCP Cloud Storage](#gcp-cloud-storage). ### AWS S3 #### Creación del bucket **Inicia sesión en AWS** Inicia sesión en tu [consola de Amazon Web Services](https://console.aws.amazon.com/) con tus credenciales. **Ve a S3** Accede a la sección **Almacenamiento > S3**. **Crea un bucket** Haz clic en el botón naranja **Crear bucket**. **Rellena la información del bucket** Rellena la información de tu bucket (nombre del bucket y región). ![s3-custom-bucket-name | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/df0f395b-d3b0-4d4e-bfe7-fc39932a86fe.png) **Configura el acceso público** Baja hasta la sección **Configuración de Bloqueo de acceso público para el bucket** y selecciona las dos opciones siguientes: - Bloquear el acceso público a los buckets y objetos concedido a través de nuevas políticas de buckets o puntos de acceso públicos. - Bloquear el acceso público y entre cuentas a los buckets y objetos a través de cualquier política de bucket o punto de acceso público. - Reconozco que la configuración actual puede provocar que este bucket y los objetos que contiene se vuelvan públicos. ![s3-custom-bucket-security | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/40eb86d0-5a52-4534-9848-f6c47d0579ec.png) **Crea el bucket** Baja y haz clic en el botón naranja **Crear bucket**. #### Configuración de credenciales **Crea un nuevo usuario de AWS** Recomendamos crear **un nuevo usuario de AWS** y sus credenciales. Ve a la sección **AWS IAM > Usuarios** y haz clic en el botón **Añadir usuario**. **Selecciona el tipo de usuario** Selecciona un nombre de usuario y elige la opción **Acceso programático** en la sección de tipo de acceso. ![s3-custom-bucket-user | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/260914eb-a80b-4096-a123-1f4760264076.png) **Sigue el asistente** Haz clic en **Siguiente** y sigue los pasos 2, 3 y 4 sin cambiar nada, manteniendo las opciones por defecto. Termina haciendo clic en el botón **Crear usuario**. **Guarda las credenciales** Se mostrarán las credenciales del usuario; cópialas y guárdalas en un lugar seguro. Tendrás que proporcionárselas a nuestro equipo. ![s3-custom-bucket-credentials | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/648a8e9f-ba6a-47c7-9938-1054bccd68c8.png) #### Conceder permisos **Añade una política inline** Ahora hay que conceder algunos permisos adicionales al nuevo usuario. En este ejemplo usaremos las Políticas inline de AWS, aunque como alternativa puedes crear una nueva Política y adjuntarla al usuario. Haz clic en el nuevo usuario y, bajo la pestaña Permisos, haz clic en **Añadir política inline**. **Usa el editor JSON** Usa el editor **{} JSON** e introduce la siguiente política de AWS: ```json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:PutObject", "s3:GetObject", "s3:DeleteObject", "s3:GetBucketLocation", "s3:PutObjectAcl" ], "Resource": [ "arn:aws:s3:::mycustom-private-bucket", "arn:aws:s3:::mycustom-private-bucket/*" ] } ] } ``` :::warning Debes sustituir `arn:aws:s3:::mycustom-private-bucket` por el ARN del bucket que creaste en el paso anterior. ::: #### Selecciona tu nueva región de almacenamiento **Accede a la configuración de almacenamiento** Una vez creado, se añadirá un nuevo registro a la lista, fácilmente identificable porque aparecerá con el título **Tú** o **Gestionado por**. **Configura la región de almacenamiento** Puedes configurar tu Región de almacenamiento personalizada a nivel de Workspace o de App: - **Workspace:** La configuración se aplicará a todo el Workspace, a todas las Apps excepto a las que ya tengan una Región de almacenamiento personalizada configurada. Para habilitarla, haz clic en **Seleccionar** en esta pantalla. - **App:** La configuración se aplicará solo a esta App, independientemente de la configuración del Workspace. Para ellodirígete a **Ajustes de la App > Avanzado** y **Selecciona** el proveedor de almacenamiento que quieras. :::info Solo las nuevas Builds cargadas se almacenarán en la nueva región. Las anteriores permanecerán en el mismo lugar. ::: ### GCP Cloud Storage #### Crear una cuenta de servicio **Inicia sesión en GCP** Inicia sesión en tu [consola de Google Cloud](https://console.cloud.google.com/) con tus credenciales. **Ve a Cuentas de servicio** Ve a la sección **IAM > Cuentas de servicio** y haz clic en el botón **Crear cuenta de servicio**. **Rellena la información de la cuenta de servicio** Rellena el **Paso 1** con la información de tu cuenta de servicio. Puedes omitir los **Pasos 2** y 3 de momento. Luego haz clic en **Listo**. ![step1-gcp-serviceaccount-001 | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/c888ba1f-083f-481e-aec2-9e2c55bcf1e5.png) **Crea una clave** Una vez creada la cuenta de servicio, haz clic en el botón **CREAR CLAVE**. **Ve a Interoperabilidad de Cloud Storage** Ahora ve a **Cloud Storage** en el menú de productos de GCP y haz clic en **Configuración > Interoperabilidad**. **Crea una clave para la cuenta de servicio** Baja hasta **HMAC de cuenta de servicio** y haz clic en **+CREAR UNA CLAVE PARA OTRA CUENTA DE SERVICIO**. ![step1-gcp-cloudstorage-interoperability | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/4209fb9f-ee32-479a-b02c-34e0f90fb9c3.png) **Selecciona la cuenta de servicio** Usa las opciones de filtrado para encontrar la cuenta de servicio que generaste en el paso anterior. Selecciónala y haz clic en **CREAR CLAVE**. ![step1-gcp-serviceaccount-004 | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ff2ccaae-1bf5-406b-8238-9ab8b48f99e0.png) **Guarda las credenciales** Se generará un nuevo par de **Clave de acceso** y **Secreto**. Guarda estos valores para más adelante. ![step1-gcp-serviceaccount-005 | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/6e63f445-1343-4448-9c8b-2914a154418b.png) #### Crear un bucket de Cloud Storage **Ve a Cloud Storage** Ve a **Cloud Storage** desde el menú de productos y haz clic en **Crear bucket**. **Rellena el nombre del bucket** Rellena el nombre del bucket y haz clic en **CONTINUAR**. ![step2-gcp-cloudstorage-001 | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ffcfc277-3c55-4d42-8d9a-f0c2b0b8f2b3.png) **Elige la ubicación de almacenamiento** Elige **dónde almacenar tus datos** de entre las regiones disponibles: almacenamiento regional, doble almacenamiento o almacenamiento multirregional. ![step2-gcp-cloudstorage-002 | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/0a0f422f-ca33-44aa-8471-c548727ce599.png) **Elige la clase de almacenamiento** A continuación, elige la **clase de almacenamiento**. Recomendamos usar la opción "autoclass" de GCP, que transiciona automáticamente cada objeto a la clase Standard o Nearline según la actividad del objeto, optimizando el coste y la latencia. Es la opción recomendada si la frecuencia de uso puede ser impredecible. ![step2-gcp-cloudstorage-003 | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/a32075ce-0e2a-4fc3-a60c-d780c5609783.png) **Define el control de acceso** Define una política de **control de acceso** que debe establecerse como "**Detallado**" (Fine-grained), ya que Applivery definirá políticas de acceso individuales para cada objeto. ![step2-gcp-cloudstorage-004 | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/07b33c35-d1c7-457d-b2b6-36881a2c352b.png) **Configura la protección de datos** En **protección de datos**, recomendamos elegir "**Política de eliminación temporal**" y luego "**Usar duración de retención predeterminada**". Haz clic en el botón **CREAR** para terminar. ![step2-gcp-cloudstorage-005 | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/24a6eb9f-32bd-4654-84bd-590b15f7f5aa.png) #### Actualizar los permisos del bucket **Ve a los permisos del bucket** Ve a **Buckets**, selecciona el bucket recién creado y haz clic en **PERMISOS**. **Concede acceso** Haz clic en **+CONCEDER ACCESO**. ![step3-gcp-cloudstorage-001 | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/6d0aeda2-2578-4e23-8a09-b01e61d98cc6.png) **Asigna el rol Storage Object User** En el panel lateral, busca la cuenta de servicio en "**Nuevas entidades de seguridad**" y asigna el rol "**Storage Object User**". Luego haz clic en **GUARDAR**. ![step3-gcp-cloudstorage-002 | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/10c815a6-1327-4b78-999a-14c2a1bee7ed.png) ### Configurar tu región de almacenamiento personalizada en Applivery **Ve a la configuración de almacenamiento** Una vez completada la configuración de AWS S3 o GCP Cloud Storage, abre el menú desplegable superior y accede a **Ajustes del Workspace** 1 en el [**panel de Applivery**](https://dashboard.applivery.io/). Luego selecciona **Almacenamiento** 2 en el menú lateral izquierdo y haz clic en el botón **\+ Crear proveedor de almacenamiento** 3. ![storage](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/fc462070-7468-4b8d-9459-6087d2211dd0.png) **Completa el formulario** Rellena el formulario con la información generada en los pasos anteriores. Luego haz clic en el botón Guardar. ![create storage provider](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/383de2b9-305a-4574-a9f5-7a258ed9ab2a.png) ### Activar buckets de almacenamiento Puedes cambiar entre regiones de almacenamiento simplemente haciendo clic en el botón Seleccionar junto a cada región de almacenamiento. ### Probar las nuevas configuraciones Puedes usar el icono de bug situado en cada Región de almacenamiento para probar la configuración correcta del bucket. Applivery ejecutará una serie de pruebas que confirmarán si el bucket se ha configurado correctamente. ![step4-gcp-cloudstorage-applivery-002 | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ea2bd444-bb83-482d-a28b-94547dfff94e.png) Una prueba correcta tendrá este aspecto: ![storage check](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/92daa6b6-da1b-4b35-b6cb-2e68fbed4a55.png) ### Deshabilitar una Región de almacenamiento personalizada Puedes deshabilitar una Región de almacenamiento personalizada haciendo clic en el botón **Seleccionar** de la región de almacenamiento por defecto (Irlanda). ### Eliminar una Región de almacenamiento personalizada Puedes eliminar permanentemente una Región de almacenamiento personalizada haciendo clic en el **botón del lápiz** 4 junto a ella y luego en el botón **Eliminar** 5 en la parte inferior del modal. La Región de almacenamiento se eliminará permanentemente del sistema. ![delete storage provider](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/0146cf90-9ae5-460d-a356-ff23a58951da.png) :::info Las Builds cargadas en este almacenamiento dejarán de estar accesibles. ::: --- ## Guía rápida de Markdown Source: https://docs.applivery.com/es/app-distribution/builds/markdown/ Description: Referencia de sintaxis Markdown para Applivery — formatea las notas de publicación y las descripciones de Builds con encabezados, listas, enlaces e imágenes. TL;DR: Esta guía de referencia de Markdown te permite formatear texto usando la sintaxis Markdown en Applivery de forma rápida y sencilla. Answers: ¿Qué es Markdown? · ¿Cómo creo un encabezado en Markdown? · ¿Cómo pongo texto en negrita o cursiva en Markdown? · ¿Cómo creo un enlace en Markdown? · ¿Cómo inserto una imagen en Markdown? · ¿Cómo creo un bloque de código en Markdown? · ¿Cómo creo una tabla en Markdown? · ¿Cómo creo una lista de tareas en Markdown? ## Guía rápida de Markdown Markdown es una sintaxis ligera para formatear texto plano que es fácil de leer y escribir. Applivery admite Markdown en Publicaciones y campos de texto para enriquecer tu contenido sin necesidad de HTML. Para la especificación completa de Markdown, consulta [la especificación original de John Gruber](https://daringfireball.net/projects/markdown/) y la [guía de GitHub-flavored Markdown](https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax). * * * ### Sintaxis básica Estos son los elementos principales admitidos por todas las aplicaciones Markdown. * * * #### Encabezados Usa el símbolo `#` para definir encabezados. El número de `#` corresponde al nivel del encabezado (del 1 al 6). ```markdown ## H1 ### H2 #### H3 ##### H4 ###### H5 ###### H6 ``` * * * #### Énfasis ```markdown Italic text with *asterisks* or _underscores_. Bold text with **asterisks** or __underscores__. Combined bold and italic with **asterisks and _underscores_**. Strikethrough with two tildes: ~~strikethrough~~. ``` **Se renderiza como:** Texto en cursiva con _asteriscos_ o _guiones bajos_. Texto en negrita con **asteriscos** o **guiones bajos**. Negrita y cursiva combinadas con **asteriscos y _guiones bajos_**. Tachado con dos tildes: ~tachado~. * * * #### Líneas horizontales Cualquiera de los siguientes produce una línea divisoria horizontal: ```markdown ___ --- *** ``` * * * #### Listas **Lista ordenada:** ```markdown 1. First item 2. Second item 3. Third item ``` **Lista no ordenada** — asteriscos, guiones y signos más funcionan: ```markdown * Item using asterisk - Item using hyphen + Item using plus ``` **Lista anidada:** ```markdown 1. First ordered item 2. Second ordered item - Unordered sub-item - Another sub-item 3. Third ordered item 1. Ordered sub-item ``` :::info Los números reales en las listas ordenadas no importan — Markdown los renderizará secuencialmente independientemente de los números que uses. `1. 1. 1.` se renderiza como `1. 2. 3.` ::: * * * #### Enlaces ```markdown [Link text](https://www.example.com) [Link text with tooltip](https://www.example.com "Tooltip text") ``` Las URLs sin formato también se convierten automáticamente en enlaces en la mayoría de los renderizadores Markdown: ```markdown https://www.example.com ``` * * * #### Imágenes ```markdown ![Alt text](https://www.example.com/image.png) ![Alt text with tooltip](https://www.example.com/image.png "Tooltip text") ``` El texto alternativo se muestra si la imagen no carga y también lo usan los lectores de pantalla. * * * #### Código **Código inline** — envuelve el texto entre comillas invertidas simples: ```markdown Use the `code` tag for inline snippets. ``` **Bloques de código** — envuelve con tres comillas invertidas. Opcionalmente indica un lenguaje para el resaltado de sintaxis: ````markdown ```javascript const greeting = "Hello, world!"; console.log(greeting); ``` ```python greeting = "Hello, world!" print(greeting) ``` ``` No language specified — no syntax highlighting applied. ``` ```` **Se renderiza como:** ```javascript const greeting = "Hello, world!"; console.log(greeting); ``` ```python greeting = "Hello, world!" print(greeting) ``` ``` No language specified — no syntax highlighting applied. ``` * * * #### Citas en bloque Usa `>` para crear citas en bloque. Se pueden anidar y pueden contener otros elementos Markdown. ```markdown > This is a blockquote. > This line is part of the same quote. > You can use *italic* and **bold** inside a blockquote. > First level >> Nested blockquote ``` **Se renderiza como:** > Esta es una cita en bloque. > Esta línea forma parte de la misma cita. > Puedes usar _cursiva_ y **negrita** dentro de una cita en bloque. > Primer nivel > > > Cita anidada * * * ### Sintaxis extendida Estos elementos amplían la sintaxis básica y están admitidos por la mayoría de los renderizadores Markdown modernos, incluido GitHub-flavored Markdown. * * * #### Tablas Usa pipes `|` y guiones `-` para crear tablas. La segunda fila define la alineación con dos puntos: ```markdown | Left-aligned | Center-aligned | Right-aligned | |:---|:---:|---:| | Cell | Cell | Cell | | Cell | Cell | Cell | ``` **Se renderiza como:** | Alineado a la izquierda | Centrado | Alineado a la derecha | | --- | --- | --- | | Celda | Celda | Celda | | Celda | Celda | Celda | * * * #### Listas de tareas ```markdown - [x] Completed task - [ ] Incomplete task - [ ] Another incomplete task ``` **Se renderiza como:** - Tarea completada - Tarea pendiente - Otra tarea pendiente * * * #### Notas al pie ```markdown Here is a sentence with a footnote.[^1] [^1]: This is the footnote content. ``` * * * #### Escape de caracteres Para mostrar un carácter que de otro modo sería interpretado como formato Markdown, anteponle una barra invertida `\`: ```markdown \*This text is not italicized\* \# This is not a heading ``` Caracteres que se pueden escapar: `\ * _ { } [ ] ( ) # + - . !` * * * ### Referencia rápida | Elemento | Sintaxis | | --- | --- | | Encabezado 1 | `# Heading` | | Encabezado 2 | `## Heading` | | Negrita | `**bold**` | | Cursiva | `*italic*` | | Negrita + cursiva | `***bold italic***` | | Tachado | `~~strikethrough~~` | | Código inline | ``code`` | | Bloque de código | ````language` | | Cita en bloque | `> quote` | | Lista ordenada | `1. item` | | Lista no ordenada | `- item` | | Enlace | `[text](url)` | | Imagen | `![alt](url)` | | Línea horizontal | `---` | | Tabla | `\| col \| col \|` | | Lista de tareas | `- [x] done` | | Escape de carácter | `\*` | --- ## Notificaciones Source: https://docs.applivery.com/es/app-distribution/builds/notifications/ Description: Configura las notificaciones de Builds en Applivery a nivel de usuario, App, Build y Publicación, incluyendo reglas de prioridad y gestión de audiencias. TL;DR: Configura las notificaciones de builds de Applivery a nivel de usuario, app, build y publicación para controlar qué actualizaciones recibes tú y tu equipo. Answers: ¿Cuáles son los niveles de notificaciones de Builds en Applivery? · ¿Qué nivel de notificación tiene prioridad en Applivery? · ¿Cómo configuro las notificaciones a nivel de App? · ¿Cómo configuro notificaciones para una Build específica? · ¿Si una Build tiene notificaciones desactivadas, quién las recibe? Configurar qué grupos de usuarios o audiencias reciben notificaciones al cargar nuevas Builds puede resultar complejo. En Applivery, hay cuatro niveles de configuración de notificaciones: **nivel de usuario**, **nivel de App**, **nivel de Build** y **nivel de Publicación**. ### Ajustes de nivel de usuario Los ajustes de **nivel de usuario** tienen prioridad sobre todos los demás. Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a los **ajustes de tu cuenta** 1 desde el menú desplegable superior, luego abre **Notificaciones** 2 en el menú lateral izquierdo y elige qué notificaciones quieres recibir y gestiónalas por App (usando el botón Gestionar por app) si es necesario. ![user notifications](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/11ccb88f-3c68-41ad-b626-28c2deb785ab.png) :::info Solo los Colaboradores del Workspace pueden configurar estas notificaciones, ya que los Empleados no tienen acceso al panel. Puedes saber más sobre los tipos de usuario de Applivery [aquí](https://docs.applivery.com/es/app-distribution/distribute/manage-users/). ::: ### Ajustes de nivel de App Los ajustes de **nivel de App** tienen la siguiente prioridad y se configuran navegando a **Configuración de la App** > sección **Notificaciones por email**. Esta configuración sirve como ajuste por defecto para notificar a los Colaboradores/empleados cuando se carga una Build en esa App. ![app notification](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/63352e33-d167-4be4-9dbd-725b911e184a.png) ### Ajustes de nivel de Build Simplemente haz clic en el botón **\+ Cargar Build** y, tras seleccionar el archivo a cargar, elige la opción **Modificar ajustes de notificaciones para esta Build**. ![notify build](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/a0fcb1ec-d25c-46f0-a081-624ef97b9d8d.png) Haz clic en el botón Siguiente para configurar los ajustes de notificaciones de esta Build concreta. ![notify users](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/be7aa3d7-bddc-40bf-b78c-e163f81205fb.png) ### Ajustes de nivel de Publicación Los ajustes de **nivel de Publicación** tienen la prioridad más baja, por lo que los ajustes descritos anteriormente tendrán prioridad sobre ellos. ![Publication level notifications](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/8959f3d8-911f-4b7c-b682-cc11623f2bfc.png) En resumen, una vez pasado el nivel de prioridad de la App, se pasa al nivel de Build y, finalmente, al de Publicación, donde se comprueba qué grupos/audiencias deben o no recibir notificaciones. :::info Para saber más sobre la gestión de grupos y audiencias, puedes consultar los siguientes recursos: - [Grupos de distribución](https://docs.applivery.com/es/app-distribution/distribute/user-groups/). - [Gestión de audiencias](https://docs.applivery.com/es/app-distribution/distribute/user-audiences/). ::: ### Consideraciones importantes sobre las notificaciones de audiencias Al configurar las notificaciones para tu audiencia en Applivery, hay que tener en cuenta varias consideraciones clave. Imagina que tienes una App con dos audiencias distintas: _Audiencia 1_ y _Audiencia 2_. Quieres enviar notificaciones sobre nuevas Builds pero necesitas configurar qué audiencia las recibirá. - Tu App tiene las notificaciones habilitadas (nivel de App). - La App tiene una Publicación que apunta a todas las Builds, compartida con ambas audiencias: - _Audiencia 1_ – notificaciones **ACTIVADAS**. - _Audiencia 2_ – notificaciones **DESACTIVADAS**. #### ¿Quién recibirá notificaciones si cargas una nueva Build con notificaciones activadas? Si cargas una Build con notificaciones activadas, la Audiencia 1 las recibirá, ya que las notificaciones están habilitadas a nivel de App, Publicación y Build. Sin embargo, la Audiencia 2 no recibirá ninguna notificación. ![](https://www.applivery.com/wp-content/uploads/2025/04/notification-1024x636.png "notification | Applivery") #### ¿Quién recibirá notificaciones si cargas una nueva Build con notificaciones desactivadas? Si cargas una Build con notificaciones desactivadas a nivel de Build, esto anulará el ajuste a nivel de App (que está activado), y ni la Audiencia 1 ni la Audiencia 2 recibirán notificaciones. Esto se aplica aunque las notificaciones estén activadas para la Audiencia 1 a nivel de Publicación, ya que el ajuste de nivel de Build tiene prioridad. #### ¿Quién recibirá notificaciones si cargas una nueva Build con notificaciones desactivadas a nivel de App pero activadas a nivel de Build? En este caso, la Audiencia 1 seguirá recibiendo la notificación, ya que la configuración de la Build tiene prioridad sobre los ajustes a nivel de App. ![](https://www.applivery.com/wp-content/uploads/2025/04/notification-2-1024x632.png "notification-2 | Applivery") --- ## Códigos de error de procesamiento Source: https://docs.applivery.com/es/app-distribution/builds/processing-error-codes/ Description: Guía de referencia de los códigos de error de procesamiento de Builds de Applivery — diagnostica y resuelve fallos en iOS, Android, macOS, Windows y Homebrew. TL;DR: Esta guía lista los códigos de error de procesamiento de builds de Applivery y ofrece soluciones para los problemas más comunes en iOS, Android y Windows. Answers: ¿Qué significa el código de error IOS_INVALID_PACKAGE en Applivery? · ¿Qué significa el código de error ANDROID_MANIFEST_NOT_FOUND? · ¿Qué significa el código de error ANDROID_AAB_INCORRECT_KEYSTORE_PASSWORD? · ¿Qué significa el código de error PKG_ARCHIVE_OPEN_FAILED? · ¿Qué significa el código de error APPX_MANIFEST_NOT_FOUND? · ¿Qué significa el código de error UNSUPPORTED_FORMAT? · ¿Qué significa el código de error NO_FILES_EXTRACTED_FROM_COMPRESSED_FILE? Cuando se carga una Build en Applivery, pasa por un pipeline de procesamiento automatizado que valida y extrae metadatos del archivo. Si el procesamiento falla, se devuelve uno de los códigos de error que se describen a continuación. Esta referencia lista todos los códigos de error posibles, qué significan y cómo resolverlos. Los códigos están agrupados por plataforma para facilitar la búsqueda. * * * ### iOS | Código | Descripción | Resolución | | --- | --- | --- | | `IOS_INVALID_PACKAGE` | El paquete dentro del archivo `.ipa` no es válido. | Asegúrate de que la app se ha compilado y firmado correctamente, y de que el bundle `.app` dentro del `.ipa` no está dañado. | | `EMBEDDED_MOBILEPROVISION_NOT_FOUND` | El perfil de aprovisionamiento móvil embebido falta y la Build no puede procesarse. | Asegúrate de que la app contiene un archivo de perfil de aprovisionamiento válido embebido en el `.ipa`. | | `PAYLOAD_NOT_FOUND` | El directorio `Payload` no se ha encontrado dentro del `.ipa`. | Verifica que el `.ipa` contiene un directorio `Payload` válido con el bundle `.app` dentro. | * * * ### Android | Código | Descripción | Resolución | | --- | --- | --- | | `ANDROID_MANIFEST_NOT_FOUND` | El archivo `AndroidManifest.xml` falta y la Build no puede procesarse. | Asegúrate de que la app contiene un archivo `AndroidManifest.xml` válido. | | `ANDROID_FAILED_PARSE_BINARY_ANDROID_MANIFEST` | El manifiesto XML de Android no es válido o no está en formato binario. | El APK contiene un manifiesto XML no binario que no puede parsearse. Comprueba el proceso de compilación para asegurarte de que el APK se ha compilado correctamente. | | `ANDROID_AAB_CONFIGURATION_NOT_FOUND` | La configuración del Android App Bundle (AAB) falta o no es válida. | Ve a **App > Configuración > Android App Bundle** y revisa o añade una configuración de AAB válida. | | `ANDROID_AAB_NO_KEY_FOUND_FOR_ALIAS_IN_KEYSTORE` | El alias de la clave de firma no se ha encontrado en el Keystore proporcionado. | Configura la clave de firma de AAB correcta en la **Configuración de Android App Bundle** de tu proyecto. | | `ANDROID_AAB_INCORRECT_KEYSTORE_PASSWORD` | La contraseña de Keystore proporcionada es incorrecta. | Verifica que la contraseña de Keystore configurada en tu **Configuración de Android App Bundle** es correcta. | | `ANDROID_AAB_INCORRECT_KEY_PASSWORD` | La contraseña de la clave de firma proporcionada es incorrecta. | Verifica que la contraseña de la clave de firma configurada en tu **Configuración de Android App Bundle** es correcta. | * * * ### macOS | Código | Descripción | Resolución | | --- | --- | --- | | `PKG_ARCHIVE_OPEN_FAILED` | El paquete dentro del archivo `.pkg` no es válido. | Asegúrate de que la app se ha compilado y firmado correctamente, y de que el paquete `.pkg` no está dañado. | | `NO_BUILD_INSIDE_DMG` | El archivo `.dmg` no contiene una Build válida. | Asegúrate de que el `.dmg` contiene un archivo `.app` o `.pkg` válido para el procesamiento. | * * * ### Windows | Código | Descripción | Resolución | | --- | --- | --- | | `APPX_BUNDLE_MANIFEST_NOT_FOUND` | El archivo `AppxBundleManifest.xml` falta en el paquete `.appxbundle` o `.msixbundle`. | Asegúrate de que tu paquete de app contiene un archivo `AppxBundleManifest.xml` válido. | | `APPX_MANIFEST_NOT_FOUND` | El archivo `AppxManifest.xml` falta en el paquete `.appx` o `.msix`. | Asegúrate de que tu paquete de app contiene un archivo `AppxManifest.xml` válido. | * * * ### Homebrew | Código | Descripción | Resolución | | --- | --- | --- | | `ERROR_ARTIFACT_FROM_HOMEBREW_TOKEN` | No se ha encontrado ningún artefacto con el token de Homebrew proporcionado. | Asegúrate de que tu app está disponible públicamente en Homebrew y de que el token es correcto. | * * * ### Errores generales / de archivo Estos códigos no son específicos de una plataforma concreta y pueden aparecer con cualquier tipo de archivo. | Código | Descripción | Resolución | | --- | --- | --- | | `UNSUPPORTED_FORMAT` | El formato del archivo cargado no está soportado para el procesamiento. | Comprueba los formatos de archivo compatibles y vuelve a cargar en un formato válido. | | `BUILD_TYPE_NOT_FOUND` | No se ha encontrado ningún archivo procesable dentro del paquete cargado. | Asegúrate de que el archivo cargado contiene un artefacto de Build compatible. | | `NO_VALID_FILE_FOUND_FOR_PROCESSING` | No se ha encontrado ningún archivo con una extensión compatible dentro del paquete. | Asegúrate de que el archivo contiene una de las siguientes extensiones: `.pkg`, `.app`, `.exe`, `.msi`, `.appxbundle` o `.msixbundle`. | | `NO_FILES_EXTRACTED_FROM_COMPRESSED_FILE` | El archivo `.zip` no contiene archivos procesables. | Asegúrate de que el `.zip` contiene un archivo de Build válido y que no está vacío ni dañado. | | `{FILE}_CURRENTLY_ONLY_ONE_BUNDLE_SUPPORTED` | El archivo contiene varios elementos del mismo tipo y no puede extraerse. `{FILE}` será uno de: `PKG`, `APP`, `EXE`, `MSI`, `APPXBUNDLE`, `MSIXBUNDLE`. | Asegúrate de que el archivo cargado contiene solo un elemento de cada tipo compatible. | | `UPLOAD_FILE_FAILED` | Se ha producido un error al cargar el archivo en Applivery. | Vuelve a intentar la carga. Si el problema persiste, contacta con el soporte. | | `COPY_FILE_FAILED` | Se ha producido un error al copiar el archivo durante el procesamiento. | Vuelve a intentar la carga. Si el problema persiste, contacta con el soporte. | * * * ### Formatos de archivo compatibles Applivery admite los siguientes formatos de archivo para cargar Builds: | Plataforma | Formatos compatibles | | --- | --- | | **iOS** | `.ipa`. | | **Android** | `.apk`, `.aab`. | | **macOS** | `.pkg`, `.app`, `.dmg`. | | **Windows** | `.exe`, `.msi`, `.appx`, `.msix`, `.appxbundle`, `.msixbundle`. | | **macOS (gestor de paquetes)** | Token de Homebrew. | | **Multiplataforma** | `.zip` con un formato compatible y `.tar.gz`. | --- ## Regiones de almacenamiento Source: https://docs.applivery.com/es/app-distribution/builds/storage-regions/ Description: Configura las regiones de almacenamiento de tus Builds en Applivery para optimizar el rendimiento y cumplir con los requisitos de residencia de datos, por organización o por App. TL;DR: Applivery te permite elegir dónde se almacenan tus builds por región para mejorar el rendimiento y cumplir con los requisitos de datos. Answers: ¿Dónde se almacenan las Builds de Applivery por defecto? · ¿Puedo cambiar la región de almacenamiento por defecto de mis Builds? · ¿Afecta el cambio de región de almacenamiento a las Builds existentes? · ¿Cómo sé en qué región está almacenada una App o Build concreta? :::warning Esta es una funcionalidad premium que puede no estar disponible en tu plan actual. Consulta la disponibilidad en nuestra [página de precios](https://www.applivery.com/pricing/). ::: El almacenamiento de Builds en Applivery está alojado en múltiples ubicaciones en todo el mundo. Estas ubicaciones se organizan en Regiones. Cada Región es un área geográfica independiente que te permite almacenar tus Builds más cerca de tus usuarios finales. Por defecto, todas las Builds y recursos se almacenan en la región `eu-west-1` Europa (Irlanda), pero los administradores de la cuenta podrán personalizar esta configuración en los siguientes niveles: - Definir una Región de almacenamiento por defecto para toda la organización. - Definir una Región de almacenamiento para una App específica. :::info Cambiar la Región de almacenamiento por defecto de la organización o de una App no afectará a las Builds ya almacenadas. Solo afectará a las nuevas Builds que se carguen. ::: Puedes saber en qué región está ubicada una App yendo a la sección **Ajustes > Avanzado** de la **App**, en el apartado **Proveedor de almacenamiento**. ![storage provider app](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/43981f8e-9229-47e9-b6b0-9c8c47b02dae.png) También puedes comprobar en qué región está almacenada una Build concreta haciendo clic en ella y revisando la sección **Proveedor de almacenamiento**. ![build storage](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/44325140-6140-4341-b679-65161532210c.png) ### Regiones disponibles La siguiente tabla y mapa listan las Regiones proporcionadas por Applivery que puedes seleccionar para tus organizaciones y Apps. Si estás en un plan Enterprise, puedes configurar tus propios Buckets de **AWS S3** o **GCP Cloud Storage**. Para configurarlos, sigue [Regiones de almacenamiento personalizadas](https://docs.applivery.com/es/app-distribution/builds/custom-storage-regions/). --- ## CI/CD Source: https://docs.applivery.com/es/app-distribution/ci-cd/ Description: Integraciones CI/CD para Applivery: automatiza la subida de Builds con Jenkins, Bitrise, Fastlane, Azure DevOps, GitHub Actions y App Live. Answers: ¿Qué es CI/CD? · ¿Con qué herramientas se integra Applivery para CI/CD? · ¿Cómo se automatiza la subida de Builds con Applivery? Applivery se integra con tu pipeline CI/CD existente para que cada Build exitosa pueda subirse y distribuirse automáticamente sin intervención manual. Es compatible con Jenkins, Bitrise, Fastlane, Azure DevOps, GitHub Actions y flujos de trabajo de App Live. Configura cada integración, usa los parámetros adecuados y automatiza las notificaciones para que tu equipo esté siempre al tanto cuando haya una nueva Build disponible. --- ## App Live Source: https://docs.applivery.com/es/app-distribution/ci-cd/app-live/ Description: Integra Applivery con App Live de BrowserStack para probar Apps móviles en dispositivos reales. Conecta tu Workspace y sincroniza versiones automáticamente. TL;DR: Integra Applivery con BrowserStack App Live para probar tus apps móviles en dispositivos reales sin subir manualmente APKs ni IPAs. Answers: ¿Cómo conecto Applivery con BrowserStack App Live? · ¿Qué necesito para integrar Applivery con App Live? · ¿Cómo sincronizo una versión de App con BrowserStack? · ¿Cómo desconecto mi Workspace de Applivery de App Live? [App Live](https://www.browserstack.com/app-live) es la plataforma de pruebas en dispositivos reales de BrowserStack. Permite a desarrolladores y equipos de QA ejecutar Apps móviles en dispositivos iOS y Android reales alojados en la nube, sin necesidad de un laboratorio físico de dispositivos. Puedes interactuar con las Apps tal como lo haría un usuario final, probarlas en cientos de combinaciones de dispositivo y sistema operativo, y depurar problemas en tiempo real. La integración de Applivery con App Live te permite conectar tu Workspace de Applivery directamente al panel de App Live. Una vez conectado, todas tus Apps y Builds estarán disponibles para pruebas en BrowserStack sin necesidad de subir archivos manualmente: selecciona una App, elige un dispositivo y comienza una sesión en vivo. * * * ### Requisitos previos Antes de configurar la integración, asegúrate de tener: - Una cuenta de [BrowserStack](https://www.browserstack.com/users/sign_up) con acceso a App Live. Si aún no tienes una, dispones de una prueba gratuita. - Una **cuenta de servicio de Applivery** y su **Bearer token** correspondiente. App Live usa estas credenciales para autenticarse contra tu Workspace de Applivery. Consulta [Cuentas de servicio](https://docs.applivery.com/es/platform/api/service-accounts/) para instrucciones sobre cómo crearla. ![Service Accounts](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/033d5048-3647-421d-8250-f9efb46824d9.png) * * * ### Conectar tu Workspace de Applivery a App Live Una vez en el [panel de App Live](https://app-live.browserstack.com/), en el panel **Select Source** 1, haz clic en **Integrate with Applivery** 2. Introduce el **Bearer token** 3 de tu Service Account de Applivery y haz clic en **Connect Workspace** 4. ![app live integration](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/71f82b67-a4ee-4624-ad91-e5f1a68eca34.png) Una vez autenticado, serás redirigido al panel de App Live con tu Workspace de Applivery conectado. Tus Apps y proyectos estarán ahora disponibles en el panel **Select Source**. ![successful integration](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/176a33a6-dfef-41f4-8b7c-d41f799d975a.png) * * * ### Explorar Apps y versiones App Live organiza tus datos de Applivery en una jerarquía de tres niveles: ``` Project → Apps → Releases ``` - Los **Projects** corresponden a tus Apps de Applivery. La lista incluye tanto los proyectos que has añadido tú mismo como los que tus compañeros han compartido contigo. - Las **Apps** dentro de cada project muestran todas las aplicaciones asociadas. - Las **Releases** muestran todas las Builds disponibles para pruebas dentro de una App concreta. Selecciona un project, luego una App y después una release para acceder a los dispositivos disponibles y comenzar una sesión de prueba. ![project app releases](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/8d9bde57-5f32-4c5d-aecc-3408f3f1d275.png) * * * ### Compartir proyectos con tu equipo Una vez que hayas añadido un project, puedes compartirlo con tu equipo. Los proyectos compartidos aparecen en los paneles de App Live de tus compañeros, bajo la misma lista de proyectos. :::info Solo puedes compartir proyectos que hayas añadido tú mismo. Los proyectos que otros te hayan compartido no se pueden volver a compartir. ::: En la lista de proyectos, haz clic en el icono **⋮** 5 (más opciones) junto al nombre del proyecto, selecciona **Share** 6 y confirma haciendo clic en **Share** 7 en el cuadro de diálogo. ![share project](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/cee3849b-6563-431f-8591-dca5a8273d22.png) El proyecto ya estará disponible para tus compañeros en sus vistas de App Live. * * * ### Sincronizar versiones de App con BrowserStack Sincronizar una versión de App la sube a BrowserStack Cloud, lo que la hace disponible para sesiones en vivo y desbloquea opciones de configuración avanzadas, como soporte para apps de gran tamaño e inyección de vídeo. Las configuraciones aplicadas tras la sincronización son persistentes para esa versión. #### Sincronizar una versión 1. Selecciona el project y la app que quieres sincronizar. 2. Haz clic en el **icono de sincronización** 8 junto al nombre de la App. 3. Espera a que el proceso finalice. El icono de sincronización cambia a un botón de desincronización cuando termina, y las opciones de configuración quedan disponibles. ![sync app release](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/1cf7f194-2718-418f-8a6a-3e29c98afb45.png) #### Desincronizar una versión Desincronizar elimina la versión de BrowserStack Cloud. Tras desincronizar, la App dejará de estar disponible para pruebas en App Live y no se podrán aplicar configuraciones. 1. En la lista de Apps, haz clic en el **icono de desincronización** 9 junto al nombre de la App. 2. La versión se elimina de BrowserStack Cloud. ![unsync app release](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/d139519d-9a71-4598-bc40-367f579dfb96.png) * * * ### Iniciar una sesión de App Live 1. Abre el panel de App Live y selecciona un project de la lista. 2. Elige la App que quieres probar. 3. Selecciona una release. La versión más reciente se sincroniza automáticamente para garantizar que estás probando la Build más reciente. 4. Elige un dispositivo de las opciones disponibles. 5. La sesión se inicia con la App y el dispositivo seleccionados. ![launching app live session](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ca55ecef-4221-4b9e-a78b-ae3c82e4286f.png) * * * ### Gestionar proyectos #### Añadir un proyecto Haz clic en el icono **+** 10 junto a la lista de proyectos en el panel de App Live y sigue el flujo de integración de Applivery. #### Actualizar un proyecto 1. Selecciona el proyecto de la lista. 2. Haz clic en el icono **⋮** 11 y elige **Refresh** 12. Esto obtiene las Apps y versiones más recientes de tu Workspace de Applivery. #### Eliminar un proyecto 1. Selecciona el proyecto. 2. Haz clic en **⋮** y elige **Delete** 13. 3. Confirma la eliminación. El proyecto se elimina de tu vista de App Live. Los proyectos compartidos por otras personas no se ven afectados. ![project actions](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/a0ee3e55-439a-46e9-95fc-11b02e0fe855.png) #### Desconectar tu Workspace de Applivery Para eliminar todos los proyectos que hayas añadido personalmente y desconectar tu Workspace de Applivery de App Live: 1. Ve a la página de **Integrations** de App Live. 2. Encuentra el mosaico de Applivery y haz clic en **Disconnect**. Esto elimina todos los proyectos que hayas añadido. Los proyectos compartidos por tus compañeros no se ven afectados. --- ## Azure Pipelines Source: https://docs.applivery.com/es/app-distribution/ci-cd/azure-pipelines/ Description: Integra Applivery con Azure Pipelines para automatizar la distribución de Apps móviles usando Fastlane o la API de Applivery. TL;DR: Integra Applivery con Azure Pipelines para automatizar la distribución de apps móviles usando Fastlane o la CLI de Applivery. Answers: ¿Cómo integro Applivery con Azure Pipelines? · ¿Cómo guardo el token de Applivery de forma segura en Azure Pipelines? · ¿Qué variables predefinidas de Azure Pipelines puedo usar con Applivery? · ¿Cómo subo Builds a Applivery desde Azure Pipelines sin Fastlane? ![azure-pipelines-long](https://www.applivery.com/wp-content/uploads/2021/12/azure-pipelines-long-1024x307.png "azure-pipelines-long | Applivery") [Azure DevOps](https://azure.microsoft.com/en-us/services/devops/) es una plataforma de Microsoft que cubre el ciclo de vida completo de las aplicaciones: control de versiones, gestión de proyectos, compilaciones automatizadas, pruebas y gestión de releases. [Azure Pipelines](https://azure.microsoft.com/en-us/services/devops/pipelines/), parte del conjunto de Azure DevOps, proporciona pipelines CI/CD alojados en la nube para Linux, macOS y Windows, con soporte para aplicaciones web, de escritorio y móviles. La integración de Applivery con Azure Pipelines te permite subir automáticamente nuevas Builds a Applivery al final de cada ejecución del pipeline, haciéndolas inmediatamente disponibles para los equipos de QA, las partes interesadas o los usuarios internos. Hay dos enfoques para integrar Azure Pipelines con Applivery: - **Mediante Fastlane** (recomendado para proyectos iOS y Android que ya usan Fastlane) — delega la subida al plugin de Applivery para Fastlane. - **Mediante la API de subida de Applivery directamente** (recomendado para cualquier proyecto o cuando no se usa Fastlane) — llama a la API con un paso `curl` en tu pipeline YAML. --- ### Requisitos previos Antes de configurar cualquiera de los dos enfoques, asegúrate de tener: - Una cuenta de Azure DevOps con una configuración de Azure Pipelines en marcha. - Un App API Token de Applivery. Encuéntralo en **Ajustes de la App → Token API** en el panel de Applivery, o consulta [Apps API Authentication](https://docs.applivery.com/es/app-distribution/api/app-api-token/). - Un pipeline que genere un artefacto de Build (`.ipa`, `.apk`, `.aab` u otro formato compatible). --- **Guardar el App Token como variable secreta** Nunca escribas tu token de Applivery directamente en `azure-pipelines.yml`. Guárdalo como variable secreta del pipeline en Azure DevOps para que quede enmascarado en los logs y no se incluya en el repositorio. 1. Abre tu proyecto de Azure DevOps y ve a **Pipelines → tu pipeline → Edit**. 2. Haz clic en **Variables** (arriba a la derecha). 3. Añade una nueva variable llamada `APPLIVERY_TOKEN`. 4. Pega tu App API Token de Applivery como valor. 5. Activa el interruptor **Keep this value secret** para enmascararlo en los logs. 6. Guarda. ![azure-devops-pipelines-vars](https://www.applivery.com/wp-content/uploads/2021/12/azure-devops-pipelines-vars-1024x559.png "azure-devops-pipelines-vars | Applivery") Una vez definida, referénciala en tu pipeline YAML como `$(APPLIVERY_TOKEN)`. **Opción A — Integración mediante Fastlane** Este es el enfoque recomendado si tu proyecto ya usa Fastlane para compilar y firmar. El plugin de Applivery para Fastlane gestiona la subida y todos los metadatos automáticamente. Para la documentación completa del plugin de Fastlane, consulta [Integración con Fastlane](https://docs.applivery.com/es/app-distribution/ci-cd/fastlane/). #### Pipeline YAML En tu `azure-pipelines.yml`, añade un paso de script que invoque tu lane de Fastlane y pase el token como parámetro: ```yaml - script: fastlane dev_deploy applivery_token:$(APPLIVERY_TOKEN) displayName: 'Desplegar en Applivery mediante Fastlane' env: APPLIVERY_TOKEN: $(APPLIVERY_TOKEN) ``` #### Fastfile Define un lane en tu `Fastfile` que compile y suba a Applivery. El ejemplo siguiente usa `last_git_commit[:message]` como changelog y `number_of_commits` para incrementar el número de Build automáticamente: ```ruby desc "Compilar y desplegar en Applivery" lane :dev_deploy do |options| increment_build_number( build_number: number_of_commits ) build_app( scheme: "MyApp-Dev", export_method: "enterprise" ) applivery( app_token: options[:applivery_token], notify_collaborators: true, changelog: last_git_commit[:message] ) end ``` :::tip Puedes ampliar la acción `applivery` con opciones adicionales como `tags`, `notify_message` y `notify_language`. Consulta la documentación de [integración con Fastlane](https://docs.applivery.com/es/app-distribution/ci-cd/fastlane/) para ver todos los parámetros disponibles. ::: **Opción B — Integración mediante la API de subida (sin Fastlane)** Si no usas Fastlane, o prefieres una configuración más sencilla sin dependencias adicionales, llama directamente a la API de subida de Applivery desde tu pipeline usando `curl`. Funciona para cualquier plataforma y agente de pipeline. #### Pipeline YAML — Ejemplo iOS ```yaml trigger: - main pool: vmImage: 'macos-latest' stages: - stage: Build jobs: - job: BuildAndUpload steps: - checkout: self - task: Xcode@5 displayName: 'Compilar app iOS' inputs: actions: 'build' scheme: 'MyApp' sdk: 'iphoneos' configuration: 'Release' xcWorkspacePath: 'MyApp.xcworkspace' packageApp: true signingOption: 'default' - script: | curl 'https://upload.applivery.io/v1/integrations/builds' \ --retry 5 \ --fail \ -H "Authorization: Bearer $(APPLIVERY_TOKEN)" \ -F "build=@$(Build.ArtifactStagingDirectory)/MyApp.ipa" \ -F "versionName=$(Build.BuildNumber)" \ -F "changelog=$(Build.SourceVersionMessage)" \ -F "tags=azure-pipelines, ios" \ -F "notifyCollaborators=true" \ -F "notifyMessage=Nueva Build disponible desde Azure Pipelines" \ -F "notifyLanguage=es" \ -F "deployer.name=Azure Pipelines" \ -F "deployer.info.commit=$(Build.SourceVersion)" \ -F "deployer.info.branch=$(Build.SourceBranchName)" \ -F "deployer.info.commitMessage=$(Build.SourceVersionMessage)" \ -F "deployer.info.buildUrl=$(System.TeamFoundationCollectionUri)$(System.TeamProject)/_build/results?buildId=$(Build.BuildId)" \ -F "deployer.info.buildNumber=$(Build.BuildNumber)" \ -F "deployer.info.repositoryUrl=$(Build.Repository.Uri)" displayName: 'Subir a Applivery' env: APPLIVERY_TOKEN: $(APPLIVERY_TOKEN) ``` #### Pipeline YAML — Ejemplo Android ```yaml trigger: - main pool: vmImage: 'ubuntu-latest' stages: - stage: Build jobs: - job: BuildAndUpload steps: - checkout: self - task: Gradle@3 displayName: 'Compilar APK de Android' inputs: workingDirectory: '' gradleWrapperFile: 'gradlew' gradleOptions: '-Xmx3072m' tasks: 'assembleRelease' - script: | curl 'https://upload.applivery.io/v1/integrations/builds' \ --retry 5 \ --fail \ -H "Authorization: Bearer $(APPLIVERY_TOKEN)" \ -F "build=@$(Build.ArtifactStagingDirectory)/app-release.apk" \ -F "versionName=$(Build.BuildNumber)" \ -F "changelog=$(Build.SourceVersionMessage)" \ -F "tags=azure-pipelines, android" \ -F "notifyCollaborators=true" \ -F "notifyMessage=Nueva Build de Android desde Azure Pipelines" \ -F "notifyLanguage=es" \ -F "deployer.name=Azure Pipelines" \ -F "deployer.info.commit=$(Build.SourceVersion)" \ -F "deployer.info.branch=$(Build.SourceBranchName)" \ -F "deployer.info.commitMessage=$(Build.SourceVersionMessage)" \ -F "deployer.info.buildUrl=$(System.TeamFoundationCollectionUri)$(System.TeamProject)/_build/results?buildId=$(Build.BuildId)" \ -F "deployer.info.buildNumber=$(Build.BuildNumber)" \ -F "deployer.info.repositoryUrl=$(Build.Repository.Uri)" displayName: 'Subir a Applivery' env: APPLIVERY_TOKEN: $(APPLIVERY_TOKEN) ``` --- ### Variables predefinidas de Azure Pipelines Los ejemplos de pipeline anteriores usan variables predefinidas de Azure Pipelines, disponibles automáticamente en cualquier pipeline sin configuración adicional: | Variable | Descripción | |---|---| | `Build.BuildNumber` | El número de Build. Útil como `versionName` en Applivery. | | `Build.BuildId` | ID numérico único para la ejecución de la Build. Se usa para construir la URL de la Build. | | `Build.SourceVersion` | SHA completo del commit de Git que desencadenó la Build. | | `Build.SourceBranchName` | Nombre de la rama que desencadenó la Build. Por ejemplo: `main`, `develop`. | | `Build.SourceVersionMessage` | Mensaje del commit que desencadenó la Build. Útil como `changelog`. | | `Build.Repository.Uri` | URL del repositorio de origen. | | `Build.ArtifactStagingDirectory` | Directorio local donde se guardan los artefactos de compilación. | | `System.TeamFoundationCollectionUri` | URL base de tu organización de Azure DevOps. | | `System.TeamProject` | Nombre del proyecto de Azure DevOps. | Para la lista completa de variables predefinidas, consulta la [documentación de variables predefinidas de Azure Pipelines](https://docs.microsoft.com/en-us/azure/devops/pipelines/build/variables). --- ### Referencia de parámetros de subida Los campos del formulario `curl` se corresponden directamente con los parámetros de la API de subida de Applivery. Los más utilizados: | Parámetro | Descripción | |---|---| | `build` | El archivo binario a subir. | | `versionName` | Etiqueta legible para la Build. Usar `$(Build.BuildNumber)` la vincula con la ejecución de Azure. | | `changelog` | Notas de la versión mostradas en el panel y en los emails de notificación. | | `tags` | Etiquetas separadas por comas para filtrar Builds. | | `notifyCollaborators` | Establece como `true` para enviar un email a los Colaboradores de la App al subir. | | `notifyMessage` | Mensaje personalizado incluido en el email de notificación. | | `deployer.name` | Nombre de la plataforma CI mostrado en el panel de Applivery. | | `deployer.info.commit` | SHA del commit de Git. | | `deployer.info.branch` | Nombre de la rama de Git. | | `deployer.info.buildNumber` | Número de Build del pipeline. | | `deployer.info.buildUrl` | URL directa a la ejecución del pipeline de Azure. | Para la referencia completa de parámetros, consulta [POST – Subir una Build](https://docs.applivery.com/es/app-distribution/api/builds/upload-build/). --- ## Bitrise Source: https://docs.applivery.com/es/app-distribution/ci-cd/bitrise/ Description: Integra Applivery con Bitrise CI/CD para automatizar la compilación, las pruebas y el despliegue de Apps móviles. TL;DR: Integra Applivery con Bitrise para automatizar el despliegue de apps móviles usando el Applivery Step en tu flujo de trabajo. Answers: ¿Qué es Bitrise? · ¿Cómo integro Applivery con Bitrise? · ¿Dónde añado el Applivery Step en Bitrise? · ¿Cómo guardo el token de Applivery de forma segura en Bitrise? ![bitrise](https://www.applivery.com/wp-content/uploads/2021/12/bitrise-1024x335.png "bitrise | Applivery") [Bitrise](https://www.bitrise.io/) es una plataforma CI/CD orientada a móviles, diseñada específicamente para el desarrollo de apps iOS y Android. Utiliza **Workflows** —secuencias de pasos configurables— para automatizar la compilación, las pruebas, la firma y el despliegue de Apps. Applivery tiene un **Applivery Step** oficial en la biblioteca de steps de Bitrise. Al añadirlo a tu workflow, el binario compilado se sube automáticamente a Applivery tras cada Build exitosa, con los metadatos de CI completos (rama, commit, número de Build). --- ### Requisitos previos Antes de configurar la integración, asegúrate de tener: - Una cuenta en [Bitrise.io](https://www.bitrise.io/) con una App ya conectada a tu repositorio (GitHub, GitLab o Bitbucket). - Un App API Token de Applivery. Encuéntralo en **Ajustes de la App → Token API** en el panel de Applivery, o consulta [Apps API Token](https://docs.applivery.com/es/app-distribution/api/app-api-token/). --- **Guardar el App Token como Secret de Bitrise** No pegues el token directamente en un campo de entrada del Step: quedaría visible en la configuración del workflow. Guárdalo como Secret para que esté enmascarado en los logs e inyectado como variable de entorno. 1. Abre tu app en Bitrise y dirígete a la pestaña **Secrets** (navegación superior). 2. Haz clic en **Add new**. 3. Establece la clave como `APPLIVERY_APP_TOKEN`. 4. Pega tu App API Token de Applivery como valor. 5. Activa **Protected** para evitar que el valor quede expuesto en los logs de Build. 6. Haz clic en **Save**. Una vez guardado, puedes referenciarlo en cualquier parte de tu workflow como `$APPLIVERY_APP_TOKEN`. **Añadir el Applivery Step a tu workflow** 1. Abre tu app en Bitrise y dirígete a la pestaña **Workflows**. 2. Selecciona el workflow donde quieres añadir el despliegue de Applivery (normalmente el workflow principal, por ejemplo `primary` o `deploy`). 3. Haz clic en el botón **+** en el punto del workflow donde quieres añadir el Step: colócalo **después** de los pasos de compilación y firma (por ejemplo, después de `Xcode Archive & Export for iOS` o `Android Build`). 4. En el cuadro de búsqueda de Steps, escribe **Applivery**. 5. Selecciona el step **Deploy to Applivery** de los resultados y haz clic en **Add**. **Configurar el Applivery Step** Con el Step añadido a tu workflow, haz clic en él para abrir su panel de configuración. Rellena los siguientes campos: **Obligatorio** | Campo | Valor | |---|---| | **App Token** | `$APPLIVERY_APP_TOKEN` (referencia al Secret creado en el Paso 1) | **Opcional** | Campo | Descripción | |---|---| | **Build name** | Etiqueta legible para la Build. Puedes usar variables de Bitrise como `$BITRISE_BUILD_NUMBER` o `$GIT_CLONE_COMMIT_MESSAGE_SUBJECT`. | | **Changelog** | Notas de la versión de esta Build. Usa `$GIT_CLONE_COMMIT_MESSAGE_BODY` para incluir el mensaje de commit automáticamente. | | **Tags** | Etiquetas separadas por comas para identificar la Build en Applivery. Por ejemplo: `bitrise, staging`. | | **Notify Collaborators** | Establece como `true` para enviar una notificación por email a los Colaboradores de la App tras la subida. | | **Notify Employees** | Establece como `true` para enviar una notificación por email a los empleados de la tienda. | | **Notify Message** | Mensaje personalizado para incluir en el email de notificación. | | **Build path** | Ruta del binario a subir. Si se deja vacío, el Step usa automáticamente la salida del paso de compilación anterior (`$BITRISE_IPA_PATH` para iOS o `$BITRISE_APK_PATH` para Android). | **Ejecutar tu workflow** Lanza una Build manualmente para verificar la integración: 1. En tu app de Bitrise, haz clic en **Start/Schedule a Build**. 2. Selecciona el workflow que configuraste. 3. Haz clic en **Start Build**. Una vez completada la Build, el Applivery Step subirá el binario a tu app de Applivery. Abre el panel de Applivery para confirmar que la Build aparece con los metadatos correctos. --- ### Variables de entorno de Bitrise El Applivery Step captura automáticamente los metadatos de CI de Bitrise. También puedes referenciar estas variables explícitamente en los campos de entrada del Step: | Variable | Descripción | |---|---| | `$BITRISE_BUILD_NUMBER` | Número de Build secuencial asignado por Bitrise. | | `$BITRISE_BUILD_URL` | URL directa a la Build actual en el panel de Bitrise. | | `$BITRISE_GIT_BRANCH` | Rama de Git que desencadenó la Build. | | `$BITRISE_GIT_COMMIT` | SHA del commit de Git que desencadenó la Build. | | `$BITRISE_GIT_TAG` | Tag de Git, si la Build fue desencadenada por un push de tag. | | `$GIT_CLONE_COMMIT_MESSAGE_SUBJECT` | Primera línea del mensaje de commit. | | `$GIT_CLONE_COMMIT_MESSAGE_BODY` | Cuerpo completo del mensaje de commit. | | `$BITRISE_IPA_PATH` | Ruta al archivo `.ipa` exportado (Builds iOS). | | `$BITRISE_APK_PATH` | Ruta al archivo `.apk` generado (Builds Android). | Para la lista completa de variables de entorno de Bitrise, consulta la [documentación del CLI de Bitrise](https://devcenter.bitrise.io/en/references/available-environment-variables.html). --- ### Usar Fastlane con Bitrise Si tu proyecto ya usa Fastlane, puedes combinar Bitrise con el plugin de Applivery para Fastlane en lugar de usar el Applivery Step dedicado. Añade un Step de **Fastlane** a tu workflow e invoca el lane que llama a la acción `applivery`: ``` Step: Fastlane Lane: ios deploy ``` En esta configuración, pasa el token a través de un Secret de Bitrise referenciado como `$APPLIVERY_APP_TOKEN` y léelo en tu `Fastfile` como `ENV["APPLIVERY_APP_TOKEN"]`. Consulta la guía de [integración con Fastlane](https://docs.applivery.com/es/app-distribution/ci-cd/fastlane/) para la configuración completa del Fastfile. --- ## Fastlane Source: https://docs.applivery.com/es/app-distribution/ci-cd/fastlane/ Description: Automatiza el lanzamiento de apps iOS y Android con Fastlane y el plugin de Applivery. Simplifica la compilación, las pruebas y la distribución. TL;DR: Automatiza el lanzamiento de tus apps iOS y Android a Applivery usando el plugin de Fastlane, simplificando el proceso de distribución. Answers: ¿Qué es el plugin de Applivery para Fastlane? · ¿Cómo instalo el plugin de Applivery para Fastlane? · ¿Cuál es el parámetro obligatorio del plugin? · ¿Cómo guardo el token de Applivery de forma segura? ![fastlane](https://www.applivery.com/wp-content/uploads/2021/12/fastlane.png "fastlane | Applivery") [Fastlane](https://fastlane.tools/) es una herramienta de automatización de código abierto para desarrolladores de iOS y Android que gestiona la compilación, las pruebas, la firma de código y la publicación de Apps. El [plugin de Applivery para Fastlane](https://github.com/fastlane-community/fastlane-plugin-applivery) extiende Fastlane con una acción `applivery` que sube el binario compilado a Applivery, adjunta metadatos de CI (commit, rama, tag, URL del repositorio) y envía notificaciones opcionales, todo en un solo paso. --- ### Requisitos previos - [Fastlane instalado](https://docs.fastlane.tools/#getting-started) en tu sistema o agente de CI. - Un App API Token de Applivery. Encuéntralo en **Ajustes de la App → Token API** en el panel de Applivery, o consulta [Apps API Token](https://docs.applivery.com/es/app-distribution/api/app-api-token/). - Un `Fastfile` en tu proyecto con al menos un lane definido. --- **Instalar el plugin** En el directorio de tu proyecto, ejecuta: ```bash fastlane add_plugin applivery ``` Esto añade el plugin a tu `Pluginfile` y lo instala. Haz commit del `Pluginfile` y el `Gemfile.lock` actualizados en tu repositorio para que el plugin esté disponible automáticamente en CI. **Configurar tu Fastfile** Añade una acción `applivery` a cualquier lane de tu `Fastfile`. El único parámetro obligatorio es `app_token`. El resto son opcionales. #### Ejemplo iOS ```ruby platform :ios do lane :deploy do # Compilar la app gym( scheme: "MyApp", export_method: "enterprise" # o "ad-hoc" ) # Subir a Applivery applivery( app_token: ENV["APPLIVERY_TOKEN"], name: "v#{get_version_number} (#{last_git_commit[:abbreviated_commit_hash]})", changelog: last_git_commit[:message], notify_collaborators: true, notify_message: "Nueva Build lista para pruebas", tags: "ios, staging" ) puts "Build subida. ID: #{lane_context[SharedValues::APPLIVERY_BUILD_ID]}" end end ``` #### Ejemplo Android ```ruby platform :android do lane :deploy do # Compilar el APK gradle(task: "assembleRelease") # Subir a Applivery applivery( app_token: ENV["APPLIVERY_TOKEN"], name: "v#{android_get_version_name}", changelog: last_git_commit[:message], notify_collaborators: true, notify_message: "Nueva Build de Android disponible", tags: "android, staging" ) end end ``` #### Ejecutar el lane ```bash fastlane ios deploy fastlane android deploy ``` ### Parámetros del plugin | Parámetro | Tipo | Obligatorio | Descripción | |---|---|---|---| | `app_token` | String | **Sí** | Tu App API Token de Applivery. Disponible en **Ajustes de la App → Token API**. | | `name` | String | No | Nombre legible de la Build mostrado en el panel de Applivery. Por ejemplo: `RC 1.0`, `v2.4.0-beta`. | | `changelog` | String | No | Notas de la versión o descripción de los cambios de esta Build. | | `notify_collaborators` | Boolean | No | Envía una notificación por email a los Colaboradores de la App tras la subida. Por defecto: `false`. | | `notify_employees` | Boolean | No | Envía una notificación por email a los empleados de la tienda tras la subida. Por defecto: `false`. | | `notify_message` | String | No | Mensaje personalizado incluido en el email de notificación. | | `tags` | String | No | Etiquetas separadas por comas para identificar la Build. Por ejemplo: `"staging, sprint-42"`. | | `filter` | String | No | Filtro de grupo para notificaciones. Separado por comas para AND, por barra vertical para OR. Por ejemplo: `"group1,group2\|group3"` significa (group1 AND group2) OR (group3). | | `build_path` | String | No | Ruta explícita al binario a subir. Por defecto usa la ruta generada por `gym()` (iOS) o `gradle()` (Android). | --- ### Valores compartidos Tras una subida exitosa, el plugin expone el ID de Build resultante como valor compartido de Fastlane. Puedes usarlo en pasos posteriores del lane, por ejemplo para desencadenar automatizaciones adicionales, actualizar una Publicación o registrar el resultado. ```ruby applivery( app_token: ENV["APPLIVERY_TOKEN"] ) build_id = lane_context[SharedValues::APPLIVERY_BUILD_ID] puts "ID de Build subida: #{build_id}" ``` --- ### Guardar el token de forma segura Nunca escribas tu App Token directamente en el `Fastfile`. Usa una de estas opciones según tu configuración: **Variable de entorno (recomendado para CI):** ```ruby applivery( app_token: ENV["APPLIVERY_TOKEN"] ) ``` Define `APPLIVERY_TOKEN` como variable de entorno secreta en tu plataforma de CI (Bitrise, Azure Pipelines, GitHub Actions, Jenkins, etc.). **Archivo `.env` de Fastlane (recomendado para desarrollo local):** Crea un archivo `.env` en tu directorio `fastlane/` (añádelo a `.gitignore`): ``` APPLIVERY_TOKEN=tu_token_aquí ``` Fastlane carga los archivos `.env` automáticamente. Referencia la variable de la misma forma: `ENV["APPLIVERY_TOKEN"]`. --- ### Ejemplo completo de Fastfile Un `Fastfile` real con lanes de despliegue separados para iOS y Android, usando metadatos de Git para el changelog y el nombre de la Build: ```ruby ## fastlane/Fastfile default_platform(:ios) platform :ios do desc "Compilar y desplegar en Applivery" lane :deploy do increment_build_number(build_number: number_of_commits) gym( scheme: "MyApp-Staging", export_method: "enterprise", output_directory: "./build", output_name: "MyApp.ipa" ) applivery( app_token: ENV["APPLIVERY_TOKEN"], name: "#{get_version_number} (#{last_git_commit[:abbreviated_commit_hash]})", changelog: last_git_commit[:message], notify_collaborators: true, notify_message: "Nueva Build de iOS — #{git_branch}", tags: "ios, #{git_branch}" ) puts "✅ Subida a Applivery. ID de Build: #{lane_context[SharedValues::APPLIVERY_BUILD_ID]}" end end platform :android do desc "Compilar y desplegar en Applivery" lane :deploy do gradle( task: "assemble", build_type: "Release" ) applivery( app_token: ENV["APPLIVERY_TOKEN"], name: "#{android_get_version_name} (#{last_git_commit[:abbreviated_commit_hash]})", changelog: last_git_commit[:message], notify_collaborators: true, notify_message: "Nueva Build de Android — #{git_branch}", tags: "android, #{git_branch}" ) puts "✅ Subida a Applivery. ID de Build: #{lane_context[SharedValues::APPLIVERY_BUILD_ID]}" end end ``` --- ## GitHub Actions Source: https://docs.applivery.com/es/app-distribution/ci-cd/github-actions/ Description: Integra Applivery con GitHub Actions para automatizar la distribución de apps móviles. TL;DR: Automatiza la distribución de tus apps móviles a Applivery usando GitHub Actions, simplificando el proceso de despliegue. Answers: ¿Cómo integro Applivery con GitHub Actions? · ¿Cómo guardo mi token de Applivery de forma segura en GitHub Actions? · ¿Cómo disparo la subida a Applivery solo en Builds de release? · ¿Qué variables de contexto de GitHub Actions puedo usar con Applivery? ![github](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/66677e61-987d-457e-aaa9-3e410e59b73f.png) [GitHub Actions](https://github.com/features/actions) es la plataforma CI/CD integrada de GitHub. Los pipelines se definen como workflows YAML almacenados directamente en tu repositorio bajo `.github/workflows/`, y se disparan por eventos como pushes, pull requests o ejecuciones manuales. La integración de Applivery con GitHub Actions te permite subir automáticamente una nueva Build a Applivery al final de cada ejecución del workflow, haciendo que los binarios recién compilados estén inmediatamente disponibles para los equipos de QA, las partes interesadas o los usuarios internos sin ningún paso manual. Hay dos enfoques para integrar GitHub Actions con Applivery: - **Mediante Fastlane** — recomendado si tu proyecto ya usa Fastlane para compilar y firmar. Una sola llamada al lane gestiona la compilación y la subida. - **Mediante la API de subida de Applivery directamente** — recomendado para cualquier proyecto o cuando no se usa Fastlane. Usa un paso `curl` en tu workflow YAML sin dependencias adicionales. * * * ### Requisitos previos Antes de configurar cualquiera de los dos enfoques, asegúrate de tener: - Un repositorio de GitHub con Actions activado. - Un App API Token de Applivery. Encuéntralo en **Ajustes de la App → Token API** en el panel de Applivery, o consulta [Apps API Token](https://docs.applivery.com/es/app-distribution/api/app-api-token/). - Un workflow que genere un artefacto de Build (`.ipa`, `.apk`, `.aab` u otro formato compatible). * * * **Guardar el App Token como GitHub Secret** Nunca escribas tu token de Applivery directamente en un archivo de workflow: quedaría en tu repositorio y sería visible para cualquiera con acceso de lectura. Guárdalo como GitHub Secret para que quede enmascarado en los logs e inyectado como variable de entorno en tiempo de ejecución. 1. Abre tu repositorio de GitHub. 2. Ve a **Settings → Secrets and variables → Actions**. 3. Haz clic en **New repository secret**. 4. Establece el nombre como `APPLIVERY_TOKEN`. 5. Pega tu App API Token de Applivery como valor. 6. Haz clic en **Add secret**. Una vez guardado, referéncialo en tu workflow YAML como `${{ secrets.APPLIVERY_TOKEN }}`. :::info Si varios repositorios necesitan acceso al mismo token, crea un **Organization secret** en su lugar. Ve a **Settings → Secrets and variables → Actions** de tu organización y sigue el mismo proceso. ::: **Opción A — Integración mediante Fastlane** Este enfoque es el recomendado si tu proyecto ya usa Fastlane. El plugin de Applivery para Fastlane gestiona la subida y todos los metadatos en una sola llamada al lane. Para la documentación completa del plugin, consulta [Integración con Fastlane](https://docs.applivery.com/es/app-distribution/ci-cd/fastlane/). #### Workflow YAML ```yaml name: Compilar y desplegar en Applivery on: push: branches: - develop - main jobs: deploy: runs-on: macos-latest steps: - name: Checkout uses: actions/checkout@v4 - name: Configurar Ruby uses: ruby/setup-ruby@v1 with: ruby-version: '3.2' bundler-cache: true - name: Desplegar en Applivery mediante Fastlane run: bundle exec fastlane ios deploy env: APPLIVERY_TOKEN: ${{ secrets.APPLIVERY_TOKEN }} ``` #### Fastfile ```ruby platform :ios do lane :deploy do gym( scheme: "MyApp", export_method: "enterprise" ) applivery( app_token: ENV["APPLIVERY_TOKEN"], changelog: ENV["COMMIT_MESSAGE"], notify_collaborators: true, notify_message: "Nueva Build desde GitHub Actions", tags: "github-actions, #{ENV["GITHUB_REF_NAME"]}" ) end end ``` **Opción B — Integración mediante la API de subida (sin Fastlane)** Este enfoque llama directamente a la API de subida de Applivery desde tu workflow usando `curl`. Funciona para cualquier plataforma sin herramientas adicionales. #### Ejemplo iOS ```yaml name: Compilar y desplegar iOS en Applivery on: push: branches: - develop jobs: build-and-deploy: runs-on: macos-latest steps: - name: Checkout uses: actions/checkout@v4 - name: Compilar app iOS run: | xcodebuild -scheme MyApp \ -configuration Release \ -archivePath build/MyApp.xcarchive \ archive xcodebuild -exportArchive \ -archivePath build/MyApp.xcarchive \ -exportPath build/ \ -exportOptionsPlist ExportOptions.plist - name: Subir a Applivery run: | curl 'https://upload.applivery.io/v1/integrations/builds' \ --retry 5 \ --fail \ -H "Authorization: Bearer ${{ secrets.APPLIVERY_TOKEN }}" \ -F "build=@build/MyApp.ipa" \ -F "versionName=${{ github.run_number }}" \ -F "changelog=${{ github.event.head_commit.message }}" \ -F "tags=github-actions, ${{ github.ref_name }}" \ -F "notifyCollaborators=true" \ -F "notifyMessage=Nueva Build de iOS desde GitHub Actions" \ -F "notifyLanguage=es" \ -F "deployer.name=GitHub Actions" \ -F "deployer.info.commit=${{ github.sha }}" \ -F "deployer.info.branch=${{ github.ref_name }}" \ -F "deployer.info.commitMessage=${{ github.event.head_commit.message }}" \ -F "deployer.info.buildUrl=${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}" \ -F "deployer.info.buildNumber=${{ github.run_number }}" \ -F "deployer.info.repositoryUrl=${{ github.server_url }}/${{ github.repository }}" ``` #### Ejemplo Android ```yaml name: Compilar y desplegar Android en Applivery on: push: branches: - develop jobs: build-and-deploy: runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v4 - name: Configurar JDK uses: actions/setup-java@v4 with: java-version: '17' distribution: 'temurin' - name: Compilar APK de Android run: ./gradlew assembleRelease - name: Subir a Applivery run: | curl 'https://upload.applivery.io/v1/integrations/builds' \ --retry 5 \ --fail \ -H "Authorization: Bearer ${{ secrets.APPLIVERY_TOKEN }}" \ -F "build=@app/build/outputs/apk/release/app-release.apk" \ -F "versionName=${{ github.run_number }}" \ -F "changelog=${{ github.event.head_commit.message }}" \ -F "tags=github-actions, ${{ github.ref_name }}" \ -F "notifyCollaborators=true" \ -F "notifyMessage=Nueva Build de Android desde GitHub Actions" \ -F "notifyLanguage=es" \ -F "deployer.name=GitHub Actions" \ -F "deployer.info.commit=${{ github.sha }}" \ -F "deployer.info.branch=${{ github.ref_name }}" \ -F "deployer.info.commitMessage=${{ github.event.head_commit.message }}" \ -F "deployer.info.buildUrl=${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}" \ -F "deployer.info.buildNumber=${{ github.run_number }}" \ -F "deployer.info.repositoryUrl=${{ github.server_url }}/${{ github.repository }}" ``` * * * ### Avanzado: Disparar por tags para Builds de release Un patrón habitual es disparar la subida a Applivery solo con tags de versión (por ejemplo, `v2.4.0`), manteniendo las Builds de ramas de funcionalidades separadas de los candidatos a release: ```yaml on: push: tags: - 'v*' # Se dispara con v1.0.0, v2.4.0-rc1, etc. ``` Combinado con `${{ github.ref_name }}` como tag en Applivery, es fácil filtrar Builds de release desde el panel. * * * ### Avanzado: Subir solo tras pruebas exitosas Usa dependencias entre jobs para garantizar que la Build solo se sube a Applivery si las pruebas pasan: ```yaml jobs: test: runs-on: macos-latest steps: - uses: actions/checkout@v4 - name: Ejecutar pruebas run: ./gradlew test deploy: runs-on: ubuntu-latest needs: test # Solo se ejecuta si el job 'test' tiene éxito steps: - name: Subir a Applivery run: | curl ... ``` * * * ### Variables de contexto de GitHub Actions Los ejemplos de workflow anteriores usan variables de contexto de GitHub Actions, disponibles automáticamente en cualquier workflow: | Variable | Descripción | | --- | --- | | `${{ github.sha }}` | SHA completo del commit que disparó el workflow. | | `${{ github.ref_name }}` | Nombre corto de la rama o tag (por ejemplo: `develop`, `v2.4.0`). | | `${{ github.run_number }}` | Número de ejecución secuencial del workflow. Útil como `versionName` en Applivery. | | `${{ github.run_id }}` | ID numérico único para la ejecución del workflow. Se usa para construir la URL de la Build. | | `${{ github.event.head_commit.message }}` | Mensaje del commit que disparó el workflow. Útil como `changelog`. | | `${{ github.server_url }}` | URL base de la instancia de GitHub (por ejemplo: `https://github.com`). | | `${{ github.repository }}` | Nombre del propietario y del repositorio (por ejemplo: `miorg/miapp`). | | `${{ secrets.APPLIVERY_TOKEN }}` | El App Token de Applivery guardado como GitHub Secret. | Para la referencia completa, consulta la [documentación de contextos de GitHub Actions](https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/accessing-contextual-information-about-workflow-runs). * * * ### Referencia de parámetros de subida Los campos del formulario `curl` se corresponden directamente con los parámetros de la API de subida de Applivery. Los más utilizados: | Parámetro | Descripción | | --- | --- | | `build` | El archivo binario a subir (`.ipa`, `.apk`, `.aab`). | | `versionName` | Etiqueta legible para la Build. Usar `${{ github.run_number }}` la vincula con la ejecución de GitHub. | | `changelog` | Notas de la versión mostradas en el panel y en los emails de notificación. | | `tags` | Etiquetas separadas por comas para filtrar Builds. Por ejemplo: `github-actions, develop`. | | `notifyCollaborators` | Establece como `true` para enviar un email a los Colaboradores de la App al subir. | | `notifyMessage` | Mensaje personalizado incluido en el email de notificación. | | `deployer.name` | Nombre de la plataforma CI mostrado en el panel de Applivery. | | `deployer.info.commit` | SHA del commit de Git. | | `deployer.info.branch` | Rama o tag de Git. | | `deployer.info.buildNumber` | Número de ejecución del workflow. | | `deployer.info.buildUrl` | URL directa a la ejecución del workflow de GitHub Actions. | Para la referencia completa de parámetros, consulta [POST – Subir una Build](https://docs.applivery.com/es/app-distribution/api/builds/upload-build/). --- ## Jenkins Source: https://docs.applivery.com/es/app-distribution/ci-cd/jenkins/ Description: Integra Jenkins con Applivery para automatizar la subida de Builds y agilizar tu flujo de trabajo CI/CD de distribución de apps móviles. TL;DR: Integra Jenkins con Applivery para subir nuevas builds automáticamente tras cada ejecución del pipeline, optimizando tu flujo de CI/CD. Answers: ¿Cómo integro Jenkins con Applivery? · ¿Cómo guardo el token de Applivery de forma segura en Jenkins? · ¿Qué variables de entorno de Jenkins puedo usar con Applivery? · ¿Cómo notifico a los Colaboradores de nuevas Builds subidas desde Jenkins? ![jenkins](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/8507c9b2-5456-4b69-abe0-f284975ab253.jpg "jenkins | Applivery") ## Integración con Jenkins [Jenkins](https://www.jenkins.io/) es un servidor de automatización de código abierto ampliamente utilizado para la integración y entrega continuas. Orquesta las etapas de compilación, prueba, empaquetado y despliegue de un pipeline de entrega de software. La integración de Applivery con Jenkins te permite subir automáticamente una nueva Build a Applivery al final de cada ejecución del pipeline, haciendo que los binarios recién compilados estén inmediatamente disponibles para los equipos de QA, las partes interesadas o los usuarios internos sin ningún paso manual. :::info Applivery no tiene un plugin dedicado para Jenkins. La integración usa el [plugin HTTP Request](https://www.jenkins.io/doc/pipeline/steps/http_request/) estándar de Jenkins para llamar directamente a la API de subida de Applivery. Este enfoque es más sencillo, más fácil de mantener y funciona con cualquier versión de Jenkins. ::: --- ### Requisitos previos Antes de configurar la integración, asegúrate de tener: - Una instancia de Jenkins con el [plugin HTTP Request](https://plugins.jenkins.io/http_request/) instalado. - Un App API Token de Applivery. Encuéntralo en **Ajustes de la App → Token API** en el panel de Applivery, o consulta [Integration API Token](https://docs.applivery.com/es/app-distribution/api/app-api-token/) para instrucciones sobre cómo crearlo. - Un pipeline de Jenkins que genere un artefacto de Build (`.ipa`, `.apk`, `.aab` u otro formato compatible). --- **Guardar el App Token como credencial de Jenkins** Nunca escribas tu token de Applivery directamente en el `Jenkinsfile`. Guárdalo como credencial secreta en Jenkins y referencíala mediante una variable de entorno. 1. Ve a **Jenkins → Manage Jenkins → Credentials**. 2. Añade una nueva credencial de tipo **Secret text**. 3. Establece el ID como `APPLIVERY_TOKEN` (o cualquier nombre que prefieras; úsalo de forma consistente). 4. Pega tu App API Token de Applivery como valor secreto. En tu `Jenkinsfile`, expón la credencial como variable de entorno: ```groovy environment { APPLIVERY_TOKEN = credentials('APPLIVERY_TOKEN') } ``` **Añadir la etapa de subida a tu pipeline** Añade una etapa `Applivery Upload` después de tu paso de compilación. La etapa usa el paso `httpRequest` del plugin HTTP Request para llamar a la API de subida de Applivery con `multipart/form-data`. ```groovy stage('Applivery Upload') { def response = httpRequest( url: 'https://upload.applivery.io/v1/integrations/builds', httpMode: 'POST', consoleLogResponseBody: true, wrapAsMultipart: true, customHeaders: [ [ maskValue: true, name: 'Authorization', value: "Bearer ${env.APPLIVERY_TOKEN}" ] ], formData: [ // Archivo de Build [ name: 'build', fileName: 'app.ipa', uploadFile: './app.ipa', contentType: 'application/octet-stream' ], // Metadatos de la Build [name: 'versionName', value: "${env.BUILD_TAG}"], [name: 'changelog', value: "${env.GIT_COMMIT_MSG}"], [name: 'tags', value: 'jenkins, ci'], // Notificaciones [name: 'notifyCollaborators', value: 'true'], [name: 'notifyEmployees', value: 'false'], [name: 'notifyMessage', value: 'Nueva Build disponible desde Jenkins'], [name: 'notifyLanguage', value: 'es'], // Filtro de grupo de notificación (opcional) // Para notificar a usuarios en group1 Y group2, O group3: [name: 'filter[0][0]', value: 'group1'], [name: 'filter[0][1]', value: 'group2'], [name: 'filter[1][0]', value: 'group3'], // Metadatos CI/CD — aparecen en el panel de Applivery [name: 'deployer.name', value: 'Jenkins'], [name: 'deployer.info.commitMessage', value: "${env.GIT_COMMIT_MSG}"], [name: 'deployer.info.commit', value: "${env.GIT_COMMIT}"], [name: 'deployer.info.branch', value: "${env.GIT_BRANCH}"], [name: 'deployer.info.buildUrl', value: "${env.BUILD_URL}"], [name: 'deployer.info.buildNumber', value: "${env.BUILD_NUMBER}"], [name: 'deployer.info.repositoryUrl', value: "${env.GIT_URL}"] ] ) echo "Respuesta de subida a Applivery: ${response}" } ``` --- ### Ejemplo completo de Jenkinsfile Aquí tienes un ejemplo completo de pipeline para una Build iOS: ```groovy pipeline { agent any environment { APPLIVERY_TOKEN = credentials('APPLIVERY_TOKEN') } stages { stage('Checkout') { steps { checkout scm } } stage('Build') { steps { // Reemplaza con tu comando de compilación real sh 'xcodebuild -scheme MyApp -configuration Release archive -archivePath build/MyApp.xcarchive' sh 'xcodebuild -exportArchive -archivePath build/MyApp.xcarchive -exportPath build/ -exportOptionsPlist ExportOptions.plist' } } stage('Applivery Upload') { steps { script { def response = httpRequest( url: 'https://upload.applivery.io/v1/integrations/builds', httpMode: 'POST', consoleLogResponseBody: true, wrapAsMultipart: true, customHeaders: [ [ maskValue: true, name: 'Authorization', value: "Bearer ${env.APPLIVERY_TOKEN}" ] ], formData: [ [ name: 'build', fileName: 'MyApp.ipa', uploadFile: './build/MyApp.ipa', contentType: 'application/octet-stream' ], [name: 'versionName', value: "${env.BUILD_TAG}"], [name: 'changelog', value: "Build #${env.BUILD_NUMBER} — ${env.GIT_BRANCH}"], [name: 'notifyCollaborators', value: 'true'], [name: 'notifyMessage', value: 'Nueva Build lista para pruebas'], [name: 'notifyLanguage', value: 'es'], [name: 'deployer.name', value: 'Jenkins'], [name: 'deployer.info.commit', value: "${env.GIT_COMMIT}"], [name: 'deployer.info.branch', value: "${env.GIT_BRANCH}"], [name: 'deployer.info.commitMessage', value: "${env.GIT_COMMIT_MSG}"], [name: 'deployer.info.buildUrl', value: "${env.BUILD_URL}"], [name: 'deployer.info.buildNumber', value: "${env.BUILD_NUMBER}"], [name: 'deployer.info.repositoryUrl', value: "${env.GIT_URL}"] ] ) echo "Respuesta de subida a Applivery: ${response}" } } } } post { failure { echo 'La compilación o la subida han fallado.' } } } ``` --- ### Referencia de parámetros clave El array `formData` se corresponde directamente con los parámetros de la API de subida de Applivery. Los más utilizados: | Parámetro | Descripción | |---|---| | `build` | El archivo binario a subir. Usa `uploadFile` para la ruta local y `fileName` para el nombre que Applivery registrará. | | `versionName` | Etiqueta legible para la Build. Usar `${env.BUILD_TAG}` o `${env.BUILD_NUMBER}` facilita su trazabilidad en Applivery. | | `changelog` | Notas de la versión mostradas en el panel de Applivery y en los emails de notificación. | | `tags` | Etiquetas separadas por comas para filtrar Builds. Por ejemplo: `jenkins, staging`. | | `notifyCollaborators` | Establece como `true` para enviar un email a los Colaboradores de la App cuando se suba la Build. | | `notifyEmployees` | Establece como `true` para enviar un email a los empleados de la tienda. | | `notifyMessage` | Mensaje personalizado incluido en el email de notificación. | | `notifyLanguage` | Idioma del email de notificación. Valores admitidos: `en`, `es`, `fr`, `de`, `it`, `zh`, `pt`, `ru`. | | `filter[N][M]` | Filtro de notificación por grupos. Cada array interno es una cláusula AND; cada índice externo es un OR. | | `deployer.name` | Nombre de la plataforma CI mostrado en el panel de Applivery. Por ejemplo: `Jenkins`. | | `deployer.info.commit` | SHA del commit de Git. | | `deployer.info.branch` | Nombre de la rama de Git. | | `deployer.info.buildNumber` | Número de Build de Jenkins. | | `deployer.info.buildUrl` | URL directa a la ejecución de Build en Jenkins. | | `deployer.info.repositoryUrl` | URL del repositorio de origen. | Para la referencia completa de parámetros, consulta [POST – Subir una Build](https://docs.applivery.com/es/app-distribution/api/builds/upload-build/). --- ### Variables de entorno de Jenkins Los ejemplos de pipeline anteriores usan variables de entorno integradas de Jenkins, disponibles en cualquier pipeline sin configuración adicional: | Variable | Descripción | |---|---| | `BUILD_NUMBER` | El número de Build actual. | | `BUILD_TAG` | Cadena con el formato `jenkins--`. Útil como nombre de versión. | | `BUILD_URL` | URL completa a la Build actual en la interfaz de Jenkins. | | `GIT_COMMIT` | SHA del commit de Git actual (requiere el plugin de Git). | | `GIT_BRANCH` | Nombre de la rama de Git actual (requiere el plugin de Git). | | `GIT_URL` | URL del repositorio de Git (requiere el plugin de Git). | :::warning `GIT_COMMIT_MSG` no es una variable integrada de Jenkins. Para usar el mensaje de commit en la subida, captúralo primero con un paso de shell: ```groovy env.GIT_COMMIT_MSG = sh(script: 'git log -1 --pretty=%B', returnStdout: true).trim() ``` ::: --- ## Distribución Source: https://docs.applivery.com/es/app-distribution/distribute/ Description: Distribución de apps con Applivery — gestiona y despliega Builds en plataformas móviles, de escritorio, web y de consola desde un único panel. Answers: ¿Qué es la distribución de apps en Applivery? · ¿Cómo distribuyo una app a mis usuarios en Applivery? · ¿Qué es una Publicación en Applivery? Pon tus Apps a disposición de los usuarios mediante Publicaciones, Audiencias y la Enterprise Store. Una vez cargada una Build, puedes crear una Publicación, definir su visibilidad, configurar los controles de acceso y distribuirla a las personas adecuadas. También encontrarás información sobre cómo gestionar Colaboradores y empleados de la tienda, configurar Grupos de usuarios y configurar el acceso OTP para usuarios externos que no tienen cuenta en Applivery. --- ## Distribuir Apps Source: https://docs.applivery.com/es/app-distribution/distribute/distribute-apps/ Description: Distribuye Apps a través de las tiendas pública y privada de Applivery. Controla el acceso, la seguridad y el branding por app y por Audiencia. TL;DR: Applivery permite distribuir apps de forma segura a través de tiendas públicas y privadas con opciones flexibles de control de acceso. Answers: ¿Qué tipos de tiendas de apps admite Applivery? · ¿Cómo controlo quién accede a una App publicada en Applivery? · ¿Qué es el acceso OTP en Applivery? · ¿Cuánto tiempo es válido un OTP y cuánto dura la sesión? Applivery ofrece una forma potente de distribuir Apps a través de **tiendas de apps públicas o privadas** que admiten múltiples configuraciones de seguridad, control de acceso y branding. También puedes tener configuraciones diferentes para cada App y cada Audiencia. ### Tiendas de apps Applivery admite tiendas de apps **públicas** y **privadas**. **Tiendas de apps públicas**: - Tu Enterprise Store está disponible públicamente bajo tu URL (`tunombre.applivery.com` o tu dominio personalizado). - Cualquier persona que conozca la URL puede acceder a la lista de Apps publicadas, siempre que no estén ocultas ni inactivas. - Tu Enterprise Store y su contenido pueden ser indexados por buscadores como Google o Bing. **Tiendas de apps privadas**: - Tu Enterprise Store no está disponible para el público en general. Los usuarios deben autenticarse para acceder a la lista de Apps. - Los usuarios pueden iniciar sesión con su cuenta de Applivery o con el Single Sign-On de tu Workspace (si está configurado). - La página de inicio de la Enterprise Store puede ser indexada por buscadores, pero el contenido requiere autenticación. :::tip En las tiendas privadas, puedes desactivar completamente las Publicaciones públicas. Ve a **Enterprise Store > Personalizar**, busca la sección **Seguridad** y desactiva la opción **Permitir Publicaciones públicas**. Si ya existen Publicaciones públicas, se te pedirá que las elimines. ::: ![allow public Publications](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/9424b2ef-d7d0-4dfe-8f12-3002d37959e0.png) En ambos casos, los usuarios podrán añadir la Enterprise Store a su pantalla de inicio para tener acceso más directo y fácil a las Apps de tu Workspace. Puedes seguir los pasos descritos en nuestros artículos para iOS y Android. ### Apps publicadas Para cada proyecto de App en Applivery, puedes crear una o más **Apps publicadas** para controlar cómo se hacen disponibles las distintas Builds para los Colaboradores, los empleados de la tienda y los usuarios externos a través de la Enterprise Store. Hay cuatro áreas de configuración clave para cada Publicación: **Selección de Build** Define qué Build o Builds muestra la Publicación: | Modo | Comportamiento | | --- | --- | | **Manual** | Distribuye una Build específica de tu lista de Builds. El historial de Builds no está disponible en este modo. | | **Tags** | Distribuye cualquier Build que coincida con una etiqueta personalizada o un conjunto de etiquetas. | | **Git Tag / Git Branch** | Despliega Builds que coincidan con una rama de Git concreta (por ejemplo: `develop`) o un tag de Git (por ejemplo: `3.2.1`). | | **Última** | Apunta siempre a la Build más reciente subida para cada SO. | **Visibilidad** Controla si la Publicación aparece en la Enterprise Store y cómo: | Opción | Comportamiento | | --- | --- | | **Inactiva** | No accesible para nadie. | | **Activa** | Visible para todos en la Enterprise Store. | | **Oculta** | No aparece en la Enterprise Store, pero es accesible para cualquiera con la URL directa. | **Seguridad** Controla el método de autenticación requerido para acceder a la Publicación: | Opción | Comportamiento | | --- | --- | | **Pública** | Sin autenticación requerida. Cualquiera con el enlace puede acceder y descargar. | | **Privada** | Requiere inicio de sesión mediante cuenta de Applivery o el SSO de tu Workspace. | | **Contraseña** | Requiere una contraseña que tú defines. No se necesita cuenta de usuario. | | **OTP (One-Time Password)** | El acceso se otorga mediante un código temporal enviado por email a una lista de usuarios preaprobados. No requiere SSO ni cuenta de Applivery. | **Control de acceso** Reglas opcionales que restringen aún más quién puede acceder a una Publicación, independientemente del modo de seguridad: - **Grupos de usuarios** o **Audiencias**: Para Publicaciones privadas, limita el acceso a Grupos de usuarios o Audiencias definidas dentro de tu Workspace. - **Restricciones por país**: Permite o bloquea el acceso según la ubicación geográfica del usuario. ![create Publication](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/e2491937-01dd-4b0d-b85d-d24b44b68136.png) ### Acceso OTP (One-Time Password) El acceso OTP es una configuración de seguridad disponible para Publicaciones privadas que te permite compartir Builds de forma segura con usuarios externos que no forman parte de tu organización —freelancers, estudios externos, testers de QA externos y colaboradores similares— sin que necesiten cuenta en Applivery ni pasar por tu SSO. Esto es especialmente útil para organizaciones con políticas SSO estrictas que necesitan compartir Builds externamente sin relajar su configuración de autenticación global. El acceso OTP se configura por Publicación y no afecta a ninguna otra Publicación ni a la configuración de autenticación global de la Enterprise Store. :::info El OTP está disponible únicamente a nivel de Publicación, no es un método de inicio de sesión global para la Enterprise Store. Un usuario que acceda a una Publicación mediante OTP está restringido a esa Publicación y no puede navegar libremente por otras partes de tu Enterprise Store. Si navega fuera de ella, solo puede volver a la misma Publicación a la que accedió originalmente mediante OTP. ::: #### Cómo funciona ##### Desde el lado del administrador :::warning El OTP solo puede configurarse después de que se haya creado la Publicación. Abre la Publicación en modo edición para acceder a la configuración de OTP. ::: :::warning Los cambios en los usuarios OTP se guardan inmediatamente al hacer clic en Guardar dentro del panel de OTP. No es necesario volver a guardar la Publicación después. ::: **Abre la Publicación en modo edición** **Activa el acceso OTP** En la sección Seguridad, activa el acceso OTP. **Configura el Control de acceso** En la sección Control de acceso, selecciona quién puede acceder a la Publicación. El OTP funciona con **Todos los usuarios**, un **Grupo de usuarios** específico o una **Audiencia**. **Añade usuarios a la lista de permitidos OTP** Abre el panel de Usuarios OTP y añade las direcciones de email de los usuarios externos a los que quieres conceder acceso. **Configura los ajustes por usuario** Para cada usuario, establece el **Límite de descargas**: elige entre descargas ilimitadas o un número específico. Establécelo en `1` para aplicar el acceso de un solo uso. El campo Descargas en el panel de Usuarios OTP muestra el número de descargas restantes, no el número de descargas ya realizadas. :::tip Combina el OTP con una Publicación con fecha de expiración para establecer un plazo absoluto de acceso, sin necesidad de limpiar manualmente una vez que pase el plazo. ::: ##### Desde el lado del usuario externo **Introduce la dirección de email** El usuario visita la URL de la Publicación y se le pide que introduzca su dirección de email. **Recibe el OTP por email** Si su email está en la lista de permitidos, recibe un OTP temporal por email, válido durante **5 minutos**. **Introduce el OTP** El usuario introduce el OTP para verificar su identidad y obtener acceso a la Publicación. **Accede a la Publicación** Una vez autenticado, su sesión permanece activa durante **2 horas**. Tras ese tiempo, necesitará solicitar un nuevo OTP para acceder de nuevo a la Publicación. **Límite de descargas alcanzado (si está configurado)** Si hay un límite de descargas configurado y el usuario lo ha alcanzado, no podrá volver a descargar a menos que un administrador restablezca o aumente su límite desde el panel de Usuarios OTP. #### Opciones de configuración | Opción | Descripción | | --- | --- | | Lista de permitidos | La lista de direcciones de email autorizadas a solicitar un OTP. | | Límite de descargas | Número máximo de descargas permitidas por usuario. Establécelo en `1` para aplicar el acceso de un solo uso, o déjalo ilimitado para descargas sin restricciones. Los administradores pueden actualizar este valor en cualquier momento desde el panel de Usuarios OTP. | | Expiración del OTP | Los OTPs son válidos exactamente durante 5 minutos y no pueden reutilizarse. | | Duración de la sesión | Tras un acceso OTP exitoso, la sesión permanece activa durante 2 horas. | | Notificaciones de nueva Build | Cuando se publica una nueva Build, los usuarios OTP de la lista de permitidos pueden recibir un email de notificación con un OTP actualizado, lo que les permite descargar sin tener que solicitar acceso de nuevo manualmente. | :::info Las **notificaciones de nueva Build** aún no están disponibles. Esta funcionalidad estará disponible próximamente. ::: #### Cuándo usar el acceso OTP | Escenario | Enfoque recomendado | | --- | --- | | Compartir una Build con un freelancer externo para una revisión puntual | OTP + límite de descargas en 1. | | Compartir una beta con un estudio de QA externo durante un período de prueba limitado | OTP + Publicación con fecha de expiración. | | Distribuir a una lista de testers externos sin darles cuentas permanentes | OTP + ciclo de vida de usuario temporal. | | Colaboradores externos a largo plazo que necesitan acceso continuado | Publicación privada + Audiencia de la Enterprise Store. | :::tip Para colaboradores a largo plazo que necesitan acceso continuado a varias Builds, considera usar una Publicación privada con acceso basado en Audiencias a través de la Enterprise Store en lugar de OTP. El OTP está pensado para escenarios de compartición externa temporal y controlada. ::: ### Configuración avanzada #### Restringir el acceso a ciertos Grupos de usuarios o Audiencias Al configurar **Apps publicadas privadas** (usando inicio de sesión de Applivery o Single Sign-On), también puedes especificar qué Grupos de usuarios o Audiencias tendrán acceso a la App. Para hacerlo, añade la lista bajo el selector **Acceso** y haz clic en **Guardar**. ![access groups](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/b4ecd93b-41bc-45c8-a0de-02298d1adb52.png) #### Bloquear o permitir el acceso por país Puedes definir qué países tienen permitido o bloqueado el acceso a una Publicación. Añade la lista de países en el ajuste **Control de acceso** de la Publicación y guarda. ### Buenas prácticas #### Usa Publicaciones separadas para cada Audiencia Al distribuir a grupos distintos (testers internos, QA, clientes, socios, estudios externos), **crea una Publicación separada para cada Audiencia**. Esto mantiene el control de acceso y la visibilidad independientes, y facilita revocar o modificar el acceso de un grupo sin afectar a los demás. #### Usa la última Build para actualizaciones continuas Si subes Builds con frecuencia, evita crear una nueva Publicación para cada una. En su lugar, establece la **Selección de Build = Última** y activa **Mostrar historial de Builds**. Esto te dará una única Publicación que siempre apunta a la Build más reciente, mientras sigue proporcionando acceso a versiones anteriores a través del historial de Builds. También puedes compartir directamente una Build específica añadiendo lo siguiente a la URL de la Publicación: ``` demo.applivery.io/{pubSlug}/{SO}/{buildId} ``` #### Combina OTP con Publicaciones con fecha de expiración para acceso externo limitado en el tiempo Para el máximo control al compartir con usuarios externos, combina el **acceso OTP** con **Publicaciones con fecha de expiración**. Esto garantiza que el acceso esté tanto verificado por identidad (mediante la lista de permitidos OTP) como limitado en el tiempo (mediante la expiración de la Publicación), sin necesidad de ninguna limpieza manual una vez pasado el plazo. ![auto expire](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/d9708724-015a-46d3-9585-7995a9e9c52c.png) #### Mantén tu política SSO intacta al compartir externamente Si tu organización aplica autenticación solo con SSO globalmente, usa el **acceso OTP** para los colaboradores externos en lugar de relajar tu política SSO o crear excepciones. El OTP opera de forma independiente a tu configuración de autenticación global y no interfiere con cómo los usuarios internos se autentican. --- ## Gestión de usuarios Source: https://docs.applivery.com/es/app-distribution/distribute/manage-users/ Description: Gestiona los usuarios en la Distribución de Apps de Applivery. Comprende los roles de Colaborador y Empleado de la tienda, los permisos y las buenas prácticas. TL;DR: La gestión de usuarios en Applivery distingue dos tipos clave: Colaboradores con acceso administrativo y Usuarios que descargan las apps distribuidas. Answers: ¿Cuáles son los dos tipos principales de usuarios en Applivery? · ¿Cuál es la diferencia entre Colaboradores y Empleados de la Store? · ¿Qué roles se pueden asignar a los Colaboradores en Applivery? · ¿Cómo se crean las cuentas de Empleados de la Store? La gestión de usuarios es un componente fundamental de la Distribución de Apps en Applivery. Garantiza que las personas adecuadas tengan el nivel de acceso correcto a los proyectos, las Apps y la Enterprise Store. Applivery divide los usuarios en dos categorías principales: **Colaboradores** y **Empleados de la Store**. Entender la diferencia entre ambos es esencial para configurar un flujo de distribución seguro y bien organizado. * * * ### Colaboradores Los Colaboradores son usuarios con acceso administrativo a tu Workspace y los proyectos de App. Operan a través del panel de Applivery y son responsables de gestionar las Apps, subir Builds, configurar los ajustes y supervisar la distribución. #### Roles y permisos A cada Colaborador se le asigna uno de los siguientes roles, que determina su nivel de acceso: | Rol | Descripción | | --- | --- | | **Propietario** | Superadministrador del Workspace. Tiene acceso completo a todos los recursos, incluida la facturación. Solo puede haber un Propietario por Workspace. | | **Admin** | Permisos administrativos completos sobre Apps y ajustes del Workspace, excepto la facturación. Puede gestionar a otros Colaboradores. | | **Editor** | Puede subir Builds. Tiene acceso de solo lectura a Distribución y Ajustes. No puede acceder a la facturación. | | **Visor** | Acceso de solo lectura a todos los recursos, excepto Facturación, Directorio y Ajustes. | | **Sin asignar** | Sin acceso a nivel de Workspace. Puede asignársele un rol específico a nivel de App individual. | :::info Estos roles se aplican a la Distribución de Apps. Device Management usa sus propios roles, que se asignan en los permisos de segmento. Consulta [Roles de Colaborador personalizados](https://docs.applivery.com/es/platform/roles-permissions/custom-collaborator-roles/). ::: ![Collaborators app management](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/5345d862-0170-471c-9456-67c0fe1bffc4.png) :::tip Sigue el principio de mínimo privilegio al asignar roles: concede a cada Colaborador solo el acceso que necesita para desempeñar sus responsabilidades. ::: * * * ### Empleados de la Store Los Empleados de la Store son los usuarios finales que acceden a tus Apps a través de la Enterprise Store. A diferencia de los Colaboradores, no tienen acceso al panel de Applivery: solo interactúan con la experiencia de la Enterprise Store. Las cuentas de Empleados de la Store pueden gestionarse tanto a nivel de App como de organización, y su acceso se controla mediante Grupos, Audiencias de usuario y permisos específicos por App. #### Origen de los empleados Las cuentas de Empleados de la Store se crean a través de diferentes mecanismos. El origen de una cuenta determina cómo se creó y cómo se comporta: | Origen | Descripción | | --- | --- | | **Panel** | Empleados invitados manualmente por un administrador desde el panel. Reciben una invitación por email para registrar su cuenta y acceder a la Enterprise Store. | | **SSO** | Empleados creados automáticamente la primera vez que inician sesión en la Enterprise Store usando Single Sign-On. No se requiere invitación manual. | | **SDK** | Empleados identificados (con al menos una dirección de email conocida) creados programáticamente mediante el método `bindUser()` del SDK de Applivery. | | **SDK Temporal** | Usuarios anónimos creados automáticamente por el SDK para identificar un dispositivo. Únicos por Workspace según el ID del dispositivo. Expiran automáticamente tras **30 días de inactividad**. | | **OTP** | Usuarios externos temporales a los que se ha concedido acceso mediante una contraseña de un solo uso a nivel de Publicación. Diseñados para usuarios que no forman parte de tu organización y no deben necesitar cuenta en Applivery ni acceso SSO. Los usuarios OTP tienen alcance en una Publicación específica y expiran tras **30 días**, salvo que se configuren como persistentes. | ![employees app distribution](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ff05aa19-af8b-427f-9b62-170f97373107.png) :::info Para más información sobre los usuarios del SDK y cómo funciona `bindUser()`, consulta [Usuarios del SDK](https://docs.applivery.com/es/app-distribution/sdk/sdk-users/). ::: :::info Puedes obtener más información sobre los usuarios OTP siguiendo este [enlace](https://docs.applivery.com/es/app-distribution/distribute/distribute-apps/#acceso-otp-one-time-password). ::: * * * ### Grupos y Audiencias de usuarios Los Colaboradores pueden organizar a los Empleados de la Store en colecciones para simplificar la segmentación de apps y la distribución a escala. Los [**Grupos**](https://docs.applivery.com/es/app-distribution/distribute/user-groups/) son colecciones estáticas de Empleados de la Store creadas manualmente por los administradores. Son ideales para la distribución por departamentos, equipos de proyecto temporales o escenarios de distribución controlada donde la pertenencia es fija y se gestiona explícitamente. Las [**Audiencias de usuarios**](https://docs.applivery.com/es/app-distribution/distribute/user-audiences/) son grupos dinámicos poblados automáticamente según atributos o actividad de los Empleados de la Store. La pertenencia se actualiza automáticamente a medida que cambian los atributos, lo que hace que las Audiencias sean ideales para escenarios de distribución a gran escala o en evolución donde gestionar grupos estáticos sería poco práctico. Las Apps y las Publicaciones pueden dirigirse a empleados individuales, Grupos y Audiencias de usuarios, o a una combinación de los tres. Esto permite un control de acceso preciso, distribuciones por fases y el cumplimiento de las políticas de distribución internas. * * * ### Actividad de los usuarios La vista de **Actividad de usuarios** proporciona visibilidad sobre las marcas de tiempo del último inicio de sesión y la última acción de cada usuario, ya sea Colaborador o Empleado de la tienda. - Los **inicios de sesión** actualizan tanto la marca de tiempo del último inicio de sesión como la de la última acción. - **Otras acciones** —como subir una Build o instalar una App— actualizan solo la marca de tiempo de la última acción. Revisar periódicamente la actividad de los usuarios ayuda a mantener el Workspace organizado y garantiza que se identifiquen y gestionen adecuadamente las cuentas inactivas o no utilizadas. * * * ### Cómo invitar usuarios Para añadir usuarios a tu Workspace dirígete al [**panel de Applivery**](https://dashboard.applivery.io), navega a **Configuración** 1 y selecciona la sección **Directorio** 2 en el menú lateral izquierdo. Desde allí, elige si quieres añadir un Colaborador o un Empleado de la tienda. ![add user](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/e5cc55d8-7c55-4455-912f-45a3937ba866.png) #### Invitar Colaboradores El flujo de invitación para nuevos Colaboradores depende de si la persona ya tiene cuenta en Applivery. **Usuario nuevo (sin cuenta de Applivery existente):** 1. El usuario recibe una invitación por email para registrarse. Su dirección de email ya está rellenada en el formulario de registro. 2. Tras registrarse, el usuario recibe un segundo email para verificar su dirección. 3. Una vez verificada, es redirigido a la página de inicio de sesión para introducir sus nuevas credenciales. 4. Tras iniciar sesión, accede al panel. Es posible que tenga que seleccionar tu Workspace en el menú lateral izquierdo para encontrar la App a la que fue invitado. **Usuario existente (ya tiene cuenta de Applivery):** El usuario recibe una notificación por email con un enlace directo al panel. Es posible que tenga que iniciar sesión primero antes de que el enlace le redirija a la App correcta. ![Collaborators flow](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ccc4c04b-f0d5-4e11-b347-fe3ee2eeb73b.webp) #### Invitar Empleados de la Store Cuando se invita a un Empleado de la tienda, se le dirige directamente a tu Enterprise Store, no al panel. Sigue un flujo de incorporación simplificado para acceder a las Apps que tiene autorización para instalar y usar. ![employees flow](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/eaa3acd9-d2fc-4c74-9e1d-61627a112f43.png) * * * ### Buenas prácticas - Asigna los roles de Colaborador siguiendo el **principio de mínimo privilegio**: concede a cada persona solo el acceso que necesita. - Usa las **Audiencias de usuarios** para la segmentación dinámica de Apps basada en atributos, en lugar de mantener manualmente grandes grupos estáticos. - Usa los **Grupos** para agrupaciones fijas e intencionales, como equipos, departamentos o testers beta. - **Combina Grupos y Audiencias** para estrategias de distribución híbridas: por ejemplo, una audiencia base más un grupo de acceso anticipado. - **Revisa periódicamente la actividad de los Empleados de la Store** para identificar y eliminar cuentas obsoletas o inactivas, especialmente los usuarios temporales del SDK que pueden acumularse con el tiempo. --- ## Despliegue progresivo con tags Source: https://docs.applivery.com/es/app-distribution/distribute/progressive-deployment/ Description: Publica Builds de forma gradual en tu organización usando anillos de despliegue — asocia cada anillo a una Publicación filtrada por tags y promociona un único Build desde el piloto hasta producción. TL;DR: Crea una Publicación por anillo con la selección de Build configurada en Tags, asigna a cada anillo sus propios Grupos o Audiencias y después promociona una versión añadiendo la tag del siguiente anillo al mismo Build. Answers: ¿Cómo hago un despliegue por fases en Applivery? · ¿Cómo publico una app primero a un grupo piloto? · ¿Cómo promociono un build entre entornos en Applivery? · ¿Cómo funcionan las tags en las Publicaciones de Applivery? · ¿Puedo usar un único build para varias publicaciones? Key topics: Anillos de despliegue, Tags de Build, Publicaciones, Control de acceso, Applivery, Builds, Grupos de usuarios, Audiencias Publicar una versión nueva para todos a la vez significa que, si algo va mal, todo el mundo se entera al mismo tiempo. El **despliegue progresivo** — también llamado despliegue por fases o por anillos — evita eso publicando primero a un grupo pequeño y ampliando la audiencia solo una vez que la versión ha demostrado su fiabilidad. Applivery no tiene una función dedicada de "anillos". Los construyes a partir de dos cosas que ya tienes: **tags en los Builds** y **Publicaciones que seleccionan Builds por tag**. Todo el modelo cabe en una frase: > Un anillo es una Publicación que sirve Builds que llevan una tag concreta. Promocionar una versión consiste en añadir la tag del siguiente anillo al mismo Build. ### Cómo se corresponden los anillos con Applivery Una configuración típica usa tres anillos, aunque puedes usar tantos como necesites: | Anillo | A quién llega | Propósito | | --- | --- | --- | | **Piloto** | Un puñado de personas — QA, early adopters | Detectar fallos evidentes antes de que los vea nadie más | | **Despliegue** | Uno o dos departamentos | Validar frente al uso real del día a día | | **Producción** | Todo el mundo | Disponibilidad general | Cada anillo necesita dos elementos: - **Una tag** que identifica el anillo, configurada en la selección de Build de la Publicación. - **Una regla de acceso** — los Grupos de usuarios o Audiencias que pueden acceder a esa Publicación. El Build en sí no tiene ninguna noción de anillo. Solo lleva tags, y las Publicaciones deciden qué hacer con ellas. :::tip Cuando subes un Build, las tags se envían como una **lista separada por comas**, así que una coma dentro del nombre de una tag la divide en dos tags. Usa guiones en su lugar: `ring-pilot`, `ring-rollout`, `ring-production`. Elige una convención y mantenla — la tag es lo que conecta todo. ::: ### Crear un anillo Un anillo es una Publicación normal con la **selección de Build** configurada en **Tags**. Crea una por anillo. #### Desde el Dashboard **Abre tu App y ve a Apps publicadas** Crea una nueva Publicación. **Configura la selección de Build en Tags** Introduce la tag de este anillo, por ejemplo `ring-pilot`. La Publicación servirá cualquier Build que lleve esa tag. **Configura la Visibilidad y la Seguridad** Para anillos internos, la combinación habitual es visibilidad **Activa** con seguridad **Privada** — las personas inician sesión con su cuenta de Applivery o con el SSO de tu Workspace. Usa **No listada** si prefieres compartir el anillo solo mediante URL directa. **Restringe el acceso** En **Control de acceso**, añade los Grupos de usuarios o Audiencias que pueden acceder a este anillo. Consulta [Cómo elegir quién recibe cada anillo](#cómo-elegir-quién-recibe-cada-anillo) más abajo. **Dale un slug reconocible** Por ejemplo `myapp-pilot`. La URL resultante es `yourworkspace.applivery.com/{slug}`. Acabas con una Publicación y una URL por anillo, cada una atenta a su propia tag. Para la lista completa de ajustes de Publicación, consulta [Distribuir Apps](https://docs.applivery.com/es/app-distribution/distribute/distribute-apps/). #### Desde la API El parámetro clave es `filter.type` configurado en `tag`, con `filter.value` conteniendo la tag del anillo. Referencia completa: [POST – Crear una Publicación](https://docs.applivery.com/es/app-distribution/api/publications/create-publication/). **Integrations API** — limitada a una sola App, autenticada con un App API Token: ```bash curl 'https://api.applivery.io/v1/integrations/distributions' \ -X POST \ -H 'Authorization: Bearer YOUR_APP_TOKEN' \ -H 'Content-Type: application/json' \ -d '{ "slug": "myapp-pilot", "security": "logged", "visibility": "active", "filter": { "type": "tag", "value": "ring-pilot" }, "groups": [["qa-team"]], "showHistory": true }' ``` **Workspace API** — a nivel de Workspace, autenticada con un token de Service Account: ```bash curl 'https://api.applivery.io/v1/organizations/ORG_ID/stores/STORE_ID/pubApps' \ -X POST \ -H 'Authorization: Bearer YOUR_SERVICE_ACCOUNT_TOKEN' \ -H 'Content-Type: application/json' \ -d '{ "slug": "myapp-production", "security": "logged", "visibility": "active", "filter": { "type": "tag", "value": "ring-production" }, "activateUserAudiences": true, "userAudienceMap": [ { "id": "AUDIENCE_ID", "notifyNewBuildsProcessed": true } ] }' ``` `security` acepta `public`, `password` o `logged`. `visibility` acepta `active`, `inactive` o `unlisted`. ### Cómo elegir quién recibe cada anillo El acceso a un anillo se controla mediante el **Control de acceso** de la Publicación, usando Grupos de usuarios o Audiencias. - Los **[Grupos de usuarios](https://docs.applivery.com/es/app-distribution/distribute/user-groups/)** son colecciones de personas seleccionadas a mano. Ideales para un anillo piloto, donde quieres nombrar a los testers exactos. - Las **[Audiencias](https://docs.applivery.com/es/app-distribution/distribute/user-audiences/)** se definen mediante reglas y se actualizan por sí solas a medida que las personas se incorporan o salen. Ideales para anillos más amplios, donde mantener una lista manual sería una tarea pesada. Un punto de partida razonable: | Anillo | Acceso típico | | --- | --- | | `ring-pilot` | Grupo de usuarios — equipo de QA, early adopters | | `ring-rollout` | Audiencia — un departamento como IT o Soporte | | `ring-production` | Audiencia — todo el mundo en el Workspace | Vía API, `groups` admite lógica AND/OR: cada array interno es una cláusula AND y cada elemento externo es una cláusula OR, de modo que `[["group1","group2"],["group3"]]` significa *group1 AND group2, OR group3*. Solo se aplica cuando `security` es `logged`. Para las Audiencias, configura `activateUserAudiences` en `true` y enuméralas en `userAudienceMap`. ### Promocionar un Build a través de los anillos La promoción no implica recompilar ni volver a subir nada. Es el mismo Build ganando tags: ```text Build #A (v2.0) 1) tags: ring-pilot → visible solo en piloto 2) tags: ring-pilot, ring-rollout → ahora también en despliegue 3) tags: ring-pilot, ring-rollout, ring-production → ahora también en producción ``` #### Desde el Dashboard **Abre el Build** Ve a **Builds** en tu App y selecciona el Build que quieres promocionar. **Añade la tag del siguiente anillo** Edita sus **Tags** y añade la tag del siguiente anillo. **Quita la tag del Build anterior** Si un Build más antiguo todavía lleva la tag de ese anillo, quítala para que el anillo sirva exactamente un Build. El Build aparece en la Publicación de ese anillo en cuanto guardas. #### Desde la API Usa [PUT – Actualizar un Build](https://docs.applivery.com/es/app-distribution/api/builds/update-build/). :::warning El campo `tags` **reemplaza el array completo**. Incluye todas las tags que el Build deba conservar — si envías solo la tag nueva, todas las demás se eliminan. ::: ```bash curl 'https://api.applivery.io/v1/integrations/builds/BUILD_ID' \ -X PUT \ -H 'Authorization: Bearer YOUR_APP_TOKEN' \ -H 'Content-Type: application/json' \ -d '{ "tags": ["ring-pilot", "ring-rollout"] }' ``` El equivalente en la Workspace API es `PUT https://api.applivery.io/v1/organizations/ORG_ID/apps/APP_ID/builds/BUILD_ID` con un token de Service Account. :::tip Mantén la tag de cada anillo en **un solo Build a la vez**. Cuando promociones un Build nuevo a un anillo, quita la tag del anterior. Así la versión que sirve cada anillo nunca es ambigua. ::: ### ¿Un Build para todos los anillos, o un Build por anillo? Es preferible **un único Build promocionado a través de los anillos**. | Enfoque | Qué significa | Recomendación | | --- | --- | --- | | Un Build → varios anillos | Compilas y subes una vez; el mismo binario avanza ganando tags | Preferido | | Un Build por anillo | Compilas y subes un Build distinto para cada anillo | Solo para casos concretos | El enfoque de un único Build gana por tres razones: - **Publicas lo que probaste.** El binario exacto que validó tu grupo piloto es el que recibe producción — sin recompilaciones intermedias que introduzcan diferencias. - **Los metadatos de versión se mantienen coherentes.** Applivery lee la información de versión del propio paquete, así que un Build significa un único conjunto de valores de versión en todos los anillos. - **La trazabilidad es sencilla.** Una versión equivale a un Build equivale a un historial. Subir un Build distinto por anillo solo tiene sentido cuando los anillos realmente necesitan binarios diferentes — configuraciones de compilación distintas, endpoints distintos incrustados en tiempo de compilación, y similares. En caso contrario, promociona por tag. ### Definir la tag inicial al subir el Build Puedes ahorrarte un paso etiquetando un Build en el primer anillo al subirlo. Esto encaja de forma natural con un pipeline de CI, que sube el resultado y lo deja directamente en piloto: ```bash curl 'https://upload.applivery.io/v1/integrations/builds' \ -X POST \ -H 'Authorization: Bearer YOUR_APP_TOKEN' \ -F 'build=@myapp.aab' \ -F 'versionName=v2.0' \ -F 'tags=ring-pilot' \ -F 'changelog=Sprint 42 release' ``` La respuesta incluye el `id` del Build, que necesitarás para volver a etiquetarlo más adelante. Consulta [POST – Subir un Build](https://docs.applivery.com/es/app-distribution/api/builds/upload-build/) para la lista completa de parámetros. ### Checklist - Una Publicación por anillo, cada una con **selección de Build = Tags**. - Una convención de nombres de tags acordada y anotada, sin comas. - Control de acceso configurado por anillo — Grupos para el piloto, Audiencias para los anillos más amplios. - CI sube los Builds nuevos ya etiquetados en el primer anillo. - Promocionar consiste en añadir la tag del siguiente anillo al mismo Build, y quitarla del anterior. --- ## Revertir una versión Source: https://docs.applivery.com/es/app-distribution/distribute/roll-back-a-release/ Description: Revierte un Build problemático en Applivery App Distribution recompilando tu versión estable con un identificador de versión superior y moviendo la tag de la Publicación hacia él. TL;DR: Recompila tu última versión estable con un identificador de versión superior, súbela y mueve la tag del anillo al nuevo Build. Recuerda reducir el umbral de actualización forzada del SDK si usas uno. Answers: ¿Cómo revierto una versión en Applivery? · ¿Puedo simplemente reetiquetar el Build anterior en lugar de recompilar? · ¿Por qué se llama roll forward? · ¿Necesito cambiar la versión que ven los usuarios? · ¿Qué pasa si olvido reducir el umbral de actualización forzada? Key topics: Procedimiento de reversión, Identificadores de versión, Tags de Build, Actualizaciones forzadas, Applivery, Builds, Publicaciones, SDK de Applivery Has publicado una versión, algo va mal en ella y necesitas que la gente vuelva a la versión que funcionaba. El instinto es volver a poner en circulación el Build anterior — pero eso no basta por sí solo, porque quién acepta una versión más antigua lo decide el sistema operativo, no Applivery. La forma fiable de revertir una versión es **avanzar** (roll-forward): toma el código de la última versión que funcionó, recompílalo con un identificador de versión **superior** al del Build problemático y distribúyelo. El código va hacia atrás; el número de versión va hacia delante. Para el dispositivo es una actualización normal, y por eso precisamente se instala. :::info Este enfoque funciona en todas las plataformas a las que Applivery distribuye. Algunas plataformas también aceptarían una bajada de versión directa, pero el roll-forward es el único procedimiento que es seguro en todas partes — así que es el que merece la pena estandarizar. ::: ### Por qué no puedes simplemente volver a servir el Build antiguo En Android, el gestor de paquetes del sistema se niega a instalar un paquete cuyo `versionCode` es inferior al ya instalado. La instalación falla con `INSTALL_FAILED_VERSION_DOWNGRADE`. La [documentación del manifiesto](https://developer.android.com/guide/topics/manifest/manifest-element) de Android expone la regla con claridad: cada versión sucesiva debe llevar un número más alto. Así que si reetiquetas el Build antiguo, cualquiera que ya instaló la versión problemática se queda atascado en ella. Las personas a las que más necesitas arreglar son precisamente aquellas a las que el Build antiguo no puede llegar. Recompilar con un identificador de versión superior evita esto por completo. ### El identificador de versión en cada plataforma Applivery **lee** la información de versión del paquete que subes — no es algo que puedas definir en el Dashboard ni pasar a la API. Tiene que definirse en tiempo de compilación. | Plataforma | Qué incrementar | Formato | | --- | --- | --- | | Android | `versionCode` en tu configuración de compilación | Entero — `201` | | iOS / macOS | `CFBundleVersion` en el Info.plist de la app | De uno a tres enteros separados por puntos — `2.0.1` | | Windows (MSIX / APPX) | Versión en `AppxManifest.xml` | Versión de cuatro partes | | Plataformas personalizadas | `packageVersion` al subir | Manual | :::warning El `CFBundleVersion` de Apple **no** es un entero simple como el `versionCode` de Android. Es una cadena de hasta tres enteros separados por puntos, así que "sumar uno" no tiene sentido por sí solo. Si el Build problemático es `2.0.0`, tu Build de reversión debería ser `2.0.1` o superior. Consulta la [referencia de CFBundleVersion](https://developer.apple.com/documentation/bundleresources/information-property-list/cfbundleversion) de Apple. ::: La versión visible para el usuario — `versionName` en Android, `CFBundleShortVersionString` en Apple — no tiene reglas técnicas. Úsala para que la situación sea legible: mantener `1.9` deja claro qué código se está ejecutando, mientras que `2.0.1` deja claro que es más nueva que la versión que reemplaza. Elige la que a tus usuarios les resulte menos confusa. ### El procedimiento **Identifica la última versión estable conocida** Localiza el código fuente de la versión a la que vas a revertir y confirma el identificador de versión del Build problemático para saber qué tienes que superar. **Recompílala con un identificador de versión superior** Mismo código, nuevo identificador de versión — superior al del Build problemático. Esto ocurre en la configuración de tu proyecto o en tu pipeline de CI, no en Applivery. **Sube el Build recompilado** Dale un `versionName` que deje claro su propósito, como `v1.9 (rollback)`. Espera a que termine el procesamiento antes de continuar. **Quita la tag del Build problemático** Abre el Build problemático y quita la tag de la Publicación afectada. Deja de servirse de inmediato. **Añade la tag al Build de reversión** La Publicación ahora sirve el Build de reversión, y los dispositivos lo ven como una actualización disponible. **Reduce el umbral de actualización forzada, si usas uno** Consulta [Cuidado con las actualizaciones forzadas](#cuidado-con-las-actualizaciones-forzadas) más abajo. Saltarte este paso puede dejar a los usuarios completamente bloqueados fuera de la app. #### Ejemplo práctico ```text Problema: Build v2.0 · versionCode 200 · activo en producción · defecto detectado Reversión: Recompila el código v1.9 · versionCode 201 (superior a 200) Sube, y luego mueve la tag de producción del Build 200 al Build 201 ``` Un dispositivo que está en `200` recibe `201`, lo trata como una actualización y lo instala — pero el código que acaba ejecutando es la lógica estable de la 1.9. #### Desde la API Ambos cambios de tag usan [PUT – Actualizar un Build](https://docs.applivery.com/es/app-distribution/api/builds/update-build/). :::warning El campo `tags` **reemplaza el array completo**. Envía todas las tags que el Build deba conservar, no solo la que estás cambiando. ::: ```bash ## 1. Deja de servir el Build problemático curl 'https://api.applivery.io/v1/integrations/builds/BUILD_ID_PROBLEM' \ -X PUT \ -H 'Authorization: Bearer YOUR_APP_TOKEN' \ -H 'Content-Type: application/json' \ -d '{ "tags": [] }' ## 2. Apunta el anillo al Build de reversión curl 'https://api.applivery.io/v1/integrations/builds/BUILD_ID_ROLLBACK' \ -X PUT \ -H 'Authorization: Bearer YOUR_APP_TOKEN' \ -H 'Content-Type: application/json' \ -d '{ "tags": ["ring-production"] }' ``` El equivalente en la Workspace API es `PUT https://api.applivery.io/v1/organizations/ORG_ID/apps/APP_ID/builds/BUILD_ID` con un token de Service Account. Si usas [despliegue progresivo](https://docs.applivery.com/es/app-distribution/distribute/progressive-deployment/), revierte un anillo cada vez, empezando por el anillo donde apareció el problema. ### Los dispositivos Apple se comportan de forma distinta según cómo se instaló la app Apple no documenta qué ocurre cuando instalas una app cuyo `CFBundleVersion` es inferior al que ya está en el dispositivo, así que lo probamos nosotros mismos. En **iOS 26.5**, la misma app en el mismo dispositivo se comportó de dos formas opuestas según la vía de entrega: | Cómo llega la app al dispositivo | Instalar un Build más antiguo | | --- | --- | | **App Distribution** — el usuario instala desde la Enterprise Store | El Build más antiguo se instala con normalidad | | **Device Management** — Build asignado mediante MDM | El dispositivo mantiene la versión más nueva | :::warning Cuando se asigna un Build más antiguo mediante Device Management, el dispositivo **no** baja de versión — y **tampoco** informa de ningún error. El comando se acepta, nada falla y la versión más nueva simplemente permanece instalada. Si estás revirtiendo por esta vía, el Dashboard no te avisará de que no ha pasado nada. Verifica la versión instalada antes de dar por hecho que los dispositivos están arreglados. ::: La consecuencia práctica: - Si distribuyes mediante la **Enterprise Store**, puedes revertir simplemente moviendo la tag de vuelta al Build anterior. Sin necesidad de recompilar. - Si despliegas mediante **Device Management**, mover la tag no basta. Tienes que recompilar con un identificador de versión superior, exactamente como se describe arriba. :::info Este comportamiento no está documentado por Apple, lo que significa que no está garantizado que se mantenga igual en futuras versiones de iOS. Nuestra prueba cubrió un dispositivo supervisado inscrito mediante Apple Business. Trata el atajo de la Enterprise Store como una comodidad, no como algo sobre lo que construir automatización — el procedimiento de roll-forward es el que sigue funcionando en cualquier caso. ::: ### Cuidado con las actualizaciones forzadas Si tu App integra el [SDK de Applivery](https://docs.applivery.com/es/app-distribution/sdk/) con las actualizaciones forzadas activadas, aquí hay una trampa que conviene conocer. Las actualizaciones forzadas bloquean el uso de la app cuando la versión instalada queda por debajo de un **umbral de versión mínima** que configuras en el Dashboard. Si ese umbral sigue apuntando a la versión problemática, tu Build de reversión queda por debajo de él — y cada usuario que lo instale queda bloqueado fuera de la app por el mismísimo arreglo que publicaste. **Reduce el umbral como parte de la reversión, no después de ella.** Una cosa juega a tu favor: el SDK siempre actualiza al **Build más reciente disponible** para la App, que coincida solo con el bundle ID o el package name. Se guía por la recencia, no por el número de versión, así que un Build de reversión recién subido se recoge como la actualización independientemente de dónde se sitúe su versión. :::info El SDK no respeta los filtros, grupos ni audiencias de las Publicaciones. Si necesitas que la reversión se limite a un anillo, ten en cuenta que las actualizaciones impulsadas por el SDK no respetan ese límite. ::: ### Después de la reversión - **Conserva el Build problemático.** No lo elimines — lo querrás para reproducir el defecto. Quitarle la tag basta para sacarlo de circulación. - **Cuida los números de versión de ahí en adelante.** Tu siguiente versión real tiene que superar al Build de reversión, no al problemático. Si la reversión fue `201`, la versión corregida empieza en `202`. - **Avisa a la gente.** Si la Publicación notifica a su audiencia, un mensaje explícito acelera las cosas — los usuarios que pospusieron la actualización anterior podrían ignorar también esta. :::tip La forma más limpia de no necesitar esto nunca es detectar el defecto antes en un anillo pequeño. Consulta [Despliegue progresivo con tags](https://docs.applivery.com/es/app-distribution/distribute/progressive-deployment/). ::: --- ## Audiencias de usuarios Source: https://docs.applivery.com/es/app-distribution/distribute/user-audiences/ Description: Usa las Audiencias de Applivery para gestionar la distribución de apps, controlar el acceso de los usuarios y personalizar las notificaciones de Builds por versión. TL;DR: Las audiencias de Applivery permiten un control granular sobre la distribución de apps definiendo grupos de usuarios y asignándoles apps, builds o publicaciones. Answers: ¿Qué son las Audiencias de Applivery? · ¿Cómo creo una Audiencia en Applivery? · ¿Cuál es la diferencia entre Audiencias de Workspace y de App? · ¿Cómo asigno una Audiencia a una Publicación? Las Audiencias son una funcionalidad de Applivery que te permite controlar el acceso a las [Publicaciones](https://docs.applivery.com/es/app-distribution/distribute/distribute-apps/) de forma escalable y dinámica. En lugar de gestionar el acceso usuario por usuario, las Audiencias te permiten definir un conjunto de usuarios basado en condiciones —los [grupos](https://docs.applivery.com/es/app-distribution/distribute/user-groups/) a los que pertenecen, sus direcciones de email, o ambos— y asignar ese conjunto a una o más Publicaciones en un solo paso. Dado que las Audiencias son basadas en condiciones, su pertenencia se actualiza automáticamente a medida que se añaden usuarios a tu Workspace o App. Esto las hace especialmente potentes cuando se combinan con SSO y el [aprovisionamiento SCIM](https://docs.applivery.com/es/device-management/integrations/sso/scim-attributes-mapping/), donde los cambios en el directorio de usuarios se propagan automáticamente sin ninguna gestión manual de Audiencias. En resumen, una Audiencia define quién puede ver, acceder y descargar Builds de una Publicación concreta. ![audiences](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/7661e1b1-0316-41f3-88c8-046010169753.png) :::warning Pertenecer a una Audiencia no define el rol de un usuario como Colaborador o Empleado. Las Audiencias no pueden contener roles (Admin, Editor, Visor, etc.). Los roles deben asignarse individualmente a nivel de Workspace o de App. Consulta [Gestionar usuarios](https://docs.applivery.com/es/app-distribution/distribute/manage-users/) para más información. ::: * * * ### Conceptos clave El **alcance de la Audiencia** define dónde puede gestionarse una Audiencia y dónde estará disponible para su asignación: - Las Audiencias de **alcance Workspace** están disponibles en todo el Workspace. Opcionalmente puedes restringir qué Apps pueden usarlas. - Las Audiencias de **alcance App** solo están disponibles dentro de una App específica. El **ámbito de búsqueda de usuarios** determina dónde busca Applivery cuando resuelve qué usuarios pertenecen a una Audiencia: - **Workspace**: Busca en todos los usuarios del Workspace. - **App**: Busca solo entre los usuarios de una App específica. Al crear una Audiencia de alcance Workspace, el ámbito de búsqueda siempre es Workspace. Al crear una Audiencia de alcance App, puedes elegir buscar dentro de la App o ampliar la búsqueda a todo el Workspace. * * * ### Crear una Audiencia Las Audiencias pueden crearse desde dos lugares: - **Nivel de Workspace:** Ve a la sección **Configuración** y selecciona **Audiencias de usuarios** en el menú lateral izquierdo. - **Nivel de App:** Ve a **App > Audiencias**. Haz clic en **\+ Crear Audiencia** y rellena las siguientes secciones: **Configuración** | Campo | Descripción | | --- | --- | | **Nombre** | Un nombre claro y descriptivo para la Audiencia. | | **Descripción** | Opcional. Útil para documentar el propósito de la Audiencia. | | **Alcance de la Audiencia** | Elige **Workspace** o **App**. Si es Workspace, puedes restringir adicionalmente en qué Apps estará disponible esta Audiencia. | **Segmentación de usuarios** | Campo | Descripción | | --- | --- | | **Ámbito de búsqueda de usuarios** | Elige **Workspace** o **App** para definir dónde busca Applivery los usuarios coincidentes. | | **Grupos** | Añade uno o más Grupos de usuarios con lógica `AND` / `OR` para definir las condiciones de pertenencia. La pertenencia se actualiza automáticamente a medida que cambia la de los grupos. | | **Emails** | Añade usuarios individuales por dirección de email. Funciona tanto para usuarios existentes como para nuevos. Al añadir un usuario que aún no pertenece al Workspace o a la App, aparece un botón de invitación para enviarle una invitación con un solo clic. | :::tip A medida que configuras las condiciones, en la parte inferior de la pantalla aparece una vista previa en tiempo real de los usuarios coincidentes, para que puedas verificar que la Audiencia se resuelve como se espera antes de guardar. ::: Haz clic en **Guardar** cuando hayas terminado. * * * ### Explorar los usuarios de una Audiencia Para ver qué usuarios coinciden actualmente con una Audiencia, abre la lista de Publicaciones, haz clic en el menú de **tres puntos verticales** junto a la Publicación y selecciona **Ver usuarios**. Esto muestra una lista de todos los usuarios que satisfacen las condiciones de la Audiencia en ese momento. También puedes acceder a esta información directamente desde la vista de lista de Audiencias: - Haz clic en el campo **Usuarios** de cualquier fila de Audiencia para ver los usuarios a los que apunta. - Haz clic en el campo **Pubs** para ver qué Publicaciones están usando esa Audiencia. ![Publication audience](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/eccb266b-0bb9-4691-a0c7-225448582854.png) * * * ### Asignar Audiencias a Publicaciones Las Audiencias se usan para controlar el acceso a Publicaciones privadas. Para asignar una: 1. Crea o edita una Publicación. 2. Establece la **Seguridad** en **Privada**. 3. En la sección **Acceso**, selecciona **Audiencias**. 4. Añade una o más Audiencias a la Publicación. Los usuarios que pertenezcan a cualquiera de las Audiencias asignadas podrán ver y descargar Builds de esa Publicación. Los usuarios fuera de la Audiencia no tendrán acceso. ![assign audience to Publication](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/7e062b8f-5750-421f-9262-5aed657ed7a9.png) * * * ### Ver las Publicaciones asociadas a una Audiencia Para ver en qué Publicaciones está asignada actualmente una Audiencia, abre la página de detalle de la Audiencia y haz clic en el recuento de Publicaciones que aparece en la parte superior de la pantalla. Esto te da una lista completa de todas las Publicaciones que referencian esa Audiencia. ![audience assigned to a Publication](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/83395703-aa64-4bbe-9485-36526b02f896.png) * * * ### Notificaciones de Builds Al crear o editar una Audiencia, puedes controlar si sus miembros reciben notificaciones por email cuando se publican nuevas Builds. Usa el **icono de campana** (🔔) junto al nombre de la Audiencia para activar o desactivar las notificaciones por Audiencia. Dos aspectos importantes a tener en cuenta: - **Las preferencias a nivel de usuario tienen prioridad.** Si un usuario individual ha desactivado las notificaciones en su configuración personal, el ajuste a nivel de Audiencia no lo anulará. - **Los ajustes de notificación a nivel de App también se aplican.** Puedes desactivar las notificaciones completamente para Colaboradores o Empleados a nivel de App yendo a **App > Ajustes > Notificaciones**. Esto anula los ajustes de notificación a nivel de Audiencia. * * * ### Buenas prácticas - **Usa los grupos como mecanismo de segmentación principal.** Las condiciones basadas en grupos se actualizan automáticamente, manteniendo tus Audiencias precisas sin intervención manual, lo que es especialmente valioso con integraciones SSO y SCIM. - **Usa la segmentación por email para excepciones.** Añade individuos por email cuando necesites conceder acceso a alguien fuera de tus grupos estándar, como una parte interesada externa o un revisor puntual. - **Prefiere las Audiencias de alcance Workspace para la reutilización.** Si el mismo conjunto de usuarios necesita acceso a varias Apps o Publicaciones, una Audiencia de alcance Workspace evita duplicaciones y mantiene la gestión centralizada. - **Usa Audiencias de alcance App para el aislamiento.** Cuando una Audiencia es específica de una sola App y no debe reutilizarse en otros lugares, el alcance de App mantiene las cosas ordenadas y evita asignaciones accidentales a Publicaciones no relacionadas. - **Verifica la pertenencia antes de guardar.** Usa la vista previa de usuarios en tiempo real en la parte inferior del editor de Audiencias para confirmar que las condiciones se resuelven correctamente antes de publicar la Audiencia. --- ## Grupos de usuarios Source: https://docs.applivery.com/es/app-distribution/distribute/user-groups/ Description: Usa el control de acceso basado en grupos de Applivery para la distribución de apps. Combina lógica AND/OR e intégralo con SSO (LDAP/SAML). TL;DR: Applivery te permite controlar la distribución de apps otorgando acceso según la pertenencia a grupos de usuarios, simplificando la gestión de equipos grandes. Answers: ¿Cómo controla Applivery el acceso a las Publicaciones privadas de la Enterprise Store? · ¿Cómo configuro el acceso basado en grupos en Applivery? · ¿Cómo sincroniza Applivery los grupos de usuarios con los proveedores SSO? · ¿Cuándo se actualiza la pertenencia a grupos en Applivery? Applivery te permite controlar el acceso a las Publicaciones de tu Enterprise Store con reglas basadas en grupos de gran precisión, combinando lógica `AND` y `OR` para adaptarse a cualquier escenario de distribución. * * * ### Descripción general La distribución de apps admite tres modos de seguridad de acceso para las Publicaciones: Pública, Contraseña y Privada. Cuando una Publicación se establece como **Privada**, los usuarios deben autenticarse antes de acceder a ella, ya sea mediante su cuenta de Applivery o una integración de Single Sign-On (SSO) personalizada. Más allá de la autenticación, el modo Privado también te permite restringir el acceso a **Grupos de usuarios** específicos. Solo los usuarios que pertenezcan a los grupos configurados obtendrán acceso tras un inicio de sesión exitoso; el resto será denegado, incluso con credenciales válidas. :::info Para un resumen completo de las opciones de seguridad de las Publicaciones, consulta [Cómo distribuir tus Apps](https://docs.applivery.com/es/app-distribution/distribute/distribute-apps/). ::: * * * ### Configurar el acceso basado en grupos Puedes añadir tantos grupos como necesites y combinarlos usando lógica `AND` y `OR`: - **Los grupos en la misma línea** se tratan como `AND`: el usuario debe pertenecer a **todos** ellos. - **Cada nueva línea** se trata como `OR`: el usuario debe satisfacer **al menos una** de las líneas. #### Ejemplo Para conceder acceso a los usuarios que pertenecen tanto a `grupoUno` como a `grupoDos`, **o** a los usuarios que pertenecen a `grupoTres`: ``` grupoUno, grupoDos grupoTres ``` Esto se lee como: _(grupoUno AND grupoDos) OR (grupoTres)_. Un usuario solo en `grupoUno` **no** tendría acceso. Un usuario solo en `grupoTres` **sí** tendría acceso. Un usuario en `grupoUno` y `grupoDos` **sí** tendría acceso. ![groups](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/31745035-443c-407d-b32e-0d130acc0029.png) * * * ### Sincronización de grupos Single Sign-On (LDAP y SAML) Cuando tu Enterprise Store está conectada a un proveedor SSO —mediante **LDAP** o **SAML**— Applivery captura y sincroniza automáticamente la pertenencia a Grupos de usuarios desde tu directorio de usuarios, incluidos los grupos definidos como Unidades Organizativas (UOs). #### Cómo funciona la sincronización La sincronización de grupos se produce **cada vez que un usuario inicia sesión**. En ese momento, Applivery lee las pertenencias a grupos actuales del usuario desde tu directorio y las actualiza en la plataforma. Para distinguir los grupos procedentes de SSO de los grupos creados directamente en Applivery, los grupos sincronizados reciben automáticamente un prefijo: | Origen | Prefijo | Ejemplo | | --- | --- | --- | | LDAP | `ldap:` | `ldap:engineering`, `ldap:qa-team` | | SAML | `saml:` | `saml:developers`, `saml:beta-testers` | | Applivery (nativo) | _(ninguno)_ | `grupoUno`, `grupoTres` | Esto hace que sea sencillo usar grupos SSO en tus reglas de acceso junto a grupos nativos de Applivery. Simplemente referencíalos con su prefijo, por ejemplo: ``` saml:qa-team, saml:mobile-testers ldap:contractors ``` #### Comportamiento importante :::warning **La sincronización de grupos se desencadena con el inicio de sesión.** Todas las pertenencias a grupos de un usuario se sobreescriben en cada nuevo inicio de sesión según el estado actual de tu directorio de usuarios. Si añades o eliminas un usuario de un grupo en tu directorio, el cambio **no** se reflejará en Applivery hasta que ese usuario inicie sesión de nuevo en tu Enterprise Store. ::: Esto significa que: - Eliminar un usuario de un grupo en tu directorio no revoca inmediatamente su acceso en Applivery. - Añadir un usuario a un nuevo grupo en tu directorio no le concede inmediatamente acceso en Applivery. - En ambos casos, el cambio surte efecto en el **próximo inicio de sesión** del usuario. * * * ### Buenas prácticas - Usa **grupos con prefijo SSO** (`ldap:` / `saml:`) para reglas de acceso que deban mantenerse sincronizadas automáticamente con tu directorio corporativo. - Usa **grupos nativos de Applivery** para reglas de distribución gestionadas de forma independiente a tu directorio, como testers beta internos o acceso específico de proyecto. - Al revocar el acceso, ten en cuenta el comportamiento de sincronización desencadenada por el inicio de sesión. Si la revocación inmediata es crítica, elimina la cuenta del usuario directamente en Applivery, además de actualizar tu directorio. --- ## Primeros pasos Source: https://docs.applivery.com/es/app-distribution/getting-started/ Description: Distribuye apps empresariales internas, gestiona pruebas beta y publica Builds en producción con la plataforma segura de Applivery. TL;DR: Aprende cómo empezar con la distribución de apps usando Applivery, incluyendo el acceso al panel, la gestión de usuarios y la personalización de la Store Enterprise. Answers: ¿Qué es la Distribución de Apps de Applivery? · ¿Cómo accedo al panel de Applivery? · ¿Quiénes son los Empleados de la tienda en Applivery? · ¿Qué tipos de archivo admite Applivery para subir apps? · ¿Qué puedo personalizar en el Enterprise Store? · ¿Qué son las Audiencias de usuario en Applivery? · ¿Cómo puedo habilitar plataformas de build adicionales en Applivery? · ¿Qué es la Store Enterprise de Applivery? Key topics: Panel de Applivery, Store Enterprise, Gestión de usuarios, Flujo de trabajo de distribución de apps, Applivery, Apple, Android, Windows La **Distribución de Apps** es una de las capacidades principales de Applivery. Tanto si necesitas distribuir apps empresariales internas, gestionar programas de pruebas beta o publicar Builds listas para producción para tus empleados, Applivery ofrece una plataforma centralizada y segura para optimizar todo el proceso. ### Acceso al panel de Applivery El **panel de Applivery** es la consola de administración donde tú y tu equipo gestionáis todo lo relacionado con la distribución de aplicaciones. Está disponible en [https://dashboard.applivery.io](https://dashboard.applivery.io). Los usuarios con acceso al panel se denominan **Colaboradores**. Los Colaboradores pueden tener distintos roles y permisos, como acceso administrativo o de desarrollo, según sus responsabilidades en el proyecto. Los usuarios finales, denominados **Empleados de la tienda**, no acceden al panel. En su lugar, acceden al **Enterprise Store** de tu organización, donde pueden descargar las aplicaciones que se les han puesto a disposición. :::info Puedes encontrar más información sobre los tipos de usuario en el siguiente artículo de [nuestra documentación](https://docs.applivery.com/es/app-distribution/distribute/manage-users/). ::: Empezar con Applivery es sencillo. Una vez creado tu Workspace, puedes empezar a organizar tus aplicaciones y publicarlas para tus usuarios. #### El Dashboard La interfaz del panel de Applivery está organizada en varias secciones principales que te permiten gestionar tus aplicaciones y flujos de trabajo de distribución de forma eficiente. ##### Resumen La sección Resumen es la página principal de tu Workspace. Aquí encontrarás: - Estadísticas de descargas y actividad de builds. - Informes y datos de uso. - Métricas de empleados. - Información general sobre tu plan de suscripción. Esta sección ofrece una visión general de tu actividad de distribución y del rendimiento global de tu Workspace. ![app distribution](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/37dd3bfe-5214-481e-a8e3-af36377a488e.png) ##### Apps Una **App** en Applivery representa el contenedor de tu proyecto. Cada App puede almacenar Builds para múltiples plataformas, incluyendo: - Apple (`.ipa`, `.pkg`, `.dmg`). - Android (`.apk`, `.aab`). - Windows (`.msi`, `.exe`, `.msix`, `.appx`, `.msixbundle`, `.appxbundle`). - [Plataformas de build personalizadas](https://docs.applivery.com/es/app-distribution/platforms/custom-platforms/). Desde esta sección puedes: - Crear nuevas aplicaciones. - Subir y gestionar Builds. - Actualizar versiones existentes. - Configurar los ajustes de distribución. Tienes control total sobre tus Apps y puedes decidir si crear una nueva App para cada proyecto o reutilizar una existente, según tu estrategia de lanzamiento. La sección Apps actúa como el repositorio técnico de tus binarios y versiones. ![Apps app distribution](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/fd213c28-8e5b-4226-8ba4-53340a3d37ad.png) ##### Store Enterprise Desde esta sección puedes: - Crear nuevas Publicaciones. - Editar las existentes. - Controlar qué Apps son visibles para qué usuarios. - Gestionar las estrategias de despliegue de versiones. ![enteprise store section](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/839b496e-6eea-4019-8df3-3844dd2f593b.png) ##### Directorio y configuración La sección **Directorio y configuración** centraliza la gestión de usuarios, el control de acceso y los ajustes a nivel de Workspace en Applivery. Desde esta sección, los administradores pueden gestionar tanto a los Colaboradores internos como a los usuarios finales, definir la segmentación por audiencia y configurar las opciones de personalización del Enterprise Store. - **Colaboradores**: usuarios que **tienen acceso al panel de Applivery**. Se les pueden asignar distintos roles y niveles de permisos según sus responsabilidades, como acceso administrativo, gestión de Apps o tareas de desarrollo. Una asignación correcta de roles garantiza flujos de trabajo operativos seguros y evita cambios no autorizados en el Workspace. - **Empleados de la tienda**: los usuarios finales que **acceden al Enterprise Store** para descargar aplicaciones. No tienen acceso al panel, pero pueden autenticarse en la tienda según el método de acceso configurado. Los administradores pueden gestionar las cuentas de los empleados de forma individual o mediante integraciones de directorio, según la configuración de la organización. - **Audiencias de usuario**: esta función permite a los administradores agrupar empleados según sus atributos. Estas audiencias se pueden usar para controlar la visibilidad de las Apps en el Enterprise Store, restringir el acceso a Builds específicos y definir estrategias de distribución segmentada. Esto permite un control granular de la distribución y da soporte a estructuras organizativas complejas. :::info Puedes encontrar más información sobre las Audiencias de usuario en el siguiente artículo de [nuestra documentación](https://docs.applivery.com/es/app-distribution/distribute/user-audiences/). ::: - **Personalización de la tienda**: el Enterprise Store se puede personalizar completamente para adaptarse a la imagen corporativa. Desde esta sección, los administradores pueden configurar el logotipo y los recursos de marca, los temas de color, el nombre de la tienda y la seguridad. Esto garantiza una experiencia de marca coherente a la vez que se mantiene la seguridad de nivel empresarial. - **Plataformas de build**: esta sección muestra qué plataformas están actualmente habilitadas a nivel de Workspace (Apple, Android, Windows o plataformas personalizadas). :::warning Por defecto, **iOS y Android** están disponibles para todos los planes. Los administradores del Workspace no pueden habilitar nuevas plataformas por su cuenta. Si necesitas plataformas adicionales, debes contactar con el soporte de Applivery a través de [**support@applivery.com**](mailto:support@applivery.com) o del **chat de la app**. ::: ![build platforms](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/50fd1029-f420-41cd-92e5-baaec630f1c1.png) #### La Store Enterprise La **Store Enterprise** es la tienda de apps privada de tu organización. Aquí es donde tus aplicaciones publicadas están disponibles para los usuarios finales (Empleados de la tienda). Es una tienda de apps web que: - Admite múltiples configuraciones de autenticación y seguridad. - Es totalmente personalizable para adaptarse a tu imagen corporativa. - Permite un control granular de la visibilidad de las apps. ![enterprise app store](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/122d1d74-563d-40a6-ba7a-8f8e4b62f6a0.png) --- ## Guía para la Store en Android Source: https://docs.applivery.com/es/app-distribution/getting-started/android-app-store-guide/ Description: Accede, navega e instala apps desde la Store Enterprise de Applivery de tu organización en Android. Cubre inicio de sesión, recuperación de contraseña y opciones de compartir. TL;DR: Esta guía explica cómo acceder, navegar e instalar apps desde la Store Enterprise de Applivery de tu organización en Android. Answers: ¿Cómo inicio sesión en la Store Enterprise? · ¿Qué hago si olvidé la contraseña de la Store Enterprise? · ¿Cómo encuentro una app concreta en la Store Enterprise? · ¿Cómo cambio el idioma en la Store Enterprise? · ¿Cómo puedo compartir una app con alguien? · ¿Cómo instalo una app desde la Store Enterprise? · ¿Cómo añado la Store Enterprise a la pantalla de inicio de mi teléfono? · ¿Qué hago si me aparece la alerta 'Orígenes desconocidos' al instalar una app? Key topics: Inicio de sesión en la Store Enterprise, Navegación por la Store Enterprise, Instalación de apps, Recuperación de contraseña, Opciones de compartir, Applivery, Android, Google Play Protect, Google Chrome ### Acceso e inicio de sesión En ocasiones deberás autenticarte para acceder a la Store Enterprise o a una App concreta. Según la configuración de tu organización, habrá una o varias opciones de autenticación: 1. **Inicio de sesión tradicional o LDAP:** introduce tu correo electrónico o nombre de usuario corporativo y contraseña. Luego haz clic en el botón verde **Siguiente** para continuar. 2. **Single Sign-On:** si está disponible, aparecerá un botón verde con el texto **Iniciar sesión con [nombre de empresa]** en la parte superior de la pantalla de inicio de sesión. Haz clic en él y serás redirigido a la pantalla de SSO donde podrás introducir de forma segura tus credenciales corporativas. ![login android](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/9b8f1aaa-79ed-464b-8306-c0d4f55b2479.png) #### Recuperar contraseña Si has perdido tu contraseña, haz clic en el enlace **Olvidé mi contraseña** en la pantalla de inicio de sesión e **introduce tu dirección de correo electrónico** en el cuadro emergente. Recibirás un correo con las instrucciones para restablecer tu contraseña. ![forgot password android](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/b7d3c7c3-20e0-4e10-93f7-b52e56a8cb1b.png) ### Navegación, búsqueda, idioma y opciones de compartir #### Navegación Una vez que accedas a la Store Enterprise, todas las Publicaciones que tienes permiso para ver aparecerán listadas en la sección **Apps**. Puedes ajustar cómo se muestran: por **Publicación**, **App** o **Build**. ![store display](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/cc3d85e5-db72-4ecd-ab1a-ad431ca6c11b.png) #### Buscar apps Puedes filtrar la lista de Apps haciendo clic en el icono de lupa en la parte superior. Según la pestaña en la que estés, encontrarás varias opciones de filtro, incluyendo **versión**, **código de versión**, **slug**, **etiquetas**, **nombre del paquete** y **registro de cambios**. ![filter options android](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/3e3ffd20-a34d-4808-97a4-3dee5057b39b.png) #### Cambiar idioma Applivery está disponible en 10 idiomas diferentes. Detecta automáticamente el idioma predeterminado de tu sistema operativo y lo aplica si está disponible. Si no, se seleccionará automáticamente el idioma predeterminado (inglés). Puedes cambiar el idioma en cualquier momento desde el menú **Más opciones > Cambiar idioma** en la esquina superior derecha de la Store Enterprise. ![change language android](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/7536a043-9990-4b56-a614-84b06d952fa5.png) #### Opciones de compartir Puedes compartir el enlace a una App de varias formas (código QR, URL o a través de tus apps nativas favoritas). Una vez dentro de una App, sigue estos pasos: **Abre el menú de más opciones de la App** Toca **Más opciones** en el menú superior derecho. **Selecciona la opción Compartir** En el menú desplegable, selecciona la opción **Compartir**. **Elige tu método de compartir** Se mostrarán todas las opciones de compartir, incluyendo una URL única y un código QR. También puedes tocar la opción **Compartir con…** para mostrar las opciones de compartir nativas y compartir la App con otros a través de las apps sociales instaladas en tu dispositivo. ![share android](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/8d949d03-bdf9-4259-9dda-c1a3d85e0b46.png) ### Instalar apps Una vez dentro de una App en la Store Enterprise: **Toca el botón Instalar** Toca el botón verde **Instalar**. **Confirma la descarga** Aparecerá una alerta en la parte inferior de la pantalla pidiendo confirmación para descargar el archivo APK. Haz clic en el botón **Aceptar**. **Abre el archivo descargado** Una vez descargado, haz clic en **Abrir**. **Confirma la instalación** Aparecerá una alerta preguntando si quieres instalar la App. Haz clic en **Instalar**. **Omite la advertencia de Google Play Protect** Aparecerá otra alerta indicando que Google Play no reconoce la App. Haz clic en **INSTALAR DE TODAS FORMAS**. **Habilitar el análisis de Google Play Protect (recomendado)** Además, podría aparecer una tercera alerta solicitando permiso para analizar la aplicación con Google Play Protect. Siempre recomendamos **ENVIAR** para el análisis. #### Orígenes desconocidos y apps desconocidas Si los **Orígenes desconocidos** están desactivados en tu teléfono, aparecerá una nueva alerta. **Abre Ajustes** Haz clic en el botón **Ajustes**. **Habilita las fuentes desconocidas** Activa la opción **Permitir desde esta fuente** y vuelve atrás para continuar. ### Añadir a la pantalla de inicio Puedes añadir la Store Enterprise de tu organización directamente como una App estándar en la pantalla de inicio para acceder a las apps de tu empresa de forma más rápida. **Abre la URL de la Store Enterprise en Chrome** **Abre la URL de la Store Enterprise de tu organización** (por ejemplo, demo.applivery.com) con **Google Chrome**. **Abre el menú de más opciones de Chrome** Toca el botón **Más opciones** en la barra superior derecha. **Selecciona Añadir a la pantalla de inicio** Toca la opción **Añadir a la pantalla de inicio** del menú desplegable. **Ponle nombre a la App y añádela** Elige un nombre para la App y haz clic en el botón **Añadir**. **Finaliza la adición** Arrastra el icono de la App o toca el botón **Añadir automáticamente** para terminar. Encontrarás la Store Enterprise de tu organización añadido a la pantalla de inicio de tu teléfono. Recordará tus ajustes de inicio de sesión y se abrirá en modo pantalla completa para una mejor experiencia de usuario. --- ## Guía para la Store en iOS Source: https://docs.applivery.com/es/app-distribution/getting-started/app-store-user-manual-ios/ Description: Accede, navega e instala apps desde la Store Enterprise de Applivery de tu organización en iOS. Cubre inicio de sesión, búsqueda y ajustes de idioma. TL;DR: Aprende a acceder, navegar e instalar apps desde la Store Enterprise de tu organización en tu dispositivo iOS. Answers: ¿Cómo inicio sesión en la Store Enterprise usando Single Sign-On (SSO)? · ¿Qué hago si olvidé la contraseña de la Store Enterprise? · ¿Cómo puedo filtrar las apps en la Store Enterprise? · ¿Cómo cambio el idioma en la Store Enterprise de Applivery? · ¿Cómo comparto una app desde la Store Enterprise? · ¿Qué hago si veo el mensaje 'Desarrollador empresarial no de confianza' tras instalar una app? · ¿Cómo añado la Store Enterprise a la pantalla de inicio de mi teléfono? · ¿Dónde encuentro las apps que tengo permiso para ver? Key topics: Acceso a la Store Enterprise, Navegación por la Store Enterprise, Instalación de apps, Resolución de problemas, Personalización, Store Enterprise, iOS, Safari, Applivery ### Acceso e inicio de sesión En ocasiones deberás autenticarte para acceder a la Store Enterprise o a una App concreta. Según la configuración de tu organización, habrá una o varias opciones de autenticación: 1. **Inicio de sesión tradicional o LDAP:** introduce tu correo electrónico o nombre de usuario corporativo y contraseña. Luego haz clic en el botón verde **Siguiente** para continuar. 2. **Single Sign-On:** si está disponible, aparecerá un botón verde con el texto **Iniciar sesión con [nombre de empresa]** en la parte superior de la pantalla de inicio de sesión. Haz clic en él y serás redirigido a la pantalla de SSO donde podrás introducir de forma segura tus credenciales corporativas. ![login ios](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/9f3a3669-f128-45f3-98dd-36be88aca4ad.png) #### Recuperar contraseña Si has perdido tu contraseña, haz clic en el enlace **Olvidé mi contraseña** en la pantalla de inicio de sesión e **introduce tu dirección de correo electrónico** en el cuadro emergente. Recibirás un correo con las instrucciones para restablecer tu contraseña. ![forgot password ios](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/5167de0e-fa2f-4b1a-b819-6490ff04bff8.png) ### Navegación, búsqueda, idioma y opciones de compartir #### Navegación Una vez que accedas a la Store Enterprise, todas las Publicaciones que tienes permiso para ver aparecerán listadas en la sección **Apps**. Puedes ajustar cómo se muestran: por **Publicación**, **App** o **Build**. ![store display ios](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/4d429d64-577d-470c-afa9-01735cabba8c.png) #### Buscar apps Puedes filtrar la lista de Apps haciendo clic en el icono de lupa en la parte superior. Según la pestaña en la que estés, encontrarás varias opciones de filtro, incluyendo **versión**, **código de versión**, **slug**, **etiquetas**, **nombre del paquete** y **registro de cambios**. ![filter ios](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/75feb7ba-cd2f-46f2-b3a6-4f408f8c003e.png) #### Cambiar idioma Applivery está disponible en 10 idiomas diferentes. Detecta automáticamente el idioma predeterminado de tu sistema operativo y lo aplica si está disponible. Si no, se seleccionará automáticamente el idioma predeterminado (inglés). Puedes cambiar el idioma en cualquier momento desde el menú **Más opciones > Cambiar idioma** en la esquina superior derecha de la Store Enterprise. ![change language ios](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/90eaea91-ac2c-4c58-9946-67453bdda71c.png) #### Opciones de compartir Puedes compartir el enlace a una App de varias formas (código QR, URL o a través de tus apps nativas favoritas). **Abre el menú de más opciones de la App** Toca **Más opciones** en el menú superior derecho. **Selecciona la opción Compartir** En el menú desplegable, selecciona la opción **Compartir**. **Elige tu método de compartir** Se mostrarán todas las opciones de compartir, incluyendo una URL única y un código QR. También puedes tocar la opción **Compartir con…** para mostrar las opciones de compartir nativas y compartir la App con otros a través de las apps sociales instaladas en tu dispositivo. ![share ios app](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/89aa5c13-d5a3-41b1-95e2-3eb2b59d91d7.png) ### Instalar apps Una vez dentro de una App en la Store Enterprise: **Toca el botón Instalar** Toca el botón verde **Instalar**. **Confirma la instalación** Aparecerá un mensaje de confirmación solicitando tu permiso para instalar la App. Toca **Instalar**. **Espera a que se complete la instalación** Desliza hacia arriba para ir a la pantalla de inicio. El proceso de descarga e instalación comenzará y verás una barra de progreso. Espera a que aparezca el icono de la App para abrirla. #### Apps empresariales (Desarrollador empresarial no de confianza) Según el tipo de certificado usado para firmar las aplicaciones, puede que necesites realizar pasos adicionales para **confiar** en el desarrollador de la aplicación. Si, una vez instalada la App, ves el mensaje **Desarrollador empresarial no de confianza** al tocarla, sigue estos pasos: **Abre Ajustes** Ve a **Ajustes > General**. **Accede a Gestión de dispositivos** Toca **Gestión de dispositivos**. **Confía en el desarrollador** 1. Selecciona el **Nombre de tu empresa**. 2. Pulsa **Confiar en [nombre de empresa]**. ### Añadir a la pantalla de inicio Puedes añadir la Store Enterprise de tu organización directamente como una App estándar en la pantalla de inicio para acceder a las apps de tu empresa de forma más rápida. **Abre la Store Enterprise en Safari** **Abre la URL de la Store Enterprise de tu organización** (por ejemplo, demo.applivery.com) con Safari. **Añadir a la pantalla de inicio** 1. Toca el botón **Compartir** en la barra de navegación gris inferior. 2. Toca la opción **Añadir a la pantalla de inicio** del menú. 3. Elige un nombre para la App y haz clic en el botón **Añadir**. Encontrarás la Store Enterprise de tu organización añadido a la pantalla de inicio de tu teléfono. Recordará tus ajustes de inicio de sesión y se abrirá en modo pantalla completa para una mejor experiencia de usuario. --- ## Crea tu primera App Source: https://docs.applivery.com/es/app-distribution/getting-started/create-first-app/ Description: Crea tu primera App en Applivery. Configura el perfil de la App, sube Builds y ajusta los parámetros de distribución y analítica. TL;DR: Aprende a crear rápidamente tu primera app en Applivery para empezar a gestionar builds y distribución. Answers: ¿Qué es una App en Applivery? · ¿Por qué crear varias Apps en Applivery? · ¿Cómo creo una nueva App en Applivery? · ¿Qué puedo gestionar dentro de una App en Applivery? · ¿Qué debo hacer tras crear una App? · ¿Puedo crear varias Apps para el mismo proyecto? · ¿Debo crear una App separada para cada entorno? Key topics: Creación de apps, Interfaz de Applivery, Gestión de apps, Applivery En Applivery, las Apps son uno de los elementos más importantes. Puedes gestionarlas de la forma que mejor se adapte a tus necesidades. Por ejemplo, puedes: - Crear una App separada para cada proyecto diferente. - Crear más de una App para el mismo proyecto y gestionar así distintas versiones o la segregación por equipo. - Crear una App para cada entorno (Desarrollo, Staging, Calidad o Producción) y diferenciarlos con facilidad. Dentro de las Apps encontrarás todo lo relacionado con ellas: Builds, analíticas, permisos de usuario, control de versiones y opciones de distribución. Vamos a crear tu primera App. **La sección Apps** Haz clic en el botón **\+ Crear App**. ![create app](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/fc2584ec-9e47-4115-8ea1-b06ff1a42b59.png) **Elige el nombre de la App** Elige un nombre fácil de identificar para la App y haz clic en **Guardar**. ![create app form](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/c06bb670-bf5b-4033-8fa8-d6e811569c4e.png) ¡Enhorabuena! Has creado correctamente tu primera App en Applivery. Ahora puedes empezar a subir Builds y gestionar la distribución de apps. --- ## Conceptos clave Source: https://docs.applivery.com/es/app-distribution/getting-started/main-concepts/ Description: Conceptos clave de la Distribución de Apps de Applivery: Workspaces, Apps, Builds, usuarios, audiencias y Publicaciones — todo lo que necesitas para empezar a distribuir. TL;DR: Aprende los conceptos principales de la plataforma de Distribución de apps de Applivery para optimizar el despliegue de apps móviles en tu organización. Answers: ¿Qué es un Workspace de Applivery? · ¿Qué es una App de Applivery? · ¿Qué es un Build de Applivery? · ¿Qué es una Publicación de Applivery? · ¿Cuál es la diferencia entre Colaboradores y Empleados de la Store en Applivery? · ¿Qué es un Grupo de Applivery? · ¿Qué es una Audiencia de usuario de Applivery? · ¿Para qué se usa la API de integración de Applivery? Key topics: Workspaces y Apps, Builds y Publicaciones, Usuarios, Grupos y Audiencias, Enterprise Store, API de integración y App Tokens, Applivery, iOS, Android, Windows, Integration API, App Token Como introducción a la Distribución de Apps de Applivery, te recomendamos encarecidamente que explores y comprendas los siguientes conceptos básicos, que se explicarán en detalle en los siguientes capítulos de la documentación, ya que representan los conceptos fundamentales de nuestra plataforma. ### Workspace Un **Workspace** es el entorno organizativo donde se gestionan todas las Apps, Builds, Colaboradores, Empleados de la Store y configuraciones. Cada Workspace funciona de forma independiente y contiene su propia estructura de distribución y ajustes de control de acceso. ### App Puedes entender una **App** como el equivalente a tu proyecto. Actúa como un contenedor de todos los Builds relacionados de la misma aplicación, independientemente de la versión o plataforma (iOS, Android, Windows o personalizada). Cada App centraliza la gestión de versiones, los ajustes de distribución y los controles de Publicación. ### Build Un **Build** es una versión concreta de una aplicación subida a Applivery. Los Builds son los archivos de instalación reales que se distribuyen a los usuarios, como: - `.ipa` (iOS). - `.pkg`, `.dmg` (macOS). - `.apk`, `.aab` (Android). - `.msi`, `.exe`, `.msix`, `.appx`, `.msixbundle`, `.appxbundle` (Windows). Pueden existir varios Builds bajo la misma App, lo que permite el control de versiones, los despliegues por fases y la gestión de actualizaciones. ### Publicación Una [**Publicación**](https://docs.applivery.com/es/app-distribution/distribute/distribute-apps/) determina cómo y a quién se pone a disposición un Build. Las Publicaciones permiten a los administradores controlar: - Qué Build se distribuye. - Qué Empleados de la Store o audiencias pueden acceder a él. - Las reglas de visibilidad en el Enterprise Store. Esto permite estrategias de distribución flexibles, como despliegues internos, lanzamientos por departamento o escenarios de pruebas beta. ### Colaboradores y Empleados de la Store En Applivery existen dos tipos diferentes de usuarios: - Los **Colaboradores** son usuarios que tienen acceso al panel de Applivery. Se les pueden asignar distintos roles y niveles de permisos, como acceso administrativo o permisos de desarrollo. Los Colaboradores gestionan las Apps, suben Builds, configuran los ajustes de distribución y controlan las Publicaciones. - Los **Empleados de la Store** representan a cada usuario final que accede a las aplicaciones a través del Enterprise Store. No tienen acceso al panel. Su interacción se limita a descargar e instalar las aplicaciones que se les han puesto a disposición. :::info Puedes encontrar más información sobre los tipos de usuario en el siguiente artículo de [nuestra documentación](https://docs.applivery.com/es/app-distribution/distribute/manage-users/). ::: ### Grupos Un [**Grupo**](https://docs.applivery.com/es/app-distribution/distribute/user-groups/) es una colección lógica de empleados dentro de un Workspace. Los Grupos se usan para organizar a los usuarios según criterios como departamento, rol, ubicación o proyecto. Simplifican la distribución de aplicaciones al permitir a los administradores asignar Publicaciones a varios usuarios a la vez en lugar de gestionar el acceso de forma individual. Los Grupos ayudan a mantener flujos de trabajo de distribución escalables y estructurados, especialmente en grandes organizaciones donde la disponibilidad de las apps debe estar segmentada entre distintos equipos o unidades de negocio. ### Audiencias de usuario Una [**Audiencia de usuario**](https://docs.applivery.com/es/app-distribution/distribute/user-audiences/) es un grupo dinámico de empleados generado automáticamente a partir de reglas o atributos predefinidos. A diferencia de los Grupos estáticos, que requieren asignación manual de usuarios, las Audiencias de usuario se actualizan automáticamente cuando los empleados cumplen los criterios definidos (como departamento, rol, ubicación o atributos personalizados). Este comportamiento dinámico permite estrategias de distribución escalables y automatizadas. Al publicar una App para una Audiencia de usuario, cualquier empleado que cumpla las condiciones obtendrá (o perderá) acceso automáticamente cuando sus atributos cambien. Las Audiencias de usuario son ideales para grandes organizaciones que necesitan una segmentación basada en reglas, actualizada de forma continua y sin mantenimiento manual. ### Enterprise Store El **Enterprise Store** es la tienda de apps privada de tu organización. Es un portal web donde los empleados pueden acceder y descargar las aplicaciones publicadas para ellos. La Store admite personalización de marca, configuraciones de seguridad y reglas de visibilidad basadas en audiencias. ### API de integración La [**API de integración**](https://www.applivery.com/wp-content/docs/openapi.html#tag/Integration-Builds/paths/~1integrations~1builds~1/get) permite a las organizaciones interactuar programáticamente con el entorno de Distribución de Apps de Applivery. A través de la API, sistemas externos como pipelines de CI/CD, portales internos o plataformas de terceros pueden automatizar acciones, incluyendo la subida de nuevos Builds o la creación o actualización de Publicaciones. La API de integración permite la automatización completa de los procesos del ciclo de vida de las Apps, reduciendo la intervención manual y garantizando una integración fluida con los sistemas empresariales existentes. ### App Token Un [**App Token**](https://docs.applivery.com/es/app-distribution/api/app-api-token/) es una credencial de autenticación segura que se utiliza para autorizar peticiones a la API de integración. Cada token se genera dentro del Workspace y está vinculado a una App o ámbito específico. Permite a los sistemas externos subir Builds de forma segura o realizar acciones de distribución automatizadas sin necesitar acceso completo al panel. Los App Tokens deben almacenarse de forma segura y gestionarse siguiendo las mejores prácticas de protección de credenciales, ya que otorgan acceso programático a las operaciones relacionadas con las Apps. ### Distribución de Apps vs. Gestión de Dispositivos La Distribución de apps está diseñada para distribuir aplicaciones a los usuarios, independientemente de si sus dispositivos están gestionados. Puede funcionar de forma independiente o combinarse con la gestión de dispositivos para escenarios más avanzados, como instalaciones silenciosas, aplicación de políticas o despliegues automatizados. --- ## Carga tu primera Build Source: https://docs.applivery.com/es/app-distribution/getting-started/upload-first-build/ Description: Carga tu primera Build de una App a Applivery paso a paso — desde el panel, mediante API o integración con CI/CD. TL;DR: Aprende a cargar tu primer build de app móvil a Applivery mediante un sencillo proceso paso a paso. Answers: ¿Cómo subo un build a Applivery? · ¿Qué tipos de archivo puedo cargar a Applivery? · ¿Cómo accedo a la sección de subida de builds en Applivery? · ¿Qué significa el estado 'En cola' para mi build de Applivery? · ¿Qué significa el estado 'Procesando' para mi build de Applivery? · ¿Qué significa el estado 'Error' para mi build de Applivery? · ¿Qué ajustes adicionales puedo configurar al cargar un build? Key topics: Subida de builds en Applivery, Distribución de apps móviles, Estados de procesamiento de builds, Applivery, iOS, Android, IPA, APK, AAB, Bitrise.io, Fastlane, Windows, macOS Si ya has [creado tu primera app](https://docs.applivery.com/es/app-distribution/getting-started/create-first-app/), ahora es el momento de cargar tu primera Build. Hay varias formas de hacerlo, incluyendo métodos automáticos usando nuestra API o plataformas de terceros como Bitrise.io o Fastlane, que permiten desplegar tus Apps en Applivery de forma automática y sin esfuerzo. Como es tu primera vez, ¡vamos a mantenerlo sencillo! **Ve a tus aplicaciones** Desde la sección **Apps**, haz clic en la **App** donde quieras cargar un Build. ![Apps section](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/0e20f8ac-ba6c-48e4-bce5-6d0d65dcbb03.png) **Carga tu Build** Serás redirigido a la lista de Builds (probablemente vacía por ahora). Haz clic en el botón **\+ Cargar Build**. ![upload build](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ef6457f8-3a2d-426e-b91c-7fbbe8014ce0.png) Haz clic en el área gris para buscar en tu disco duro el paquete que quieres cargar. Debe tener una de las siguientes extensiones de archivo: - `.ipa` para iOS e iPadOS. - `.pkg` o `.dmg` para macOS. - `.apk` o `.aab` para Android. - `.msi`, `.exe`, `.msix`, `.appx`, `.msixbundle` o `.appxbundle` para Windows. - Los formatos `.zip` o `.tar.gz` son compatibles en todas las plataformas. :::info Estas son las extensiones de archivo predeterminadas que puedes cargar a tu Workspace. Puedes leer más sobre las **Plataformas de build personalizadas** [aquí](https://docs.applivery.com/es/app-distribution/platforms/custom-platforms/). ::: ![upload build form](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/aa1ad383-6ee6-4d6b-aefb-64fc15f626f4.png) La vista modal cambiará automáticamente para permitirte seleccionar ajustes adicionales, como el nombre del Build, añadir etiquetas, incluir un registro de cambios o configurar los ajustes de notificación. Cuando estés listo, haz clic en el botón **Subir** para iniciar el proceso de subida. ![upload build](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/d328085b-61ab-4e20-82a5-84b1a7e0f8df.png) Una vez terminada la subida del Build, volverás a la lista de Builds y encontrarás una nueva fila con uno de los siguientes estados: - **En cola:** el Build está esperando a ser procesado por nuestros sistemas. - **Procesando:** el paquete está siendo procesado por nuestros sistemas. - **Error:** el paquete ha sido analizado, pero no hemos podido extraer información. Puedes leer más sobre los códigos de error de procesamiento de Builds [aquí](https://docs.applivery.com/es/app-distribution/builds/processing-error-codes/). - **Finalizado:** el Build se ha procesado correctamente. Verás el icono de la App (si existe) e información adicional. Ten paciencia, ya que puede tardar un rato dependiendo del tamaño de tus Builds. ![build state](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/fbd89c68-2a97-40a7-bf15-ad988581cb07.png) --- ## Integraciones Source: https://docs.applivery.com/es/app-distribution/integrations/ Description: Integraciones de Distribución de Apps en Applivery: conecta con Slack y webhooks para recibir notificaciones de Builds en tiempo real y automatizar flujos de trabajo. TL;DR: Applivery se integra con Slack y webhooks para enviar notificaciones de Builds en tiempo real y automatizar tareas de distribución de apps. Answers: ¿Qué integraciones admite la Distribución de Apps de Applivery? · ¿Cómo conecto Slack con Applivery? · ¿Para qué sirven los webhooks en Applivery? · ¿Dónde configuro las integraciones en Applivery? · ¿Puedo automatizar tareas con las integraciones de Applivery? Key topics: Integración con Slack, Webhooks personalizados, Automatización de notificaciones, Applivery, Slack, Webhooks La Distribución de Apps de Applivery se conecta con servicios externos para ampliar la automatización y mantener a tu equipo informado. Puedes lanzar webhooks personalizados en eventos clave o enviar notificaciones de Builds en tiempo real directamente a un canal de Slack. Configura cada integración y personaliza los eventos y mensajes que se envían a tus herramientas externas. --- ## Slack Source: https://docs.applivery.com/es/app-distribution/integrations/slack/ Description: Conecta Applivery con Slack para recibir notificaciones en tiempo real de nuevas Builds, feedback e informes de error, y vencimiento de certificados. TL;DR: Integra Applivery con Slack para recibir notificaciones instantáneas sobre nuevas builds, feedback, informes de errores y análisis de descargas. Answers: ¿Qué eventos de Applivery pueden lanzar notificaciones de Slack? · ¿Cómo integro Applivery con Slack? · ¿Dónde se configuran las integraciones de Slack en Applivery? · ¿Puedo editar o eliminar una integración de Slack existente? ![applivery-slack-macIphone | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/8e0ca2d7-921c-47eb-b6f9-0d4b32d04df1.png) Ahora puedes integrar Applivery con Slack y empezar a recibir notificaciones cuando ocurran los siguientes eventos: - Se ha subido una nueva **Build**. - Una nueva **Build** ha sido procesada y está lista para instalar. - Se ha recibido un nuevo **informe de feedback**. - Se ha recibido un nuevo **informe de error**. - Un **certificado Enterprise** de una App está a punto de vencer. Integrar Applivery en tu equipo de Slack es muy sencillo gracias a nuestra App Oficial, y la configuración te llevará menos de 1 minuto. Solo sigue los pasos a continuación. ### Primeros pasos La integración de Slack se puede configurar a nivel de **Workspace**, para que las notificaciones de toda la actividad de Apps y Builds de tu organización se envíen a un `#canal` o `@usuario` específico. **Navegar a Integraciones** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a los **Ajustes del Workspace** 1 desde el menú desplegable superior, abre **Integraciones** 2 en el menú lateral izquierdo y haz clic en el botón **\+ Crear integración** 3. ![integrations](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/4f179d05-6d7c-49c5-b654-ba62c802673a.png) **Eventos de Slack** Elige la opción **Slack**, selecciona los eventos que quieres recibir de la lista y haz clic en el botón **Añadir a Slack**. ![slack integration](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/71550d3a-3864-4e8f-8c10-f4c9718b14f5.png) **Autorizar la integración** Ahora es momento de iniciar sesión en tu equipo: necesitarás introducir tu **dirección de email de Slack** y tu **contraseña de Slack**. Después, selecciona dónde deben publicarse los mensajes de Applivery usando el menú desplegable inferior, que mostrará la lista de usuarios y canales disponibles en tu equipo de Slack. Una vez hecho, haz clic en el botón **Permitir**. ![slack-step4-1 | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/92f790ba-de74-448d-9a6a-aee13fa8274c.png) **Gestionar las integraciones de Slack** Serás redirigido automáticamente a la sección **Integraciones**, donde aparecerá la nueva integración de Slack con todos los detalles que has seleccionado: - **Tipo:** Slack. - **Configuración:** `#canal` o `@usuario` que recibirá los mensajes. - **Eventos:** lista de eventos que se notificarán. ![slack-step4-1 | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/92f790ba-de74-448d-9a6a-aee13fa8274c.png) ¡Eso es todo! Serás redirigido automáticamente de vuelta a Applivery, y comenzaremos a enviar notificaciones a tu equipo de Slack de inmediato. **Actualizar los ajustes de la integración de Slack** Puedes editar tus integraciones de Slack en cualquier momento yendo a la **sección de Integraciones** de tu **Workspace** y haciendo clic en una de las integraciones de Slack existentes. Se abrirá un panel lateral que te permite elegir qué eventos se publicarán en tus `@usuarios` o `#canales`. También podrás eliminar la integración haciendo clic en el botón **Eliminar**. #### Ejemplos de notificaciones ![new-Builds-messages | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/99ca45b9-c2b3-439b-86a2-999d16107ab0.png)![new-feedback-messages | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/265daebc-72c2-4c22-9355-b8cca6b0bbb7.png) **Webhooks personalizados** Aprende a configurar webhooks personalizados para escenarios de integración avanzados. --- ## Webhooks personalizados Source: https://docs.applivery.com/es/app-distribution/integrations/webhooks/ Description: Integra Applivery con webhooks para recibir notificaciones en tiempo real de nuevas Builds, feedback, informes de error y vencimiento de certificados. TL;DR: Integra Applivery con webhooks para recibir notificaciones en tiempo real sobre eventos de distribución de apps como nuevas builds, registros de usuarios y crashes. Answers: ¿Qué eventos de Applivery pueden lanzar un webhook? · ¿Dónde puedo configurar los webhooks de Applivery? · ¿Qué datos se envían en un webhook de Applivery? · ¿Cómo edito un webhook existente en Applivery? ![webhooks](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/a78842cc-a70c-4563-8b35-9740ae11e2d1.png) Integra Applivery con servicios externos usando webhooks personalizados para recibir notificaciones en tiempo real sobre eventos clave de Distribución de Apps. Los webhooks te permiten conectar Applivery con cualquier servicio externo que acepte peticiones HTTP POST — pipelines CI/CD, paneles de control personalizados, herramientas de notificaciones, y más. Cuando ocurre un evento relevante en Applivery, se envía automáticamente un payload JSON a la URL que hayas configurado. Para la Distribución de Apps, los siguientes eventos pueden lanzar una notificación de webhook: - Se ha subido una nueva **Build**. - Una nueva **Build** ha sido procesada y está lista para instalar. - Se ha recibido un nuevo **informe de feedback**. - Se ha recibido un nuevo **informe de error**. - Un **certificado Enterprise** de una App está a punto de vencer. ### Primeros pasos Las integraciones de webhooks pueden configurarse en dos niveles: - **Workspace** — Las notificaciones de todas las Apps de tu organización se envían a la URL configurada. - **App** — Las notificaciones de una App específica se envían a la URL configurada. **Navegar a Integraciones** Decide si quieres una integración a nivel de Workspace o de App. Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/): - Para **Workspace**: Ve a los Ajustes del Workspace 1 desde el menú desplegable superior, abre Integraciones 2 en el menú lateral izquierdo y haz clic en el botón + Crear integración 3. ![integrations](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/f9d029bf-b26a-4951-9f24-7f1b086ed836.png) - Para una **App** específica: Ve a los **Ajustes de la App** 4 y, desde el menú lateral izquierdo, selecciona **Integraciones** 5. Haz clic en el botón **\+ Crear integración** 6. ![app integration](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/3c423eaf-87f2-4da8-a4e1-74c2dd765cc9.png) **Configurar el Webhook** 1. Selecciona **Webhook** como tipo de integración. 2. Introduce la **URL** que debe recibir los payloads del webhook. 3. Selecciona los **eventos** a los que quieres suscribirte de la lista. 4. Haz clic en **Guardar**. ![webhook configuration](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/e6adcaa6-e8b5-42fd-9616-42021457e409.png) ### Gestionar las integraciones de Webhook Tras guardar, serás redirigido a la sección de Integraciones, donde tu nuevo webhook aparecerá listado con un resumen de su configuración: - **Tipo:** Webhook - **Configuración:** La URL de destino - **Eventos:** La lista de eventos suscritos #### Editar un Webhook Ve a la sección **Integraciones** de tu Organización o App y haz clic en una integración de webhook existente. Se abrirá un panel lateral donde podrás actualizar la URL de destino y los eventos suscritos. #### Eliminar un Webhook Abre la integración de webhook desde la sección Integraciones y haz clic en el botón **Eliminar** en el panel lateral. ### Payloads de eventos Todas las notificaciones de webhook se entregan como peticiones HTTP POST con un cuerpo JSON. Usa el campo `action` para identificar el tipo de evento y enrutar tu lógica de procesamiento en consecuencia. **build_created — Se lanza cuando se ha subido una nueva Build y está en cola para ser procesada, pero todavía no ha sido procesada.** ```json { "action": "build_created", "organization": { "id": "5d4d1391cd523c15f50df235", "name": "Applivery Test", "url": "https://dashboard.applivery.io/test" }, "application": { "id": "5e790ce04faa50cac52e4676", "name": "Awesome App", "url": "https://dashboard.applivery.io/test/apps/awesome-app" }, "build": { "id": "5e79232e98d88ac68cf7d4bc", "url": "https://dashboard.applivery.io/test/apps/awesome-app/builds?id=5e79232e98d88ac68cf7d4bc" } } ``` **build_processed — Se lanza cuando una Build se ha procesado correctamente y está lista para instalar.** ```json { "action": "build_processed", "organization": { "id": "5d4d1391cd523c15f50df235", "name": "Applivery Test", "url": "https://dashboard.applivery.io/test" }, "application": { "id": "5e790ce04faa50cac52e4676", "name": "Awesome App", "url": "https://dashboard.applivery.io/test/apps/awesome-app" }, "build": { "id": "5e79232e98d88ac68cf7d4bc", "os": "android", "versionName": "", "url": "https://dashboard.applivery.io/test/apps/awesome-app/builds?id=5e79232e98d88ac68cf7d4bc" } } ``` **bug_created — Se lanza cuando se ha enviado un nuevo informe de error.** ```json { "action": "bug_created", "organization": { "id": "5c9921fbb9f3bb001cc5c9a9", "name": "Applivery Dev", "url": "https://dashboard.applivery.io/test" }, "application": { "id": "5cd19870cdecf8001bef50b7", "name": "Awesome App", "url": "https://dashboard.applivery.io/test/apps/awesome-app" }, "report": { "message": "This is a Bug message that will be included in the Report along with the technical information of the device", "url": "https://dashboard.applivery.io/test/apps/awesome-app/reports?id=5e7923a976b4b0e9aa4aa6a9" } } ``` **feedback_created — Se lanza cuando se ha enviado un nuevo informe de feedback.** ```json { "action": "feedback_created", "organization": { "id": "5c9921fbb9f3bb001cc5c9a9", "name": "Applivery Dev", "url": "https://dashboard.applivery.io/test" }, "application": { "id": "5cd19870cdecf8001bef50b7", "name": "Awesome App", "url": "https://dashboard.applivery.io/test/apps/awesome-app" }, "report": { "message": "This is a Feedback message that will be included in the Report along with the technical information of the device", "url": "https://dashboard.applivery.io/test/apps/awesome-app/reports?id=5e7923a976b4b0e9aa4aa6a9" } } ``` **certificate_will_expire — Se lanza cuando un certificado Enterprise de una App se acerca a su fecha de vencimiento.** ```json { "action": "certificate_application_will_expire", "organization": { "id": "5c9921fbb9f3bb001cc5c9a9", "name": "Applivery Dev", "url": "https://dashboard.applivery.io/test" }, "application": { "id": "5cd19870cdecf8001bef50b7", "name": "Awesome App", "url": "https://dashboard.applivery.io/test/apps/awesome-app" }, "numDays": "5", "team": { "name": "Applivery Test", "identifier": "BJ55L1KAQW" } } ``` :::info El campo `numDays` indica cuántos días faltan para que venza el certificado. ::: ### Referencia de eventos | Acción | Disparador | | --- | --- | | `build_created` | Se ha subido una nueva Build y está en cola para procesarse. | | `build_processed` | Una Build ha sido procesada y está lista para instalar. | | `bug_created` | Se ha enviado un nuevo informe de error. | | `feedback_created` | Se ha enviado un nuevo informe de feedback. | | `certificate_will_expire` | Un certificado Enterprise de una App está a punto de vencer. | --- ## Plataformas Source: https://docs.applivery.com/es/app-distribution/platforms/ Description: Guía completa para publicar y distribuir apps en todas las plataformas compatibles con Applivery: iOS, Android, macOS, Windows y plataformas personalizadas. TL;DR: Applivery admite distribución de apps para iOS, Android, macOS, Windows y plataformas personalizadas, con configuración específica por plataforma. Answers: ¿Qué plataformas admite Applivery para la distribución de apps? · ¿Cómo distribuyo apps iOS con Applivery? · ¿Cómo distribuyo apps Android con Applivery? · ¿Admite Applivery plataformas personalizadas? · ¿Qué configuración específica de plataforma necesito para Applivery? Key topics: Distribución de apps iOS, Distribución de apps Android, Plataformas personalizadas, Applivery, iOS, Android, macOS, Windows Applivery es compatible de forma nativa con iOS, Android, macOS y Windows, cada uno con sus propias opciones de configuración específicas de plataforma. También puedes ampliar la distribución a cualquier otra plataforma mediante las Plataformas de Build personalizadas. Cada plataforma compatible tiene sus propios requisitos de certificados de firma, App Bundles, aprovisionamiento de UDIDs y distribución. --- ## Android Source: https://docs.applivery.com/es/app-distribution/platforms/android/ Description: Distribuye y gestiona Apps Android dentro de tu organización con Applivery — AABs, certificados de firma, apps privadas y más. TL;DR: Applivery permite distribuir y gestionar apps Android dentro de una organización, cubriendo AABs, keystores, Apps Privadas self-hosted y requisitos específicos de plataforma. Answers: ¿Qué es la Gestión de Apps Android en Applivery? · ¿Admite Applivery los Android App Bundles (AAB)? · ¿Puede Applivery gestionar certificados de firma y keystores de Android? · ¿Cómo distribuyo apps Android privadas con Applivery? · ¿Gestiona Applivery el requisito de fuentes desconocidas para instalar apps Android? Key topics: Android App Bundles, Certificados de firma y keystores, Apps Privadas self-hosted, Fuentes desconocidas en Android, Applivery, Android, Google Play, Keystore Applivery te permite distribuir y gestionar aplicaciones Android de forma segura dentro de tu organización. Puedes trabajar con Android App Bundles (AAB), gestionar certificados de firma y keystores, distribuir Apps Privadas self-hosted y gestionar los requisitos de distribución específicos de la plataforma. Tanto si distribuyes apps empresariales internas como si gestionas un programa de pruebas, aquí encontrarás toda la guía específica de plataforma que necesitas. --- ## Android App Bundles (AAB) Source: https://docs.applivery.com/es/app-distribution/platforms/android/aab/ Description: Applivery admite Android App Bundles (AAB) para la Distribución de Apps: genera APKs universales y distribúyelos a tus usuarios sin complicaciones. TL;DR: Applivery usa Android App Bundles (AAB) para generar APKs universales con amplia compatibilidad entre dispositivos Android. Answers: ¿Qué es un Android App Bundle (AAB)? · ¿Cómo gestiona Applivery los archivos AAB? · ¿Cómo configuro el AAB en Applivery? · ¿Qué limitaciones tiene el soporte AAB de Applivery? ## Android App Bundle (AAB) El [Android App Bundle (AAB)](https://developer.android.com/platform/technology/app-bundle) es el formato oficial de publicación de Android, diseñado para hacer la entrega de Apps más eficiente y flexible. En lugar de generar un único APK que funcione en todos los dispositivos, un AAB contiene todo el código compilado y los recursos de tu App y delega la generación y firma del APK a la plataforma de distribución, resultando en instalaciones más pequeñas y optimizadas para los usuarios finales. Cambiar a AAB no requiere refactorizar tu código. El formato también permite el desarrollo modular de apps y la entrega personalizable de funcionalidades, facilitando la escalabilidad y el mantenimiento de tu App a lo largo del tiempo. ![android-app-bundle | Applivery](https://www.applivery.com/wp-content/uploads/2021/12/android-app-bundle-1024x362.png "android-app-bundle | Applivery") ### Cómo gestiona Applivery los archivos AAB Google Play usa un App Bundle para generar y servir APKs optimizados adaptados a la configuración hardware específica de cada dispositivo, de modo que los usuarios solo descargan el código y los recursos que su dispositivo realmente necesita. El modelo de distribución de Applivery funciona de manera diferente. Como los usuarios normalmente descargan Apps a través de un navegador (Safari, Chrome, Firefox, etc.), Applivery no tiene acceso fiable a la configuración hardware del dispositivo en el momento de la descarga, que es un requisito previo para generar un APK optimizado por dispositivo. Para solucionar esto, Applivery usa la [herramienta oficial bundletool de Android](https://developer.android.com/tools/bundletool) para extraer un **APK universal** de tu App Bundle. Un APK universal incluye todo el código y los recursos necesarios para instalar la App en cualquier dispositivo Android compatible, independientemente del hardware. Esto significa que la App se instalará correctamente en todos tus dispositivos compatibles, pero la descarga será más grande que un APK optimizado por dispositivo generado por Google Play. #### Limitaciones actuales Como consecuencia de este enfoque, algunas funcionalidades de Android App Bundle no están completamente soportadas aún en Applivery: - **Entrega Dinámica (Dynamic Delivery)**: La entrega basada en módulos y los tamaños de APK optimizados por dispositivo no están disponibles, ya que requieren detección hardware en el momento de la descarga. #### En qué estamos trabajando Nuestro equipo está trabajando activamente en dos enfoques para llevar el soporte completo de AAB a Applivery: - **Predicción de dispositivo**: Para habilitar la Entrega Dinámica desde las Stores Enterprise de Applivery sin requerir detección hardware explícita. - **Detección hardware mediante SDK**: Para obtener información hardware del dispositivo a través del SDK de Applivery y habilitar la Entrega Dinámica para actualizaciones in-app. Puedes seguir el progreso de ambas iniciativas en nuestro [roadmap público en GitHub](https://github.com/orgs/applivery/projects/1). * * * ### Configurar Android App Bundle en Applivery Para subir y procesar archivos AAB, primero necesitas proporcionar la configuración de firma de tu App para que Applivery pueda generar un APK universal válido a partir de tu bundle. **Añadir la configuración de tu Keystore** Ve a **Ajustes > Android App Bundle** dentro de la App que quieres configurar y proporciona la siguiente información requerida: | Campo | Descripción | |---|---| | **Keystore** | El keystore de despliegue (archivo `.jks`) usado para firmar los APKs generados. | | **Contraseña del Keystore** | La contraseña del keystore. Puede introducirse como texto plano o proporcionarse mediante un archivo `.pwd`. | | **Alias del Keystore** | El alias de la clave de firma a usar dentro del keystore. | | **Contraseña de la clave** | La contraseña para la clave de firma. Puede introducirse como texto plano o proporcionarse mediante un archivo `.pwd`. | ![aab](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/67d91b3d-af21-4158-8dbd-7f89a196049e.png) :::info Esta configuración debe estar en su lugar antes de subir cualquier archivo `.aab`. Las subidas fallarán durante el procesamiento si la configuración del keystore falta o es incorrecta. Consulta los [Códigos de error de procesamiento de Builds](https://docs.applivery.com/es/app-distribution/builds/processing-error-codes/) para ver los detalles de los errores. ::: **Subir tu archivo AAB** Una vez configurado el keystore, puedes subir tu archivo `.aab` usando cualquiera de los siguientes métodos: - **Panel de control**: Ve a la sección **Builds** de tu App y selecciona o arrastra y suelta tu archivo `.aab`. - **API de subida**: Usa el mismo método de subida que los APKs estándar. Consulta la [documentación de la API de subida](https://docs.applivery.com/es/app-distribution/api/builds/upload-build/) para más detalles. - **Integraciones CI/CD**: Usa cualquiera de las integraciones existentes de Applivery con plataformas CI/CD populares como Fastlane, Jenkins, Bitrise o Azure DevOps. Una vez subido, Applivery procesará automáticamente el bundle, extraerá el APK universal usando bundletool, lo firmará con tu configuración de keystore y lo pondrá disponible para su distribución. --- ## Convertir Keystore a JKS Source: https://docs.applivery.com/es/app-distribution/platforms/android/convert-keystore-to-jks/ Description: Convierte tu archivo keystore de Android a formato JKS usando el comando keytool para proteger el proceso de firma de tu App. TL;DR: Convierte tu keystore de Android al formato JKS usando el comando `keytool` para firmar apps de forma segura. Answers: ¿Qué es un archivo keystore de Android? · ¿Cómo convierto un archivo keystore a JKS? · ¿Qué contraseñas se necesitan al convertir a JKS? · ¿Qué comando debo usar para convertir un keystore a JKS? Si estás desarrollando una aplicación Android, es posible que hayas creado un archivo keystore durante el proceso de firma. - **Keystore**: Un archivo keystore en el desarrollo Android actúa como un contenedor seguro para almacenar claves criptográficas y certificados. Se usa para firmar paquetes de apps Android (APKs o Android App Bundles) antes de su distribución a través de tiendas de apps como Google Play o directamente a los usuarios. Este proceso de firma garantiza que ni la tienda de apps ni los usuarios reciban una App que haya sido manipulada o modificada por fuentes no autorizadas. - **JKS**: JKS son las siglas de Java Keystore, un formato de archivo propio de Java. Los archivos keystore con formato `.jks` se usan ampliamente para almacenar claves en aplicaciones basadas en Java. Sigue estos pasos para convertir un archivo Keystore existente en un archivo JKS: **Abre el Terminal o el símbolo del sistema** Inicia tu interfaz de línea de comandos (Terminal en macOS/Linux, o CMD/PowerShell en Windows). **Navega a la ubicación del archivo Keystore** Usa el comando `cd` para navegar al directorio que contiene tu archivo `.keystore`. **Ejecuta el comando de conversión** Ejecuta el siguiente comando **keytool** para crear un archivo `.jks` a partir de tu archivo `.keystore` actual: ```bash keytool -importkeystore -srckeystore yourapp.keystore -destkeystore yourapp.jks -deststoretype jks ``` Reemplaza `yourapp.keystore` con el nombre de tu archivo keystore existente y `yourapp.jks` con el nombre deseado para el archivo JKS de salida. Al ejecutar el comando, se te pedirá que proporciones las siguientes contraseñas: - **Contraseña del Keystore de origen**: La contraseña de tu archivo `.keystore` actual. - **Contraseña del Keystore de destino**: La nueva contraseña para el archivo `.jks`. **Asegúrate de que esta contraseña sea segura y única**. Una vez que el comando se complete correctamente, se creará un archivo `.jks`. Este archivo puede usarse para firmar tu app Android antes de subirla. --- ## Apps Privadas Self-Hosted Source: https://docs.applivery.com/es/app-distribution/platforms/android/self-hosted-private-apps/ Description: Distribuye apps Android privadas self-hosted a través de Managed Google Play con Applivery — cubre la configuración, publicación y pasos de lanzamiento. TL;DR: Distribuye tus apps privadas auto-alojadas en Android a través de Managed Google Play configurando la URL de tu servidor de apps en Applivery. Answers: ¿Qué se necesita para gestionar apps self-hosted con Applivery y Google Play? · ¿Cómo hago mi app privada en Google Play Console para Applivery? · ¿Dónde encuentro mi ID de organización Android MDM de Applivery? · ¿Cómo subo y lanzo la app en Google Play Console? Además de las muchas funcionalidades que ofrece la [Managed Play Store para gestionar tus Apps Privadas](https://docs.applivery.com/es/device-management/android/app-management/private-app-distribution/), también puedes gestionar y distribuir las Apps que tienes alojadas en Applivery u otra plataforma. Hay algunos **requisitos y pasos** que debes seguir para habilitar esta funcionalidad: 1. Debes tener una Licencia activa de Android Developer. 2. No puedes usar las cuentas gestionadas de Google Play que se generan automáticamente al subir Apps a través de tu Managed Play Store, ya que estas cuentas no están —ni pueden estar— vinculadas a una cuenta activa de Android Developer. 3. Las apps privadas self-hosted deben configurarse en la cuenta de Google Play con una Licencia activa de Android Developer. Una vez que estés seguro de que cumples estos requisitos, puedes proceder con los siguientes pasos de configuración: ### Crear y configurar una nueva App en tu Google Play Console **Crear una nueva App en Google Play Console** Ve a la [Google Play Console](https://play.google.com/console) e inicia sesión con tu cuenta de Android Developer. Una vez dentro, haz clic en el botón **Crear app** y rellena el formulario. ![google-play-console-create-app | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ccaa35bc-310e-46bf-a032-3077f8d08f45.png) **Completar la información de la ficha de tu tienda** Una vez creada, deberás completar la información de la ficha de la App con todos los detalles, incluyendo iconos, capturas de pantalla, descripciones, etc. ![google-play-console-store-listing | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ba9112df-4e40-451a-95ee-8b57f2225642.png) **Hacerla privada y compartirla con tu Managed Google Play de Applivery** Recuerda que estás creando y subiendo una App a tu cuenta de Google Play, que no es la misma cuenta que has configurado en Applivery, por lo que el siguiente paso es muy importante: 1. Haz tu App privada. 2. Compártela con la Managed Play Store de Applivery. Vuelve a la **Google Play Console** y, dentro de tu App, navega a la sección **Configuración > Ajustes avanzados**, dirígete a la pestaña **Managed Google Play** y activa la opción _Acceso restringido a tu app y gestionar pistas de prueba cerradas_. A continuación aparecerá una nueva sección que restringirá qué organizaciones tendrán acceso a tu App. Haz clic en el botón **Añadir organización** e introduce tu ID de organización Android MDM de Applivery. Puedes encontrarlo en tu [**panel de Applivery**](https://dashboard.applivery.io) navegando a **Configuración** y, desde el menú lateral izquierdo, seleccionando **Configuración Android**. En la parte superior de esa sección encontrarás el Enterprise ID. Asegúrate de guardar los cambios. Una vez hecho, tu App solo estará disponible para los usuarios de tu MDM de Applivery. ![play-console-share-org | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/6f990c8b-1973-4f5b-9057-2e005d0efee3.png) ### Configurar el proyecto de Applivery **Obtener la clave pública RSA de tu App** Ahora que la ficha de tu App está completada, dirígete a la sección **Configuración de monetización > Licencias**. Allí encontrarás la clave pública RSA de tu App codificada en Base64, que Applivery usará para proteger y verificar el origen de las descargas desde tu Managed Play Store. **Copia la cadena.** La necesitarás en el siguiente paso. ![google-play-console-rsa | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/adedb5c4-63e5-46ed-ba87-f94ca6fcf159.png) **Configurar tu App en el panel de Applivery** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io), navega a tu App. Una vez allí, dirígete a la sección **Ajustes > Avanzado**. Pega la clave pública RSA bajo el área de texto **Clave de licencia de Google Play**. ![google play license key](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/c63eb4b8-c083-4273-9536-fd4a9f0c3f56.png) **Subir una nueva Build** [Sube una nueva Build Android](https://docs.applivery.com/es/app-distribution/getting-started/upload-first-build/) a tu App. Applivery generará automáticamente un archivo JSON con toda la información de tu App. Una vez finalizada la subida, haz clic en la Build y descarga el archivo JSON haciendo clic en **Descargar JSON**. ![download json file](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/bd067057-e06d-4589-a652-079a019d2c6e.png) ### Subir y lanzar la App Ahora que todo está listo y siguiendo en la Google Play Console, inicia un nuevo **lanzamiento de Producción**. **Elige el archivo JSON** que acabas de descargar en el paso anterior y súbelo en la sección **App Bundles y APKs**. Completa el resto de los campos. Una vez listo, haz clic en **Guardar y revisar lanzamiento** para completar el proceso. Revisa toda la información en la siguiente pantalla y, una vez listo, haz clic en **Iniciar despliegue en Producción** para lanzar tu App. Ten en cuenta que, aunque no hay revisión de Google para las Apps Privadas Self-Hosted, tardará unas horas en estar disponible para los usuarios. ![play-store-release | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/2c9d764c-5064-4ea4-80c4-e9852ed872fb.png) --- ## Fuentes desconocidas Source: https://docs.applivery.com/es/app-distribution/platforms/android/unknown-sources/ Description: Habilita la instalación de apps desde fuentes desconocidas en Android de forma segura — cubre el modelo de permisos por app y el comportamiento de Google Play Protect. TL;DR: Aprende a instalar apps desde fuentes desconocidas en Android de forma segura concediendo permisos por app y evitando riesgos de seguridad en todo el dispositivo. Answers: ¿Por qué Android bloquea la instalación de apps de Applivery? · ¿Cómo permito que Applivery instale apps en Android? · ¿Qué versión de Android introdujo el permiso por app para fuentes desconocidas? · ¿Mi dispositivo sigue protegido si permito instalaciones desde fuentes desconocidas? ![unknown sources](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/f7f20415-e62e-423e-a8f1-3959358b1680.jpeg) El sistema operativo Android incluye una función de seguridad integrada que bloquea la instalación de Apps procedentes de fuentes externas a Google Play Store. Esto significa que si intentas instalar una App a través de Applivery por primera vez, es posible que encuentres un mensaje de advertencia. #### Lo que podrías ver Al intentar instalar una App desde Applivery, puede aparecer un mensaje como este: :::danger Instalación bloqueada Por tu seguridad, tu teléfono no está autorizado actualmente para instalar apps desconocidas desde esta fuente. Puedes cambiarlo en Ajustes. ::: Antes de Android 8.0 (Oreo), los usuarios podían activar un ajuste global para permitir las instalaciones desde fuentes desconocidas. Sin embargo, con la introducción de **Android 8.0** (**nivel de API 26**), este enfoque cambió a un modelo de **permiso por app**. Ahora, en lugar de un único ajuste, los usuarios deben conceder permiso individualmente a cada App para que pueda instalar aplicaciones desconocidas. Este cambio mejora la seguridad al garantizar que solo las Apps de confianza puedan instalar archivos `.apk` desconocidos. Para más detalles, consulta la documentación oficial de Android Developers disponible en este [enlace](https://developer.android.com/studio/publish#publishing-unknown). ![device alert unknown sources](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/72ff92cf-d443-4703-9615-36e2c1706888.png) ### Cómo habilitar la instalación de Apps desde Applivery Para continuar con la instalación, sigue estos pasos: **Abre los Ajustes** Abre los **Ajustes** de tu dispositivo. **Navega a Apps** Navega a **Apps** y pulsa en **Acceso especial a apps** (esto puede estar en **Avanzado**, según tu dispositivo). **Selecciona Instalar apps desconocidas** Selecciona **Instalar apps desconocidas**. **Concede el permiso** Aquí encontrarás una lista de Apps que te permiten solicitar permiso para instalar desde fuentes desconocidas. Para conceder acceso, simplemente elige la App que usarás para descargar o instalar el `.apk` (por ejemplo, Chrome o tu gestor de archivos) y activa **Permitir desde esta fuente**. :::warning Una vez activado, puedes reintentar la instalación de la App. Ten en cuenta que **activar esta opción permitirá la instalación de apps desde todas las fuentes, no solo desde Applivery**. ::: ### Sigues estando protegido Aunque permitas instalaciones desde fuentes desconocidas, tu dispositivo sigue estando protegido. [Google Play Protect](https://www.android.com/intl/es_es/play-protect/) seguirá analizando las Apps en busca de posibles amenazas como malware o comportamiento perjudicial, independientemente de su procedencia. Si se detecta algo sospechoso, la App se bloqueará automáticamente. **Plataforma de Distribución de Apps** Distribuye tus Apps con una interfaz de usuario amigable y familiar, impulsada por una Store Enterprise web totalmente personalizable. Protege tus despliegues sincronizando tu directorio de usuarios y habilitando la seguridad empresarial a través de la Distribución de Apps de Applivery. --- ## Apple Source: https://docs.applivery.com/es/app-distribution/platforms/apple/ Description: Distribuye y gestiona aplicaciones iOS y macOS de forma segura en tu organización con Applivery. Aprende sobre tipos de firma, recopilación de UDIDs, distribución beta y resolución de problemas. TL;DR: Applivery permite distribuir y gestionar apps iOS y macOS de forma segura dentro de una organización, cubriendo firma de apps, recopilación de UDIDs y resolución de problemas. Answers: ¿Qué es la Gestión de Apps Apple en Applivery? · ¿Qué tipos de firma de apps admite Applivery para iOS? · ¿Por qué recopilar UDIDs para dispositivos iOS en Applivery? · ¿Cómo resuelvo problemas de instalación de apps iOS en Applivery? · ¿Cómo gestiono los avisos de "Desarrollador Enterprise no fiable"? · ¿Puedo excluir el SDK de iOS de Applivery de las Builds de producción? Key topics: Tipos de firma de apps iOS, Recopilación de UDIDs, Distribución de apps iOS, Integración del SDK, Apple, Applivery, iOS, macOS, UDID, SDK Applivery te permite distribuir y gestionar aplicaciones iOS y macOS de forma segura en toda tu organización. Puedes recopilar UDIDs para el aprovisionamiento de dispositivos, conocer los tipos de firma de apps (Ad-Hoc, Enterprise, Development, TestFlight), resolver problemas de instalación y trabajar con los requisitos de distribución específicos de la plataforma Apple. --- ## Tipos de firma de apps Source: https://docs.applivery.com/es/app-distribution/platforms/apple/app-signing-types/ Description: Tipos de firma de apps de Apple explicados: Ad-Hoc, Enterprise (In-House), Development y TestFlight — diferencias, casos de uso y limitaciones. TL;DR: Esta guía explica los diferentes tipos de firma de apps de Apple (Ad-Hoc, Enterprise, Development, TestFlight) y sus casos de uso. Answers: ¿Qué tipos de firma de apps iOS/macOS admite Applivery? · ¿Para qué es mejor la firma Ad-Hoc? · ¿Cuántos dispositivos admite la firma Enterprise? · ¿Cuándo debo usar TestFlight? Cada app iOS y macOS debe estar firmada criptográficamente antes de poder instalarse en un dispositivo. El tipo de firma determina quién puede instalar la App, en cuántos dispositivos, cómo se distribuye y qué certificados y perfiles de aprovisionamiento se requieren. Applivery admite apps firmadas con **Enterprise (In-House)**, **Ad-Hoc**, **Development** y **TestFlight**. Elegir el tipo de firma adecuado para tu caso de uso es una de las primeras decisiones que debes tomar al configurar tu flujo de distribución. :::warning Los detalles que se indican a continuación están definidos por Apple y pueden cambiar en cualquier momento sin previo aviso. Consulta siempre la [documentación oficial de Apple](https://developer.apple.com/programs/) para obtener la información más actualizada. ::: * * * ### Tipos de firma de un vistazo | Tipo de perfil | Audiencia | Límite de dispositivos | Caducidad de la Build | Validez del certificado | Coste | | --- | --- | --- | --- | --- | --- | | **Ad-Hoc** | Dispositivos registrados específicos | 100 dispositivos | 1 año | 3 años | 99 $ / año | | **Enterprise (In-House)** | Empleados y colaboradores de la organización | Ilimitado | 1 año | 3 años | 299 $ / año | | **Development** | Dispositivos de desarrollador registrados | 100 dispositivos | 1 año | 3 años | Gratuito (incluido con el Apple Developer Program) | | **TestFlight** | Testers registrados (internos o externos) | 10.000 testers | 90 días por Build | N/A | 99 $ / año | * * * ### Ad-Hoc La distribución Ad-Hoc te permite instalar una app firmada en un conjunto específico de dispositivos preregistrados. Es el tipo de firma más común para distribuir Builds previas al lanzamiento a un grupo controlado de testers o partes interesadas. #### Cómo funciona Antes de firmar la App, recopilas los UDIDs de cada dispositivo que necesita instalarla y los añades a un perfil de aprovisionamiento. La app firmada solo puede instalarse en esos dispositivos específicos. #### Características clave - Requiere conocer el UDID de cada dispositivo objetivo con antelación. - Se necesita actualizar el registro de dispositivos y el perfil de aprovisionamiento cada vez que añades un nuevo dispositivo. - Máximo de **100 dispositivos** por cuenta de Apple Developer (compartido entre perfiles Ad-Hoc y Development). - Las Builds caducan tras **1 año** desde la fecha de firma. #### Ideal para Grupos de prueba internos pequeños o medianos, equipos de QA y distribuciones de vista previa para clientes donde tienes una lista definida y manejable de dispositivos objetivo. * * * ### Enterprise (In-House) El Apple Developer Enterprise Program permite a las organizaciones firmar y distribuir Apps internamente a un **número ilimitado de dispositivos**, sin pasar por la App Store ni registrar UDIDs individuales de dispositivos. #### Cómo funciona Las apps se firman con un certificado Enterprise y pueden instalarse en cualquier dispositivo perteneciente a la organización, siempre que el dispositivo confíe en el certificado de la organización. Los usuarios suelen instalar la App a través de un enlace directo o una plataforma de distribución interna como Applivery. #### Características clave - No requiere registro de UDID del dispositivo. - Sin límite de dispositivos — adecuado para despliegues internos a gran escala. - Apple exige que las Apps distribuidas de esta manera sean **usadas únicamente por empleados o colaboradores oficiales** de la organización. La distribución al público general es una violación de los términos de Apple y puede resultar en la revocación del certificado. - Las Builds caducan tras **1 año** desde la firma; el propio certificado Enterprise dura **3 años**. - Requiere ser miembro del [Apple Developer Enterprise Program](https://developer.apple.com/programs/enterprise/), sujeto al proceso de aprobación de Apple. #### Ideal para Grandes organizaciones que distribuyen Apps internas propietarias a toda su plantilla sin involucrar la App Store. :::warning Los certificados Enterprise conllevan una gran responsabilidad. Si Apple detecta un uso indebido — como distribuir Apps a usuarios externos a la organización — puede revocar el certificado, dejando inmediatamente de funcionar todas las Apps firmadas con él en todos los dispositivos donde estén instaladas. ::: * * * ### Development El tipo de firma Development está pensado principalmente para probar Apps durante el proceso de desarrollo en un pequeño conjunto de dispositivos conocidos. Funciona de manera similar a Ad-Hoc en cuanto a los requisitos de registro de dispositivos. #### Cómo funciona Se crea un perfil de aprovisionamiento de Development que contiene los UDIDs de dispositivos específicos. La app firmada solo puede instalarse en esos dispositivos registrados. Xcode se usa normalmente para desplegar directamente, aunque el `.ipa` también puede distribuirse manualmente. #### Características clave - Requiere registrar el UDID de cada dispositivo objetivo en el perfil de aprovisionamiento. - Máximo de **100 dispositivos** (compartido con Ad-Hoc en la cuenta de Apple Developer). - Para **apps macOS**, la firma Development es la única forma de distribuir una app firmada con el Apple Developer Program para pruebas fuera de la Mac App Store. - Gratuito con cualquier membresía del Apple Developer Program. #### Ideal para Pruebas de desarrollo durante la fase de Build, o distribución de Builds de prueba de macOS a un pequeño equipo interno. * * * ### TestFlight TestFlight es la plataforma oficial de pruebas beta de Apple, integrada en el ecosistema de la App Store. A diferencia de los otros tipos de firma, TestFlight no usa un perfil de aprovisionamiento tradicional — Apple gestiona la distribución directamente después de que subas la Build. #### Cómo funciona Subes tu App a App Store Connect, donde pasa por un proceso de revisión antes de estar disponible para los testers. Los testers instalan la app TestFlight y acceden a tu Build a través de ella — no pueden instalar el `.ipa` directamente. #### Características clave - Requiere membresía en el [Apple Developer Program](https://developer.apple.com/programs/) (99 $ / año). - Las Builds están disponibles durante **90 días** antes de expirar automáticamente. - Admite hasta **10.000 testers externos** mediante invitación por email o un enlace público. - Los testers internos (hasta 100) pueden recibir Builds inmediatamente sin revisión de la App Store. - Los testers externos requieren una revisión Beta App Review antes de poder acceder a la Build. - No puede usarse para distribuir un `.ipa` directamente — los testers deben usar la app TestFlight. #### Ideal para Programas de pruebas beta a gran escala, investigación con usuarios externos y validación previa al lanzamiento antes de la presentación en la App Store. * * * ### Elegir el tipo de firma adecuado | Escenario | Tipo de firma recomendado | | --- | --- | | Distribución a un pequeño equipo de QA con dispositivos conocidos | Ad-Hoc | | Distribución de una app interna a todos los empleados a escala | Enterprise (In-House) | | Probar una Build en tu propio dispositivo de desarrollo | Development | | Distribución de Builds de prueba de macOS fuera de la Mac App Store | Development | | Ejecutar un programa de beta a gran escala con testers externos | TestFlight | | Lanzar una App al público general | App Store _(no compatible con Applivery)_ | * * * ### Nota sobre la firma para la App Store La firma para la App Store es un tipo separado que no está incluido en la tabla anterior. Es exclusivamente para apps destinadas a la distribución pública a través de la App Store oficial de Apple y **no puede usarse en Applivery**. Los sistemas MDM y las plataformas de distribución empresarial como Applivery están diseñados para gestionar e implementar Apps privadas o internas, no Apps publicadas en la App Store. * * * ### Lecturas adicionales - [Apple Developer Program](https://developer.apple.com/programs/) - [Apple Developer Enterprise Program](https://developer.apple.com/programs/enterprise/) - [Descripción general de TestFlight](https://developer.apple.com/testflight/) - [Perfiles de aprovisionamiento — Documentación de Apple](https://developer.apple.com/documentation/xcode/distributing-your-app-to-registered-devices) --- ## Depurar la instalación de apps iOS Source: https://docs.applivery.com/es/app-distribution/platforms/apple/debug-ios-app-installation/ Description: Resuelve problemas de instalación de apps iOS con Xcode. Conecta tu dispositivo, accede a la consola y analiza los registros para identificar y resolver incidencias. TL;DR: Usa Xcode para depurar problemas de instalación de apps iOS analizando los logs del dispositivo y filtrando el proceso `installd` para identificar el error. Answers: ¿Qué necesito para depurar la instalación de una app de Applivery? · ¿Cómo conecto mi dispositivo Apple a Xcode para depurar? · ¿Cómo abro la consola del dispositivo en Xcode? · ¿Cómo encuentro los registros de instalación en la consola de Xcode? En caso de que todas las opciones anteriores fallen, te recomendamos depurar el proceso de instalación de tu App. Necesitarás lo siguiente: - Un dispositivo Apple real (iPhone o iPad). - Un cable USB. - Un Mac. - Xcode instalado en tu Mac. :::info Estos problemas no pueden ser atendidos por nuestro equipo de Ingeniería ya que no tenemos acceso a tu código fuente ni a tu Apple Developer Portal. ::: **Conecta tu dispositivo al Mac y abre Xcode** Empieza conectando tu dispositivo Apple a tu Mac. Es posible que aparezca una alerta pidiéndote que **Confíes** en tu ordenador. Haz clic en **Confiar** para continuar. Una vez hecho, abre **Xcode** en tu Mac y selecciona **Window > Devices and Simulators** desde el menú de la barra superior o usa el siguiente atajo de teclado **Shift + Command + 2**. ![xcode-window | Applivery](https://www.applivery.com/wp-content/uploads/2021/12/xcode-window-1024x805.png "xcode-window | Applivery") **Abre la consola del dispositivo** Una vez que Xcode haya reconocido tu dispositivo, selecciónalo desde el menú lateral izquierdo en la sección **Devices > Connected** y haz clic en el botón **Open Console**. ![Devices-and-simulators | Applivery](https://www.applivery.com/wp-content/uploads/2021/12/devices-and-simulators-1024x597.png "devices-and-simulators | Applivery") **Encuentra los registros apropiados** Se abrirá una nueva pantalla. Asegúrate de que tu dispositivo iOS está seleccionado en el menú lateral izquierdo y haz clic en el botón **Start** en la parte superior. Los registros comenzarán a mostrarse en pantalla. En el cuadro de búsqueda de la parte superior derecha, puedes filtrar por `Process: installd`, que es el nombre del proceso responsable de la instalación de Apps en tu dispositivo. Ahora, **en tu dispositivo iOSdirígete a la Store Enterprise de Applivery e inicia una nueva instalación de la App**. Deberían aparecer varios registros; léelos detenidamente para entender exactamente dónde está el problema de instalación. Puedes hacer clic en cada línea para ver el mensaje de error completo en la parte inferior de la pantalla. ![xcode-console | Applivery](https://www.applivery.com/wp-content/uploads/2021/12/xcode-console-1014x1024.png "xcode-console | Applivery") --- ## Excluir el SDK de las Builds de producción de iOS Source: https://docs.applivery.com/es/app-distribution/platforms/apple/exclude-sdk-ios-production/ Description: Excluye el SDK de Applivery de tus Builds de producción de iOS usando configuraciones de Xcode y flags del compilador para evitar el rechazo en la App Store. TL;DR: Excluye el SDK de Applivery de tus builds de producción iOS usando configuraciones de Xcode y flags del compilador. Answers: ¿Por qué no debo usar el SDK de Applivery en apps de producción en tiendas de apps? · ¿Cómo excluyo el SDK de Applivery de las Builds de producción en iOS? · ¿Qué es un archivo .xcconfig? · ¿Cómo uso el SDK de forma condicional en mi código? Como ya sabrás, no está permitido usar el SDK de Applivery en Apps de producción que se lancen en las Tiendas de Apps oficiales (Google Play y Apple App Store). Además, es una práctica que no recomendamos y que podría causar el rechazo de tu App durante el proceso de revisión. Puedes excluir condicionalmente el SDK de Applivery según el entorno de la App (por ejemplo, Live, Test, Staging o Quality). :::info Necesitas conocer los conceptos básicos de cómo gestionar diferentes entornos usando Esquemas y Configuraciones. Si no es así, echa un vistazo al siguiente [artículo del blog](https://www.freecodecamp.org/news/managing-different-environments-and-configurations-for-ios-projects-7970327dd9c9/). ::: **Crear archivos de configuración (.xcconfig) para cada entorno** Ve a **File > New > File… (Command + N) -> Configuration Settings file** y elige un nombre descriptivo para tu archivo de configuración. Para este ejemplo, crearemos dos archivos de configuración diferentes: uno para el entorno de desarrollo (`DEV.xcconfig`) y otro para el entorno de producción (`PROD.xcconfig`). **DEV.xcconfig** ``` // App Info APP_NAME = My Awesome App [DEV] BUNDLE_IDENTIFIER = com.acme.awesome.dev // Environment ENVIRONMENT = DEV // Applivery Options APPLIVERY_TOKEN = b7C...2I6 ``` **PROD.xcconfig** ``` // App Info APP_NAME = My Awesome App [PROD] BUNDLE_IDENTIFIER = com.acme.awesome.prod // Environment ENVIRONMENT = PROD // Applivery Options APPLIVERY_TOKEN = 1gxC...66f EXCLUDED_SOURCE_FILE_NAMES = Applivery.framework ``` Como no queremos que el SDK de Applivery esté incluido en el entorno de Producción, hemos añadido la siguiente línea de código `EXCLUDED_SOURCE_FILE_NAMES = Applivery.framework` que excluirá los archivos fuente del SDK de Applivery durante el proceso de compilación de la App. Además, aprovecharemos este archivo de configuración para definir también un token del SDK de Applivery diferente para cada uno de los entornos. **Vincular los archivos de configuración con los esquemas de tu proyecto** Ahora que tenemos varios archivos de configuración que describen las particularidades de tus entornos, es momento de vincularlos con los esquemas de tu proyecto. Para hacerlo, en los **ajustes de Configuraciones del proyecto**, selecciona el archivo de configuración apropiado usando el menú desplegable **Build Configurations**. ![ios-sdk-configurations-002 | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/4b937ac6-bcfa-44a2-bd33-d5469e2c6cad.png) **(Opcional) Usar las variables del archivo de configuración en tu código** ![ios-sdk-configurations-003 | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/a4d9fc97-2ef7-4354-9d7a-19f3d584b8ca.png) Además, para usar las **claves** del `Info.plist` en tu código, puedes seguir el siguiente enfoque: ```swift // Get values from Info.plist public func InfoDictionary(_ key: String) -> String { guard let constant = Bundle.main.infoDictionary?[key] as? String else { return "CONSTANT NOT FOUND" } return constant } // Example of usage of the above function when starting the Applivery SDK applivery.start(token:InfoDictionary("APPLIVERY_TOKEN"), appStoreRelease: false) ``` **Usar el SDK de forma condicional** Dado que el **import** del SDK de Applivery ha sido excluido desde el archivo `.xcconfig` al compilar el código, recomendamos usar **Swift Compiler Custom Flags y Active Compilation Conditions** para declarar un conjunto de constantes que te ayuden a iniciar el SDK de Applivery de forma condicional. Aquí tienes un ejemplo: ```swift #if !APPSTORE import Applivery #endif struct AppliveryWrapper { func setup() { #if !APPSTORE && !DEBUG let applivery = Applivery.shared applivery.logLevel = .info applivery.start(token:InfoDictionary("APPLIVERY_TOKEN"), appStoreRelease: false) #endif } } ``` ![ios-sdk-configurations-004 | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/88f9c11a-9677-4a6c-8986-d5d090a0a574.png) Alternativamente, si no quieres usar archivos de configuración, puedes excluir ciertos **nombres de archivos fuente** en los **Build Settings** de tu proyecto para cada uno de tus esquemas. :::tip Recuerda probar tu App a fondo en todos los entornos para asegurarte de que el SDK de Applivery está correctamente excluido de las Builds de producción. ::: --- ## Recopilación de UDID Source: https://docs.applivery.com/es/app-distribution/platforms/apple/udid-collection/ Description: Recopila identificadores únicos de dispositivos iOS (UDID) con Applivery para distribuir Builds beta y alpha a dispositivos específicos. TL;DR: Applivery simplifica la recogida de UDIDs de iOS para la distribución de apps en beta a través de su tienda empresarial, eliminando el registro manual de dispositivos. Answers: ¿Qué es un UDID? · ¿Por qué se necesitan UDIDs para las apps iOS? · ¿Cómo recopila Applivery los UDIDs? · ¿Dónde se almacenan los UDIDs recopilados en Applivery? :::warning Esta es una funcionalidad premium que puede no estar disponible en tu plan actual. Consulta la disponibilidad en nuestra [página de precios](https://www.applivery.com/pricing/). ::: UDID son las siglas de **Unique Device Identifier** (Identificador Único de Dispositivo). Es un valor de 40 caracteres alfanuméricos y es usado por Apple para el registro de dispositivos. Los UDIDs son necesarios si quieres instalar versiones alpha o beta de apps iOS antes de que sean lanzadas en la App Store oficial de Apple. Los desarrolladores necesitan estos identificadores para incluirlos en los Perfiles de aprovisionamiento de las apps alpha y beta antes de que sean firmadas y distribuidas. Siempre puedes conectar tu iPhone/iPad a tu ordenador y obtener el UDID, IMEI y otros detalles usando iTunes. Sin embargo, Applivery proporciona una forma fácil y amigable de recopilar UDIDs a través de las Stores Enterprise de Applivery, en un entorno web totalmente personalizado y guiado. :::info Applivery proporciona la funcionalidad de recopilación de UDID. Una vez recopilados, debes añadir los UDIDs al perfil de aprovisionamiento, y eres responsable de la firma del código y la generación del paquete. ::: ### Cómo funciona Una vez que la funcionalidad de recopilación de UDID esté habilitada en tu organización, puedes empezar a recopilar UDIDs desde la URL de tu Store Enterprise, dependiendo de si usas un dominio o subdominio personalizado: - `{workspace_slug}.applivery.io/collect` - `tu-dominio-de-app-store.com/collect` - `tu.subdominio-de-app-store.com/collect` :::info Se pedirá a los usuarios que usen **Safari** para navegar a este sitio, ya que es obligatorio para instalar los perfiles necesarios. ::: Una vez allí, los usuarios solo tienen que seguir los diferentes pasos: **Descargar el perfil** Haz clic en el botón **Descargar** para iniciar la descarga del perfil. **Permitir la descarga del perfil** **Permite** la descarga del perfil cuando se te solicite. **Instalar el perfil** Ve a **Ajustes > Perfil descargado** y haz clic en **Instalar**. A continuación puedes ver el proceso completo: ![udid collection part 1](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/02e88757-c8f4-4993-9e91-69ba6eb82eca.png)![udid collection part 2](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/433b84be-7353-4afd-ab7a-7227e50f63f3.png) ### Recuperar los UDIDs Todos los UDIDs registrados se almacenarán automáticamente en tu cuenta bajo la sección **Inventario**. Los registros proporcionarán la siguiente información: - Nombre del dispositivo. - Número de serie. - UDID. - Fecha de recopilación. En los casos donde la autenticación esté activada a nivel de tienda, los registros también incluirán la dirección de email del usuario que autorizó la recopilación. También puedes usar el botón **Descargar CSV** para iniciar la descarga de todos los registros en un único archivo CSV. Además, puedes consultar el [método GET de la entidad Inventory API](https://api.applivery.io/openapi#tag/InventoryItem/paths/~1organizations~1:organizationId~1inventory-items~1/get). --- ## Desarrolladores Enterprise no fiables Source: https://docs.applivery.com/es/app-distribution/platforms/apple/untrusted-enterprise-developer/ Description: Soluciona el error "Untrusted Enterprise Developer" en iOS confiando manualmente en el certificado Enterprise del desarrollador en tu dispositivo. TL;DR: Para ejecutar apps en beta en iOS, debes confiar en el certificado de desarrollador Enterprise en Ajustes > General > VPN y gestión del dispositivo. Answers: ¿Por qué mi app iOS dice "Untrusted Enterprise Developer"? · ¿Cómo confío en un desarrollador Enterprise en iOS? · ¿Dónde está la Gestión de dispositivos en los ajustes de iOS? · ¿Tengo que confiar en el desarrollador cada vez que actualizo la app? Desde iOS 9, los testers deben _confiar_ en el certificado de desarrollador Enterprise Apple de tu organización antes de ejecutar distribuciones beta. Este es un proceso que solo se realiza una vez. Al ejecutar una App desde un certificado en el que no se confía, los testers verán el mensaje **Untrusted Enterprise Developer**. Pueden confiar en el certificado siguiendo los pasos a continuación: **Navegar a Gestión de dispositivos** Ve a **Ajustes** > **General** > **Gestión de dispositivos** en tu dispositivo iOS. **Selecciona el perfil del desarrollador** Localiza y selecciona el perfil del desarrollador en la sección **ENTERPRISE APPS**. **Confía en el desarrollador** Pulsa **Confiar en "\[Nombre del desarrollador\]"**. **Confirma la confianza** Selecciona **Confiar** para confirmar. ![untrusted enterprise developer](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/75b3c86e-c26f-4a71-861c-e4528de1a7c2.png) Recuerda confiar únicamente en los desarrolladores Enterprise que conozcas y en los que confíes. --- ## Plataformas de Build personalizadas Source: https://docs.applivery.com/es/app-distribution/platforms/custom-platforms/ Description: Las Plataformas de Build personalizadas de Applivery amplían la Distribución de Apps más allá del móvil: distribuye Builds para consolas de videojuegos, runtimes web y más. TL;DR: Las plataformas de build personalizadas de Applivery te permiten distribuir builds a cualquier plataforma, incluidas consolas de videojuegos, smart TVs y wearables. Answers: ¿Qué plataformas admiten las Plataformas de Build personalizadas de Applivery? · ¿Qué formatos de archivo admiten las plataformas personalizadas? · ¿Cómo habilito las Plataformas personalizadas en Applivery? · ¿Cómo subo una Build para una Plataforma personalizada? Por defecto, Applivery es compatible de forma nativa con Builds de Android, iOS, macOS y Windows. Las **Plataformas de Build personalizadas** amplían esto para cubrir cualquier plataforma a la que distribuya tu equipo — incluyendo consolas de videojuegos, tiendas alternativas, runtimes web y formatos de archivo — todo gestionado a través del mismo flujo de trabajo de Applivery. Esto es especialmente útil para estudios de videojuegos, equipos de desarrollo multiplataforma y organizaciones que distribuyen a dispositivos o entornos fuera de los cuatro principales sistemas operativos móviles y de escritorio. * * * ### Capacidades clave **Soporte de plataforma ampliado** — sube y distribuye Builds para plataformas más allá de iOS, Android, macOS y Windows, incluyendo PlayStation, Xbox, Nintendo Switch, Steam y más. **Configuración manual de metadatos** — a diferencia de las plataformas nativas, donde Applivery extrae los metadatos automáticamente del archivo de Build, las Plataformas personalizadas requieren que proporciones el `packageName`, `packageVersion` y opcionalmente `packageIcon` de forma manual en el momento de la subida. **Gestión unificada** — todas las Builds, independientemente de la plataforma, se gestionan en el mismo Workspace de Applivery y son accesibles a través de la misma [API de subida](https://docs.applivery.com/es/app-distribution/api/builds/upload-build/), manteniendo tu flujo de trabajo de distribución consistente en todos los objetivos. **Distribución de archivos en bruto** — las Plataformas personalizadas distribuyen los archivos de build en su formato original sin procesamiento automatizado, dándote control total sobre lo que se entrega. * * * ### Plataformas y extensiones de archivo compatibles Todas las plataformas personalizadas admiten `.zip` y `.tar.gz` como formatos de contenedor universales. A continuación se listan las extensiones compatibles específicas de cada plataforma: | Identificador de plataforma | Extensiones admitidas | | --- | --- | | `android` | `.apk`, `.aab` | | `amazon` | `.apk`, `.aab` | | `flexion` | `.apk`, `.aab` | | `ios` | `.ipa` | | `macos` | `.pkg`, `.dmg` | | `macos-archive` | `.zip`, `.tar.gz` | | `windows` | `.msi`, `.exe`, `.msix`, `.appx`, `.msixbundle`, `.appxbundle` | | `windows-archive` | `.zip`, `.tar.gz` | | `ps4` | `.pkg` | | `ps5` | `.pkg` | | `switch` | `.nsp` | | `xbox-one` | `.zip`, `.tar.gz` | | `xbox-series` | `.zip`, `.tar.gz` | | `steam` | `.zip`, `.tar.gz` | | `steam-mac` | `.zip`, `.tar.gz` | | `epic` | `.zip`, `.tar.gz` | | `epic-mac` | `.zip`, `.tar.gz` | | `web` | `.unityweb`, `.wasm`, `.js`, `.html` | :::info Todas las plataformas también admiten `.zip` y `.tar.gz` como formatos de archivo genéricos, independientemente de las extensiones listadas arriba. ::: * * * ### Cómo subir una Build para una Plataforma personalizada **Sube tu archivo** Sigue el proceso estándar de subida de Builds descrito en [Cómo subir tu primera Build](https://docs.applivery.com/es/app-distribution/getting-started/upload-first-build/). Puedes subir a través del panel de control o la [API de subida](https://docs.applivery.com/es/app-distribution/api/builds/upload-build/). Si subes un archivo `.zip` o `.tar.gz` que no corresponde a una plataforma nativa, Applivery te pedirá que selecciones la Plataforma personalizada objetivo en el siguiente paso. **Selecciona la Plataforma personalizada** Tras subir, selecciona la plataforma para la que está destinada la Build desde el selector de Plataforma personalizada. Esto indica a Applivery cómo categorizar y mostrar la Build dentro de tu Workspace. ![upload build for custom platform](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/a8a00bf3-bb23-4ec0-a6c6-c5e53272d447.png) **Proporciona los metadatos de la Build** Como las Plataformas personalizadas no realizan extracción automática de metadatos, debes proporcionar la siguiente información manualmente: | Campo | Obligatorio | Descripción | | --- | --- | --- | | `packageName` | Sí | El identificador único de tu App o build (por ejemplo: `com.studio.mygame`). | | `packageVersion` | Sí | La cadena de versión para esta Build (por ejemplo: `1.4.2`). | | `packageIcon` | No | Una imagen de icono para representar la Build en la interfaz de Applivery. | ![required fields custom platforms](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/11476b4f-43fb-4357-9a0b-236b5c36fa6d.png) Una vez enviada, la Build aparecerá en la sección Builds de tu App junto a cualquier otra Build del proyecto. * * * ### Cómo habilitar las Plataformas personalizadas Las Plataformas de Build personalizadas no están habilitadas por defecto y deben activarse a nivel de Workspace. Para ver tus plataformas habilitadas actualmente, dirígete al [**panel de Applivery**](https://dashboard.applivery.io), navega a la sección **Configuración** 1 y selecciona **Plataformas de Build** 2 desde el menú lateral izquierdo. ![build platforms](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/eaa35661-27da-426a-9e59-7471833da260.png) :::info Para habilitar las Plataformas personalizadas en tu Workspace, contacta con el equipo de soporte de Applivery en [support@applivery.com](mailto:support@applivery.com). Habilitaremos la funcionalidad y te ayudaremos a configurar las plataformas específicas que necesitas. ::: * * * ### Usar la API de subida con Plataformas personalizadas Las Plataformas personalizadas están totalmente soportadas a través de la API de subida de Applivery, lo que te permite integrar las subidas de Builds en tu pipeline CI/CD igual que harías con plataformas nativas. Se usa el mismo endpoint — simplemente especifica el identificador de plataforma personalizada en tu petición. Consulta la [documentación de la API de subida](https://docs.applivery.com/es/app-distribution/api/builds/upload-build/) para todos los detalles sobre el formato de la petición, la autenticación y los parámetros requeridos, incluyendo `packageName` y `packageVersion` para Builds de plataformas personalizadas. --- ## SDK Source: https://docs.applivery.com/es/app-distribution/sdk/ Description: Integra la distribución de apps y la gestión de usuarios directamente en tus aplicaciones con el SDK de Applivery. Entrega actualizaciones in-app y gestiona usuarios fácilmente. TL;DR: El SDK de Applivery permite integrar distribución de apps, actualizaciones OTA y gestión de usuarios directamente en apps iOS y Android con unas pocas líneas de código. Answers: ¿Para qué se usa el SDK de Applivery? · ¿Puedo usar el SDK de Applivery en lanzamientos de la App Store o Google Play? · ¿Cómo instalo el SDK de Applivery para iOS? · ¿Cómo inicializo el SDK de Applivery? · ¿Cómo asocio usuarios autenticados con las sesiones de Applivery? · ¿Cómo personalizo los colores del SDK de Applivery? Key topics: Integración del SDK, Distribución de apps, Gestión de usuarios, Applivery, SDK, iOS, Android El SDK de Applivery es una librería ligera para iOS y Android que añade gestión de actualizaciones OTA, actualizaciones forzadas, informes de feedback y vinculación de usuarios directamente en tu App. Está diseñado para Builds de distribución interna y beta — no para lanzamientos de producción en la App Store o Google Play. El SDK se integra con unas pocas líneas de código y no requiere que tus usuarios finales tengan cuenta en Applivery. :::info El SDK actualiza siempre al **Build más reciente disponible** para la App, haciendo coincidir únicamente el bundle ID o el package name. No respeta los filtros de Publicación, ni grupos ni audiencias, ya que en el momento de actualizar no se puede identificar la Publicación desde la que se descargó originalmente un Build. Si necesitas aislar las actualizaciones por flavor o por funcionalidad, crea una app de Applivery independiente para cada variante, con una sola Publicación cada una. ::: * * * ### Funcionalidades **Actualizaciones automáticas OTA** Avisa a los usuarios cuando hay una versión nueva disponible y les permite instalarla con un solo toque. **Actualizaciones forzadas** Bloquea el uso de la app y fuerza la actualización cuando la versión instalada está por debajo de la versión mínima configurada en el panel de Applivery. **Feedback y reporte de errores** Los usuarios pueden reportar errores o enviar feedback haciendo una captura de pantalla o grabando un vídeo. La información del dispositivo se adjunta automáticamente. **Vinculación de usuarios** Asocia tus propios usuarios autenticados con las sesiones de Applivery, para analítica, seguimiento de descargas y atribución del feedback. **iOS SDK** **Versión actual:** 4.5.4 **Versión mínima de iOS:** 15.0 **Lenguaje:** Swift **Distribución:** Swift Package Manager (recomendado), CocoaPods (obsoleto) **Repositorio:** [applivery/applivery-ios-sdk](https://github.com/applivery/applivery-ios-sdk) #### Instalación ##### Swift Package Manager (recomendado) En Xcode, ve a **File → Add Package Dependencies** e introduce: ``` https://github.com/applivery/applivery-ios-sdk.git ``` Establece la regla de dependencia en **Up to next major version** (`4.0.0 < 5.0.0`). Se te pedirá elegir entre dos targets: | Target | Cuándo usarlo | | --- | --- | | `Applivery` | Úsalo cuando la App sea estrictamente interna y nunca se vaya a enviar a la App Store. Framework estático. | | `AppliveryDynamic` | Úsalo cuando distribuyas internamente con Applivery pero también publiques en la App Store. El framework se puede excluir en tiempo de compilación para los esquemas de App Store. | :::info **Envíos a la App Store:** incluir el SDK de Applivery en un build de App Store no está permitido y tu envío puede ser rechazado. Usa `AppliveryDynamic` y exclúyelo de la configuración de build de App Store — consulta [Excluir condicionalmente el SDK de iOS de Applivery](https://docs.applivery.com/es/app-distribution/platforms/apple/exclude-sdk-ios-production/) para las instrucciones paso a paso. ::: ##### CocoaPods (obsoleto) ```ruby pod 'Applivery', '~> 4.5' ``` #### Configuración inicial Inicializa el SDK al principio del ciclo de vida de tu App, normalmente en `AppDelegate` o `SceneDelegate`: **Swift** ```swift import Applivery let applivery = AppliverySDK.shared applivery.start(token: "YOUR_APP_TOKEN", tenant: "YOUR_TENANT") ``` **Objective-C** ```objc @import Applivery; AppliverySDK *applivery = [AppliverySDK shared]; [applivery startWithToken:@"YOUR_APP_TOKEN" tenant:@"YOUR_TENANT"]; ``` El parámetro `tenant` es opcional. Si lo omites, el SDK usa el host por defecto de Applivery. Tu **App Token** está disponible en **Ajustes de la App → API Tokens**, en el panel de Applivery. #### Configuración Pasa un objeto `AppliveryConfiguration` a `start()` para personalizar el comportamiento del SDK: **Swift** ```swift import Applivery let config = AppliveryConfiguration( postponedTimeFrames: [3600, 86400], // Opciones de aplazamiento en segundos que se muestran al usuario cuando hay una actualización enforceAuthentication: true // Exige que el usuario inicie sesión antes de usar el SDK ) AppliverySDK.shared.start( token: "YOUR_APP_TOKEN", tenant: "YOUR_TENANT", configuration: config, skipUpdateCheck: false ) ``` **Objective-C** ```objc NSArray *timeFrames = @[@3600, @86400]; AppliveryConfiguration *config = [[AppliveryConfiguration alloc] initWithPostponedTimeFramesNSNumber:timeFrames enforceAuthentication:YES]; ``` | Propiedad | Tipo | Descripción | | --- | --- | --- | | `postponedTimeFrames` | `[TimeInterval]` | Intervalos de tiempo en segundos que se muestran como opciones de "recordármelo más tarde" en el diálogo de actualización. Máximo 3 opciones. | | `enforceAuthentication` | `Bool` | Si es `true`, los usuarios tienen que iniciar sesión en Applivery antes de poder usar la App. Por defecto: `false`. | #### Métodos principales de la API | Método | Descripción | | --- | --- | | `start(token:tenant:configuration:skipUpdateCheck:)` | Inicializa el SDK. Llámalo una sola vez al arrancar la app. | | `checkForUpdates(forceUpdate:)` | Comprueba si hay un build más reciente y propone al usuario actualizar. Pasa `forceUpdate: true` para ignorar cualquier aplazamiento. | | `isUpToDate() -> Bool` | Devuelve `true` si el número de build actual coincide con el último disponible. No respeta los filtros de Publicación. | | `update(onDownload:)` | Descarga e instala el último Build de inmediato. | | `setCheckForUpdatesBackground(_ enabled: Bool)` | Comprueba automáticamente si hay actualizaciones cuando la App vuelve de segundo plano. | | `feedbackEvent()` | Muestra la interfaz de feedback de forma programática (por ejemplo, al agitar el dispositivo). | | `enableScreenshotFeedback()` / `disableScreenshotFeedback()` | Activa o desactiva la detección de capturas de pantalla para lanzar el feedback. | | `bindUser(email:firstName:lastName:tags:onComplete:)` | Asocia una identidad de usuario con la sesión actual, para analítica y seguimiento del feedback. | | `unbindUser(onComplete:)` | Elimina el usuario vinculado actualmente. | | `getUser(onSuccess:)` | Devuelve el perfil del usuario vinculado como un diccionario. | | `handleRedirectURL(url:)` | Gestiona las URLs de redirección de autenticación SAML. Llámalo desde `AppDelegate` o `SceneDelegate`. | | `setLogHandler(_ handler:)` | Define un manejador de logs propio para capturar o redirigir los logs de Applivery. | #### Personalización **Colores de la interfaz** ```swift AppliverySDK.shared.palette = Palette( primaryColor: .orange, secondaryColor: .white, primaryFontColor: .white, secondaryFontColor: .black, screenshotBrushColor: .green ) ``` **Literales de texto** — traduce o adapta a tu marca los mensajes del SDK: ```swift AppliverySDK.shared.textLiterals = TextLiterals( appName: "MyApp", otaUpdateMessage: "A new version is available. Update now?", forceUpdateMessage: "This version is no longer supported. Please update to continue." ) ``` **Registro de logs** ```swift applivery.logLevel = .info // .none | .error | .info | .debug ``` | Nivel | Recomendado para | | --- | --- | | `.none` | Producción (por defecto) | | `.error` | Desarrollo | | `.info` | Probar la integración del SDK | | `.debug` | Depurar las peticiones y respuestas del SDK | #### Compatibilidad con Swift y Xcode | Versión del SDK | Xcode | Swift | | --- | --- | --- | | v4.0+ | 13.x+ | 5.x | | v3.4 | 13.x | 5.x | | v3.2 | 12.x | 5.x | | v2.7.x | 9.x – 10.x | 4.0, 4.2 | **Android SDK** **Versión actual:** 5.0.0 **Versión mínima de Android:** Android 7.0 (API level 24) **Lenguaje:** Kotlin **Distribución:** Maven Central **Repositorio:** [applivery/applivery-android-sdk](https://github.com/applivery/applivery-android-sdk) #### Instalación Añade la dependencia al `build.gradle` de tu App. El SDK está pensado para Builds que no son de producción: ```kotlin // Usa debugImplementation para que Applivery solo se ejecute en builds de debug o de testing debugImplementation("com.applivery:applivery-sdk:${latestVersion}") ``` **Artefacto no-op para Builds de release** Para no tener que montar una configuración compleja de source sets que excluya el SDK de los Builds de release, usa el artefacto no-op. Expone la misma API pública que el SDK completo, pero no hace nada en tiempo de ejecución: ```kotlin releaseImplementation("com.applivery:applivery-sdk-no-op:${latestVersion}") ``` Así puedes llamar a los métodos del SDK de Applivery desde cualquier punto de tu código sin que afecte a los Builds de release. #### Configuración inicial Inicializa el SDK en el método `Application.onCreate()`: ```kotlin import com.applivery.android.sdk.Applivery import com.applivery.android.sdk.start class MyApplication : Application() { override fun onCreate() { super.onCreate() Applivery.start(APPLIVERY_TOKEN) // Para instancias privadas de Applivery, pasa también el tenant: // Applivery.start(APPLIVERY_TOKEN, TENANT) } } ``` :::info En proyectos Java (versión 4.0.0 o superior), usa la clase `AppliveryInterop` para acceder a la funcionalidad del SDK. ::: Tu **App Token** está disponible en **Ajustes de la App → API Tokens**, en el panel de Applivery. #### Configuración Pasa un objeto `Configuration` a `Applivery.start()` para personalizar el comportamiento: ```kotlin val configuration = Configuration( postponeDurations = listOf(2.hours, 30.minutes, 5.minutes), enforceAuthentication = false, downloadAction = BuildDownloadAction.IMMEDIATE ) Applivery.start(APPLIVERY_TOKEN, configuration = configuration) ``` | Propiedad | Tipo | Descripción | | --- | --- | --- | | `postponeDurations` | `List` | Opciones que se muestran al usuario para aplazar una actualización disponible. Máximo 3 opciones. | | `enforceAuthentication` | `Boolean` | Si es `true`, los usuarios tienen que iniciar sesión antes de usar el SDK. Por defecto: `false`. | | `downloadAction` | `BuildDownloadAction` | `IMMEDIATE` instala la actualización en cuanto termina la descarga. `DEFERRED` muestra una notificación y deja que el usuario decida cuándo instalarla. | #### Gestión de actualizaciones ```kotlin // Comprobar actualizaciones manualmente Applivery.getInstance().checkForUpdates() // Comprobar automáticamente cuando la app vuelve de segundo plano Applivery.getInstance().setCheckForUpdatesBackground(true) // Descargar la última actualización sin instalarla de inmediato val callback = object : DownloadLastUpdateCallback { override fun onSuccess(update: CachedAppUpdate) { update.install() // instalar cuando esté listo } override fun onError(error: Throwable) { /* gestionar el error */ } } Applivery.getInstance().downloadLastUpdate(callback) // Activar la descarga automática en segundo plano Applivery.getInstance().enableDownloadLastUpdateBackground(callback) // Lanzar descarga e instalación inmediatas (sigue el downloadAction configurado) Applivery.getInstance().update() ``` :::warning `enableDownloadLastUpdateBackground` y `setCheckForUpdatesBackground` son mutuamente excluyentes. Activar uno desactiva el otro. ::: #### Feedback ```kotlin // Activar o desactivar el feedback por captura de pantalla Applivery.getInstance().enableScreenshotFeedback() Applivery.getInstance().disableScreenshotFeedback() // Mostrar la interfaz de feedback de forma programática Applivery.getInstance().feedbackEvent() ``` #### Gestión de usuarios ```kotlin // Vincular un usuario para analítica y seguimiento del feedback Applivery.getInstance().bindUser(email, firstName, lastName, tags) // Eliminar el usuario vinculado Applivery.getInstance().unbindUser() // Obtener el usuario actual Applivery.getInstance().getUser(getUserCallback) ``` #### Permisos necesarios El SDK necesita los siguientes permisos en tiempo de ejecución. Solicítalos en tu App antes de usar las funciones que los requieren: | Permiso | Para qué se usa | | --- | --- | | `POST_NOTIFICATIONS` | Mostrar notificaciones durante las descargas de actualizaciones y la grabación de pantalla | | `READ_MEDIA_IMAGES` | Detección de capturas de pantalla para el feedback (en Android 14+ se requiere acceso completo) | | `SYSTEM_ALERT_WINDOW` | Grabación de pantalla para el feedback | #### Personalización de la interfaz Crea un archivo `res/values/applivery.xml` para sobrescribir los colores y textos por defecto: ```xml #FF0241E3 #FF0241E3 #FF010258 A new version is available. Update now? This version is outdated. Please update to continue. ``` --- ## Usuarios del SDK Source: https://docs.applivery.com/es/app-distribution/sdk/sdk-users/ Description: Usuarios del SDK de Applivery — usuarios vinculados y temporales, cómo vincularlos y desvincularlos, aplicación de autenticación y seguimiento del uso y feedback de la App. TL;DR: Los usuarios SDK de Applivery son registros creados automáticamente para los dispositivos que ejecutan apps con el SDK, permitiendo su seguimiento y gestión desde el panel. Answers: ¿Cuáles son los dos tipos de usuarios del SDK en Applivery? · ¿Cómo identifica Applivery a los usuarios del SDK? · ¿Cuánto tiempo duran los Usuarios SDK temporales? · ¿Cuándo debo llamar a `bindUser()` en mi app? El SDK de Applivery crea y registra usuarios automáticamente para cada dispositivo que ejecuta una App con el SDK integrado. Estos registros aparecen en el panel de Applivery y te permiten obtener información sobre quién instala tus Apps, quién reporta feedback y cómo se adoptan las Builds en tu base de usuarios. Los usuarios del SDK se dividen en dos tipos según su origen: **usuarios del SDK** (identidades vinculadas y con nombre) y **usuarios temporales del SDK** (anónimos, basados en el dispositivo). Ambos cuentan como empleados dentro del límite de empleados de tu Workspace. :::info Tanto los usuarios del SDK como los usuarios temporales del SDK cuentan para la cuota de **Store Employees** de tu Workspace. ::: --- ### Tipos de usuarios del SDK | | Usuario SDK | Usuario temporal del SDK | |---|---|---| | **Origen** | Creado mediante programación a través de `bindUser()` | Creado automáticamente por el SDK en el primer lanzamiento del dispositivo | | **Duración** | Permanente | Caduca tras 30 días de inactividad en todas las Apps de tu organización | | **Identificador** | Dirección de email que proporcionas. Ej. `jane@example.com` | ID del dispositivo. Ej. `6effd10a-5b00-45ec-b02d-580b53a5775c` | | **Descripción** | Empleados con nombre y una identidad conocida, vinculados a la sesión a través de `bindUser()` | Usuarios desconocidos creados automáticamente para rastrear dispositivos únicos. Únicos en tu Workspace basándose en el ID del dispositivo. | :::info La **inactividad** se define como la última vez que un usuario abrió cualquier App de tu organización con el SDK integrado. El contador de 30 días se reinicia en cada apertura. ::: --- ### Usuarios del SDK (vinculados) Cuando llamas a `bindUser()` con una dirección de email, Applivery vincula la sesión del dispositivo actual a una identidad con nombre. Esto te permite: - Ver quién descargó o instaló cada Build. - Atribuir informes de feedback y envíos de errores a una persona concreta. - Rastrear la adopción de actualizaciones por usuario con nombre. - Controlar el acceso a la app por identidad de usuario cuando la aplicación de autenticación está activada. Los usuarios vinculados aparecen con su dirección de email en el panel de Applivery, facilitando la correlación de la actividad del SDK con tu propia base de usuarios. ### Usuarios temporales del SDK (anónimos) Cuando un dispositivo ejecuta el SDK por primera vez sin una llamada a `bindUser()`, Applivery crea automáticamente un registro de Temporal SDK User identificado por el ID único del dispositivo. Estos registros permiten analíticas básicas a nivel de dispositivo (instalaciones, adopción de actualizaciones) incluso cuando no hay ninguna identidad con nombre disponible. Los usuarios temporales del SDK caducan tras 30 días de inactividad. Si el mismo dispositivo vuelve a abrir la App después de la caducidad, se crea un nuevo registro de Temporal SDK User. --- ### Vincular un usuario Llama a `bindUser` después de que se complete el flujo de autenticación propio de tu App, para que la identidad sea conocida antes de que se produzca cualquier interacción con Applivery. **iOS (Swift)** ```swift AppliverySDK.shared.bindUser( email: "user@example.com", // Obligatorio firstName: "Jane", // Opcional lastName: "Doe", // Opcional tags: ["beta", "ios-team"] // Opcional — se usa para filtrar en el panel ) { // callback onComplete — se llama cuando se confirma la vinculación } ``` **iOS (Objective-C)** ```objc [[AppliverySDK shared] bindUserWithEmail:@"user@example.com" firstName:@"Jane" lastName:@"Doe" tags:@[@"beta", @"ios-team"] onComplete:nil]; ``` **Android (Kotlin)** ```kotlin Applivery.getInstance().bindUser( email = "user@example.com", firstName = "Jane", lastName = "Doe", tags = listOf("beta", "android-team") ) ``` ##### Parámetros de `bindUser` | Parámetro | Tipo | Obligatorio | Descripción | |---|---|---|---| | `email` | String | Sí | La dirección de email del usuario. Se usa como identificador principal en el panel de Applivery. | | `firstName` | String | No | El nombre del usuario. Se muestra junto al email en informes y feedback. | | `lastName` | String | No | El apellido del usuario. | | `tags` | Array de Strings | No | Etiquetas personalizadas para agrupar o filtrar usuarios en el panel. Ej. `["qa", "ios"]`. | --- ### Desvincular un usuario Llama a `unbindUser` cuando el usuario de tu App cierre sesión, para que las interacciones posteriores del SDK ya no se atribuyan a esa identidad. **iOS (Swift)** ```swift AppliverySDK.shared.unbindUser { // callback onComplete } ``` **iOS (Objective-C)** ```objc [[AppliverySDK shared] unbindUserWithOnComplete:nil]; ``` **Android (Kotlin)** ```kotlin Applivery.getInstance().unbindUser() ``` :::info Tras desvincular, la sesión del SDK vuelve al modo anónimo hasta que se vuelva a llamar a `bindUser`. ::: --- ### Obtener el usuario actual Puedes leer el perfil del usuario vinculado actualmente en cualquier momento: **iOS (Swift)** ```swift AppliverySDK.shared.getUser { userInfo in // userInfo es un NSDictionary, o nil si no hay ningún usuario vinculado print(userInfo ?? "No user bound") } ``` **Android (Kotlin)** ```kotlin Applivery.getInstance().getUser(object : GetUserCallback { override fun onSuccess(user: AppliveryUser?) { // user es null si no hay ningún usuario vinculado } override fun onError(error: Throwable) { /* gestionar */ } }) ``` --- ### Aplicación de autenticación Si tu Publicación requiere que los usuarios inicien sesión antes de acceder a la App, puedes imponer esto a nivel del SDK. Cuando `enforceAuthentication` está establecido en `true` en la configuración del SDK, los usuarios deben autenticarse a través de Applivery (o el SSO de tu Workspace) antes de que la App sea utilizable. **iOS** ```swift let config = AppliveryConfiguration( enforceAuthentication: true ) AppliverySDK.shared.start(token: "YOUR_TOKEN", configuration: config) ``` **Android** ```kotlin val config = Configuration( enforceAuthentication = true ) Applivery.start(APPLIVERY_TOKEN, configuration = config) ``` :::info Cuando la aplicación está activada y el usuario no se ha autenticado, Applivery mostrará un prompt de inicio de sesión. Si `enforceAuthentication` es `false` (el valor predeterminado), los usuarios pueden descartar el prompt de inicio de sesión y continuar usando la App de forma anónima. ::: --- ### Visibilidad de los usuarios en el panel Los usuarios del SDK son visibles por app en el panel de Applivery o en la sección Directorio bajo el menú de Ajustes. Para cada usuario puedes ver: - Dirección de email y nombre para mostrar (para usuarios vinculados). - Etiquetas asignadas a través de `bindUser`. - Dispositivos asociados al usuario. - Historial de descargas — qué Builds se instalaron. - Envíos de feedback atribuidos al usuario. Los usuarios anónimos aparecen con un identificador de dispositivo en lugar de una dirección de email. --- ### Usuarios del SDK frente a otros tipos de usuario Applivery tiene varios tipos de usuario diferenciados. Entender las diferencias ayuda a evitar confusiones: | Tipo de usuario | Quiénes son | Cómo se autentican | Dónde aparecen | |---|---|---|---| | **Colaboradores** | Miembros del equipo que gestionan la App (desarrolladores, responsables de QA) | Cuenta de Applivery o SSO | Panel → Equipo | | **Empleados de la Store** | Usuarios finales con acceso a las Publicaciones de la Store Enterprise | Cuenta de Applivery, SSO, contraseña u OTP | App → Usuarios (Store) | | **Usuarios SDK** | Usuarios de una App con el SDK integrado | A través de `bindUser` en el código de la App | App → Usuarios (SDK) | | **Usuarios OTP** | Usuarios externos con acceso limitado en el tiempo a una Publicación | Contraseña de un solo uso enviada por email | App → Publicación → Lista de permisos OTP | Los usuarios del SDK son el único tipo creado mediante programación desde dentro de la propia App. Todos los demás tipos se gestionan a través del panel de Applivery o la API. --- ## Resolución de problemas Source: https://docs.applivery.com/es/app-distribution/troubleshooting/ Description: Resuelve problemas de distribución de apps: errores de instalación, problemas de firma, compatibilidad de dispositivos y problemas de red para una entrega fluida de apps. TL;DR: Esta sección ayuda a resolver los problemas más comunes en la Distribución de Apps: instalación, firma, compatibilidad y red. Answers: ¿Cuáles son los problemas más comunes en la distribución de apps? · ¿Cómo soluciono errores de instalación de apps? · ¿Qué causa los problemas de firma y aprovisionamiento de apps? · ¿Cómo resuelvo problemas de compatibilidad de dispositivos? · ¿Qué problemas de red afectan a la distribución de apps? Key topics: Errores de instalación, Firma y aprovisionamiento, Compatibilidad de dispositivos, Problemas de red, Applivery, iOS, Apple Developer Portal Identifica y resuelve los problemas más comunes en la Distribución de Apps — desde fallos de instalación y errores de firma hasta problemas de compatibilidad de dispositivos y errores relacionados con la red. Cada artículo explica los síntomas, las causas más probables y los pasos para solucionar el problema para que puedas volver a distribuir cuanto antes. --- ## Problemas de instalación de apps Source: https://docs.applivery.com/es/app-distribution/troubleshooting/unable-to-download-install-application/ Description: Diagnostica y resuelve los problemas más comunes de instalación de apps iOS: descargas bloqueadas, iconos en gris e incidencias en la verificación de integridad. TL;DR: Resuelve los problemas más comunes de instalación de apps iOS verificando la conectividad de red, los perfiles de aprovisionamiento, los certificados de firma y la compatibilidad de la versión iOS. Answers: ¿Por qué la barra de progreso de instalación de la app iOS no avanza? · ¿Por qué la instalación de mi app iOS se queda en "Esperando..."? · ¿Qué significa que el icono de la app iOS se vuelva gris oscuro y no sea pulsable tras la instalación? · ¿Qué causa el error "No se puede instalar — la integridad no se pudo verificar" en iOS? ![unable to install](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/92554d69-31a0-4b97-b3ff-b5298dbd6f85.png) :::info Los problemas descritos aquí son específicos de **iOS**. Los problemas de instalación en Android suelen estar causados por el ajuste "Fuentes desconocidas" — consulta [Fuentes desconocidas en Android](https://docs.applivery.com/es/app-distribution/platforms/android/unknown-sources/) para obtener más información. ::: * * * ### Diagnóstico rápido: ¿qué estás viendo? | Síntoma | Causa más probable | | --- | --- | | La barra de progreso aparece pero no avanza | Problema de conectividad de red | | La instalación de la app se queda en "Esperando…" | Problema de conectividad de red | | El icono de la app se vuelve gris oscuro y no es pulsable | Problema con el certificado o el perfil de aprovisionamiento | | Alerta: _"No se puede instalar — la integridad no se pudo verificar"_ | Fallo en la firma del código | * * * ### La barra de progreso aparece pero no avanza **Causa:** El dispositivo no puede llegar a los servidores de descarga de Applivery. Casi siempre es un problema de red. **Resolución:** 1. Asegúrate de que el dispositivo tiene una conexión a internet estable — cambia entre Wi-Fi y datos móviles para descartar un problema específico de la conexión. 2. Cancela la descarga e inténtalo de nuevo. 3. Si el problema persiste, prueba en una red diferente. * * * ### La instalación de la app se queda en "Esperando…" **Causa:** iOS puso la instalación en cola pero no puede continuar — lo más habitual es un timeout de red durante la descarga o un estado de sobrecarga del dispositivo. **Resolución:** 1. Asegúrate de que el dispositivo tiene una conexión a internet estable e inténtalo de nuevo. 2. Si el problema persiste, apaga el dispositivo completamente, espera al menos 5 minutos, vuélvelo a encender y reinténtalo. 3. Si sigue bloqueándose, usa el [depurador de instalación de iOS](https://docs.applivery.com/es/app-distribution/platforms/apple/debug-ios-app-installation/) para obtener más detalles sobre dónde falla el proceso. * * * ### El icono de la app se vuelve gris oscuro y no es pulsable Este síntoma significa que iOS comenzó la instalación pero se detuvo antes de completarla. La causa está siempre relacionada con la configuración de firma de la App. Sigue estas comprobaciones: #### UDID del dispositivo faltante (solo distribución Ad-hoc) Si la App se firmó con un certificado **Ad-hoc**, el UDID del dispositivo debe estar incluido en el perfil de aprovisionamiento. Si no lo está, iOS fallará silenciosamente al instalar. **Resolución:** 1. En el panel de Applivery, abre los detalles de la Build y anota el UDID del dispositivo. 2. Añade el UDID a tu perfil de aprovisionamiento en el [Apple Developer Portal](https://developer.apple.com/account/). 3. Descarga el perfil de aprovisionamiento actualizado, vuelve a firmar la App y sube la nueva Build a Applivery. #### Perfil de aprovisionamiento caducado Los perfiles de aprovisionamiento tienen una validez máxima de un año. Un perfil caducado impedirá la instalación aunque el certificado de firma siga siendo válido. **Resolución:** 1. Renueva el perfil de aprovisionamiento en el [Apple Developer Portal](https://developer.apple.com/account/). 2. Reconstruye la App con el perfil actualizado y sube la nueva Build a Applivery. #### Certificado de firma caducado Tanto los certificados de firma Ad-hoc como los Enterprise caducan. Un certificado caducado invalida todas las Builds firmadas con él, aunque el perfil de aprovisionamiento siga siendo válido. **Resolución:** 1. Renueva o crea un nuevo certificado de firma en el [Apple Developer Portal](https://developer.apple.com/account/). 2. Actualiza la configuración de firma en Xcode, reconstruye la App y sube la nueva Build a Applivery. #### Otros problemas de firma Si ninguno de los puntos anteriores aplica, puede haber una discrepancia entre el certificado, el perfil y el bundle identifier. **Resolución:** 1. Verifica que el bundle identifier en tu proyecto de Xcode coincide exactamente con el del perfil de aprovisionamiento. 2. Comprueba que el certificado usado para firmar la Build es el asociado al perfil de aprovisionamiento. 3. Usa el [depurador de instalación de iOS](https://docs.applivery.com/es/app-distribution/platforms/apple/debug-ios-app-installation/) para capturar el error específico. * * * ### Alerta: _"No se puede instalar — la integridad no se pudo verificar"_ **Mensaje completo:** _No se puede instalar "Nombre de la App": Esta app no se puede instalar porque su integridad no se pudo verificar._ **Causa:** Apple comprobó la firma del código de la App después de la descarga y la encontró inválida. Esto normalmente significa que el perfil de aprovisionamiento incluido en la App no coincide con el certificado de firma, o que el perfil ha caducado. **Resolución:** 1. Comprueba el perfil de aprovisionamiento asociado a la Build — asegúrate de que no ha caducado y coincide con el certificado de firma utilizado. 2. Reconstruye la App con una combinación válida de perfil y certificado y sube la nueva Build a Applivery. 3. Si el problema persiste, usa el [depurador de instalación de iOS](https://docs.applivery.com/es/app-distribution/platforms/apple/debug-ios-app-installation/) para capturar el punto exacto del fallo. --- ## Gestión de dispositivos Source: https://docs.applivery.com/es/device-management/ Description: Gestiona y protege los dispositivos corporativos en Apple, Android y Windows con Gestión de Dispositivos de Applivery — inscribe dispositivos, aplica políticas, despliega apps y automatiza los flujos del ciclo de vida. TL;DR: La Gestión de Dispositivos de Applivery ofrece a los equipos de IT una plataforma unificada para inscribir, configurar y proteger dispositivos corporativos en Apple, Android y Windows. Answers: ¿Qué es la Gestión de Dispositivos en Applivery? · ¿Qué plataformas admite la Gestión de Dispositivos de Applivery? · ¿Puede Applivery aplicar reglas de cumplimiento en los dispositivos? · ¿Admite Applivery comandos remotos en los dispositivos? · ¿Cumple Applivery con los protocolos MDM de Apple y Android Enterprise? Key topics: Gestión de dispositivos, MDM, Inscripción de dispositivos, Configuración de políticas, Comandos remotos, Applivery, Apple MDM, Android Enterprise, Windows MDM La Gestión de Dispositivos de Applivery ofrece a los equipos de IT todo lo necesario para inscribir, configurar y proteger los dispositivos corporativos — en Apple (iOS, macOS), Android y Windows — desde un único panel en la nube. Con pleno cumplimiento del protocolo MDM de Apple, Android Enterprise y Windows MDM, cubre el ciclo de vida completo del dispositivo: desde la inscripción y la configuración de políticas hasta el despliegue de apps, la ejecución de scripts, los comandos remotos y la automatización de flujos de trabajo del ciclo de vida. --- ## Android Source: https://docs.applivery.com/es/device-management/android/ Description: Applivery gestiona dispositivos Android con Android Enterprise (GMS) y AOSP MDM para dispositivos industriales sin servicios de Google. TL;DR: Applivery gestiona dispositivos Android con Android Enterprise para GMS y AOSP MDM para entornos sin Google Mobile Services. Key topics: Gestión de dispositivos Android, Android Enterprise MDM, AOSP MDM, Funcionalidades de MDM, Despliegue de aplicaciones, Applivery, Android Enterprise, Google Mobile Services, Managed Google Play Applivery admite dos vías de gestión de Android: **Android Enterprise MDM** para dispositivos con GMS, y **AOSP MDM** para dispositivos robustos, modo quiosco e industriales que se envían sin Google Mobile Services. Ambos se gestionan desde el mismo panel de Applivery, sin necesidad de herramientas separadas. Con Android Enterprise, puedes desplegar apps a través de Managed Google Play, aplicar políticas de seguridad, configurar el modo quiosco, gestionar ajustes específicos del OEM y ejecutar comandos remotos. Con AOSP MDM, obtienes las mismas capacidades de gestión de dispositivos — distribución silenciosa de apps, políticas, modo quiosco y comandos remotos — sin ninguna dependencia de los servicios o cuentas de Google. La gestión de dispositivos Android en Applivery incluye métodos de inscripción, gestión de apps, políticas, configuraciones OEM, comandos remotos, soporte AOSP y resolución de problemas. --- ## Android Enterprise MDM Source: https://docs.applivery.com/es/device-management/android/android-enterprise-mdm/ Description: Android Enterprise MDM en Applivery: funcionalidades clave, modos de gestión y control de dispositivos Android a escala con gestión completa. TL;DR: Applivery ofrece una potente solución MDM para Android Enterprise, con funciones y soporte para diversos conjuntos de gestión, para una administración eficaz de dispositivos Android. Answers: ¿Qué es Android Enterprise MDM? · ¿Cómo soporta Applivery Android Enterprise? · ¿Cuáles son las características clave de Applivery MDM para Android? · ¿Qué son los conjuntos de gestión de Android Enterprise? · ¿Qué es Android Device Policy? · ¿Qué es Managed Google Play? · ¿Cómo inscribir dispositivos con Android Enterprise? Key topics: Android Enterprise, Gestión de dispositivos móviles, MDM de Applivery, Android Device Policy, Managed Google Play, Applivery, Google, Android Management API, Google Play API Applivery ofrece soporte completo al ecosistema de [Android Enterprise](https://www.android.com/enterprise), una iniciativa liderada por Google para permitir el uso de dispositivos y apps Android en el entorno laboral. El programa ofrece APIs (principalmente la Android Management API y la Google Play API) y otras herramientas para que los desarrolladores integren el soporte para Android en sus soluciones de gestión de movilidad empresarial (EMM). Applivery se ha convertido en **una de las soluciones EMM (Enterprise Mobility Management) más potentes**, tal como la describe y certifica Google en el [Android Enterprise EMMs Solutions Directory](https://androidenterprisepartners.withgoogle.com/provider/#!/40bMPraLqpk8Cx65JrDp). Somos **una de las pocas empresas a nivel mundial que ofrece soporte a los 4 principales conjuntos de gestión y la única que ha creado una interfaz tan fácil de usar para interactuar con las APIs de Google.** A continuación, descubrirás los conceptos más importantes sobre Android Enterprise y la solución MDM de Applivery para Android. ### Gestión de Dispositivos Android - Características clave **Plantillas de políticas** Una biblioteca completa de plantillas de políticas preconfiguradas para ahorrar tiempo operativo. **Modo quiosco** Limita de forma segura el funcionamiento de un dispositivo a una selección predefinida de apps y funciones. **Aplicación de políticas** Aplica políticas de seguridad como la complejidad de la contraseña y el cifrado. **Perfil de trabajo BYOD** Accede de forma segura a los datos de trabajo en dispositivos personales con Perfil de trabajo BYOD. **Análisis de uso** Seguimiento de ubicación y uso de apps para proporcionar una comprensión profunda de cómo se utilizan los dispositivos. **Soporte remoto** Diseñado para capacitar a los equipos de soporte de TI para solucionar problemas, diagnosticar y resolver incidencias de forma remota. **Inscripción Zero-touch** Proceso dinámico y automatizado de aprovisionamiento y configuración de dispositivos empresariales. **Actualizaciones de SO gestionadas** Asegura que los dispositivos permanezcan actualizados, seguros y conformes con los estándares de la organización. **Integraciones SSO** Accede a dispositivos, apps y recursos corporativos con un único conjunto de credenciales. **Distribución avanzada de apps** Ahorra tiempo automatizando la distribución de apps y prueba nuestra herramienta CI&CD de primera clase. * * * **Explora la Gestión de Dispositivos** La mejor solución MDM de su clase, experiencia de administración fácil de usar en una plataforma basada en la nube, diseñada para dispositivos Android, Apple y Windows. A continuación, descubrirás los conceptos más importantes sobre Android Enterprise y la solución MDM de Applivery para Android. ### Conjuntos de gestión Applivery soporta los siguientes conjuntos de gestión de Android Enterprise: - **Perfil de trabajo:** Permite la separación a nivel de plataforma de las apps y los datos de trabajo. Las empresas tienen control sobre todos los datos y las políticas de seguridad dentro del perfil de trabajo. Fuera del perfil de trabajo, el dispositivo sigue siendo adecuado para uso personal, ideal para implementaciones BYOD. - **Totalmente administrado:** Proporciona una gestión completa de MDM y apps para un control granular sobre los dispositivos propiedad de la empresa. Elige entre más de 80 configuraciones para aplicar y benefíciate del conjunto completo de funciones de gestión de apps de Android. Esta opción está diseñada para dispositivos destinados principalmente al uso corporativo. - **Dispositivo dedicado:** Transforma los dispositivos propiedad de la empresa en dispositivos diseñados para un propósito específico. Bloquéalos a una sola app o a un conjunto de apps para escenarios específicos de empleados o de cara al cliente. Aplica una amplia gama de políticas de seguridad para evitar que los usuarios salgan de las apps y accedan a la pantalla de bloqueo. - **Mobile App Management (MAM):** Benefíciate del conjunto completo de funciones de gestión de apps empresariales de Android combinado con la seguridad básica del dispositivo. Distribuye apps públicas y privadas, organiza la Play Store en los dispositivos de los usuarios y restringe el acceso a las apps de trabajo si un dispositivo no cumple con las políticas de contraseña mínimas. ### Android Device Policy Todos los dispositivos Android que una organización gestiona a través del panel de Applivery deben instalar la Android Device Policy durante la configuración. Android Device Policy es una app proporcionada por Android que aplica automáticamente las políticas de gestión establecidas en tu consola EMM a los dispositivos. La instalación de esa app será diferente según el escenario de gestión: - **Perfil de trabajo y MAM:** Los empleados o el administrador de TI serán responsables de la instalación de la app Android Device Policy desde Google Play Store. Sin embargo, Applivery guiará el proceso por correo electrónico. - **Totalmente administrados y dispositivos dedicados:** La app Android Device Policy se instalará automáticamente durante el proceso de configuración del dispositivo. ### Managed Google Play Managed Google Play es una versión empresarial de Google Play que facilita ciertas capacidades de gestión de apps para las soluciones de Android Enterprise. Combina la experiencia de usuario familiar y las funciones de App Store de Google Play con un conjunto de capacidades de gestión diseñadas específicamente para empresas. Ofrece las siguientes características: - Búsqueda de apps públicas. - Publicación básica de apps privadas. - Publicación de apps web. - Organización de apps. En los **dispositivos gestionados**, Managed Google Play es la App Store del usuario. La interfaz es similar a Google Play: los usuarios pueden buscar apps, ver los detalles de las apps e instalarlas. A diferencia de la versión pública de Google Play, los usuarios solo pueden instalar apps de Managed Google Play que su organización apruebe para ellos. ![managed-google-play-iframe | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/04e75d0b-f1c4-4b8e-8fae-a6332fe0ef25.png) **Inicia tu prueba gratuita** Prueba Applivery completamente gratis y sin límites durante 14 días. Todas tus herramientas de gestión de dispositivos en un solo lugar: dispositivos, apps, datos, seguridad y más. **Agenda una demostración** Habla con nuestros expertos para saber cómo Applivery puede optimizar tu gestión de dispositivos móviles. --- ## Android Open Source Project (AOSP) Source: https://docs.applivery.com/es/device-management/android/aosp/ Description: Applivery ofrece MDM AOSP para dispositivos Android robustos, quioscos e industriales sin GMS. Distribución silenciosa de apps y seguridad robusta. TL;DR: Applivery proporciona MDM completo para dispositivos Android AOSP y sin GMS, ofreciendo gestión integral, distribución silenciosa de apps y seguridad robusta sin Google. Answers: ¿Para qué se utiliza el MDM AOSP de Applivery? · ¿En qué se diferencia el MDM AOSP de Applivery de Android Enterprise? · ¿Cuáles son los componentes clave de la solución MDM AOSP de Applivery? · ¿Cómo distribuye Applivery las apps en dispositivos AOSP sin Google Play? · ¿Qué conjuntos de gestión ofrece Applivery para dispositivos AOSP? · ¿Puede el MDM AOSP de Applivery aplicar políticas de seguridad y acciones remotas? · ¿Cómo se inscriben los dispositivos AOSP en el MDM de Applivery? Key topics: Componentes de la solución MDM AOSP, Capacidades clave de gestión de dispositivos, Distribución de apps para dispositivos sin GMS, Funciones de seguridad y usabilidad del dispositivo, Conjuntos de gestión y aprovisionamiento, Applivery, AOSP, Android Open Source Project, Google Mobile Services, GMS, Android Enterprise, Google Play, Applivery DPC, APIs de DevicePolicyManager, Applivery Self-Service, Pushy, Android Device Policy, Zebra, Bluebird, Samsung Knox, Google Workspace Applivery proporciona MDM completo para **AOSP (Android Open Source Project)** y dispositivos Android sin GMS, ofreciendo las mismas capacidades de gestión de dispositivos a terminales robustos, quioscos y hardware industrial que se distribuyen sin Google Mobile Services. El MDM AOSP es la elección adecuada para dispositivos robustos, PDAs industriales, terminales de punto de venta, señalización digital y cualquier build de Android OEM no certificado para ejecutar servicios de Google. A diferencia de Android Enterprise, no requiere cuenta de Google, configuración de Android Enterprise ni organización de Managed Google Play. Todo se gestiona desde el mismo panel de Applivery. ### La solución AOSP de Applivery La solución MDM AOSP de Applivery se basa en tres componentes: - El **DPC** de Applivery— un agente en el dispositivo que se ejecuta como Device Owner y aplica cada política configurada en el panel de Applivery a través de las APIs nativas de Android `DevicePolicyManager`. - El **Self-Service de Applivery** — aloja e instala APKs de forma silenciosa sin ninguna dependencia de Google Play. - Un **canal de comandos en tiempo real** impulsado por Pushy — envía comandos remotos a los dispositivos e informa de los resultados al panel de Applivery. El DPC de Applivery desempeña el mismo papel que Android Device Policy en las implementaciones estándar de Android Enterprise, pero no depende de ningún servicio, cuenta o infraestructura de Google Play. ### Capacidades clave **Plantillas de políticas** Una biblioteca completa de plantillas de políticas preconfiguradas listas para aplicar a cualquier dispositivo AOSP. **Modo quiosco** Bloquea un dispositivo a una sola app o a un conjunto de apps seleccionadas, con control total sobre la barra de navegación, la barra de estado y el botón de encendido. **Aplicación de políticas** Aplica políticas de seguridad como la complejidad de la contraseña, restricciones de keyguard, protección de restablecimiento de fábrica y borrado remoto. **Distribución silenciosa de apps** Instala, actualiza y desinstala apps de forma silenciosa en dispositivos gestionados — no se requiere Google Play Store. **Gestión de Wi-Fi y certificados** Aprovisiona de forma silenciosa redes Wi-Fi corporativas (Abierta, WPA, WPA-Enterprise con EAP-TLS, PEAP y TTLS) y distribuye certificados CA y de cliente de soporte. **Soporte remoto** Bloquea, reinicia, restablece la contraseña, borra datos de apps y desinscribe dispositivos en tiempo real desde el panel de Applivery. **Aprovisionamiento de fábrica** Preinstala el DPC de Applivery en una imagen OEM y aprovisiona dispositivos automáticamente en el primer arranque, sin interacción del usuario. **Informes de estado** Informes periódicos sobre apps instaladas, configuración del dispositivo, build de software, memoria, almacenamiento, red e información de hardware. **VPN siempre activa** Fuerza todo el tráfico del dispositivo a través de una VPN corporativa con modo de bloqueo opcional y exenciones por paquete. **Configuraciones OEM** Aplica configuraciones gestionadas específicas de OEM en hardware AOSP compatible — Zebra, Bluebird, Samsung Knox y más. ### Conjuntos de gestión Applivery soporta dos conjuntos de gestión para dispositivos AOSP: - **Gestión totalmente administrada** — proporciona MDM completo y gestión de apps para un control granular sobre los dispositivos AOSP propiedad de la empresa. Elige entre más de 80 configuraciones para aplicar, incluyendo complejidad de contraseña, restricciones de keyguard, configuración de Wi-Fi, permisos de tiempo de ejecución, controles de hardware y más. - **Dispositivos dedicados** — transforma los dispositivos AOSP propiedad de la empresa en terminales dedicados. Bloquéalos a una sola app o a un conjunto de apps seleccionadas, y aplica un rango extendido de políticas de seguridad — botón de encendido, barra de navegación, barra de estado, diálogos de error del sistema y acceso a Ajustes — para evitar que los usuarios salgan de la experiencia bloqueada. ### El Self-Service de Applivery Dado que los dispositivos AOSP no tienen acceso a Google Play, toda la distribución de apps se realiza a través del [**Self-Service de Applivery**](https://docs.applivery.com/es/device-management/android/policies/agent/#portal-self-service). Es el reemplazo de Applivery para Managed Google Play en dispositivos AOSP, y proporciona: - Distribución privada de apps — sube APKs directamente desde el panel de Applivery. - Instalación, actualización y desinstalación silenciosa sin necesidad de interacción del usuario. - Configuración gestionada por app aplicada de forma silenciosa a través del DPC. - Política de permisos de tiempo de ejecución por app. - Bloquea la desinstalación y desactiva los controles de usuario. - Comprobaciones de compatibilidad y despliegue automático a todos los dispositivos inscritos que coincidan con las reglas de segmentación. ### Primeros pasos Para empezar a gestionar dispositivos AOSP con Applivery, **no** necesitas configurar Android Enterprise, vincular una cuenta de Google Workspace ni crear una organización de Managed Google Play. Todo lo que necesitas está en el lado de Applivery. El **aprovisionamiento mediante código QR** es el único método de inscripción admitido, tanto para despliegues de flota como para inscripciones puntuales. El token de inscripción **no puede inyectarse mediante ADB**. Una vez inscrito, cada dispositivo aparece en la sección de **Dispositivos** con su nombre de visualización, modelo, versión de Android y la política que se aplicó. Desde ahí, puedes gestionar apps, ejecutar comandos, editar la política y revisar informes de estado. ### Lista de funciones El DPC de Applivery opera como Device Owner utilizando las APIs nativas de Android, por lo que cada función a continuación funciona en cualquier build AOSP que incluya esas APIs — independientemente de si los servicios de Google están presentes. #### Seguridad del dispositivo - **Desafío de seguridad del dispositivo** — establece y aplica un PIN, patrón o contraseña de un tipo y complejidad definidos. - **Gestión avanzada de contraseñas** — longitud mínima, letras, números, símbolos, mayúsculas/minúsculas, historial, caducidad y umbral de borrado. - **Borrado y bloqueo remoto** — bloquea y desinscribe dispositivos de forma remota. - **Aplicación de cumplimiento** — aplica reglas de aplicación (bloquear, luego borrar) cuando los dispositivos se desvían del cumplimiento. - **Políticas de seguridad predeterminadas** — las funciones de depuración y las instalaciones de fuentes desconocidas están bloqueadas por defecto. - **Políticas de seguridad para dispositivos dedicados** — los usuarios no pueden salir de un dispositivo bloqueado. - **Gestión de seguridad de hardware** — desactiva el restablecimiento de fábrica, el arranque seguro, la transferencia de datos USB, el montaje de medios físicos, el haz NFC y la cámara. - **Política de Memory Tagging Extension (MTE)** y **modo Common Criteria** en dispositivos compatibles. #### Gestión de Apps - **Distribución silenciosa de apps** — instala, actualiza y desinstala apps sin interacción del usuario. - **Gestión de configuración gestionada** — visualiza y establece de forma silenciosa configuraciones gestionadas para cualquier app que las soporte. - **Gestión del catálogo de apps y listas blancas** — configura el catálogo de apps de trabajo mediante listas blancas o listas negras de apps. #### Gestión de Dispositivos - **Gestión de políticas de permisos de tiempo de ejecución** — establece una respuesta predeterminada (Preguntar / Conceder / Denegar) y anula por app por permiso. - **Gestión de configuración Wi-Fi** — aprovisiona de forma silenciosa Wi-Fi empresarial (Abierta, PSK, EAP-TLS, PEAP, TTLS). - **Gestión de seguridad Wi-Fi** — identidad, certificados de cliente, certificados CA, coincidencia de sufijo de dominio, coincidencia SAN. - **Gestión avanzada de Wi-Fi** — bloquea las configuraciones de Wi-Fi en dispositivos gestionados. - **Gestión de cuentas** — impide a los usuarios añadir o modificar cuentas. - **Gestión de servicios de accesibilidad** — controla qué servicios de accesibilidad se pueden habilitar. - **Gestión de uso compartido de ubicación** — fuerza ALTA\_PRECISIÓN, SOLO\_SENSORES, AHORRO\_BATERÍA o DESACTIVADO. - **Gestión de protección de restablecimiento de fábrica** — protege los dispositivos contra robos o desactívala según sea necesario. - **Control avanzado de apps** — bloquea la desinstalación, desactiva la detención forzada y el borrado de datos a través de Ajustes. - **Gestión de captura de pantalla** — bloquea las capturas de pantalla y el uso compartido de pantalla. - **Desactiva las cámaras**. - **Reinicia el dispositivo de forma remota**. - **Gestión de radio del sistema** — controla la red móvil, roaming, llamadas, SMS, tethering, tiempo de espera de Wi-Fi y Bluetooth. - **Gestión de audio del sistema** — silencia, bloquea cambios de volumen, bloquea la reactivación del micrófono. - **Gestión del reloj del sistema** — controla el reloj, la zona horaria y la configuración automática. - **Funciones avanzadas de dispositivos dedicados** — desactiva el keyguard, la barra de estado, las notificaciones y los ajustes rápidos; fuerza la pantalla encendida; evita toasts, alertas del sistema y superposiciones. #### Usabilidad del dispositivo - **Mensajes de pantalla de bloqueo** — mensaje personalizado en la pantalla de bloqueo. - **Gestión de transparencia de políticas** — mensajes de soporte cortos y largos que se muestran cuando los usuarios encuentran una restricción. - **Política de actualización del sistema** — OTAs automáticas, programadas o pospuestas. - **Gestión del modo quiosco** — fija una o varias apps a la pantalla. - **Gestión de funciones de keyguard** — desactiva la cámara, biometría, huella dactilar, reconocimiento facial, agentes de confianza, notificaciones y accesos directos. - **Recuperación de dirección MAC** — obtiene de forma silenciosa la dirección MAC del dispositivo para el inventario. - **Gestión avanzada del modo de tarea bloqueada** — controla el botón de inicio, recientes, acciones globales, notificaciones, barra de estado y keyguard mientras está en modo quiosco. - **Política avanzada de actualización del sistema** — periodos de congelación para bloquear OTAs durante rangos de fechas específicos. ### Permisos COPE en dispositivos AOSP El DPC de Applivery en AOSP se ejecuta solo como **Device Owner**. No hay perfil de trabajo ni flujo de uso personal COPE, por lo que los límites de permisos documentados para [dispositivos COPE](https://docs.applivery.com/es/device-management/android/cope-permission-limits/) no se aplican — cada restricción que configures tiene efecto a nivel de dispositivo completo. Si necesitas una división de perfil de trabajo / COPE, utiliza el flujo estándar de [MDM de Android Enterprise](https://docs.applivery.com/es/device-management/android/android-enterprise-mdm/) en dispositivos con servicios de Google. ### VPN siempre activa Fuerza todo el tráfico del dispositivo a través de una VPN corporativa, con modo de bloqueo opcional y exenciones por paquete. **Navega a Políticas** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a **Políticas** 1. Elige la política donde quieras añadir la configuración. **Añade la configuración de VPN siempre activa** En el menú de la izquierda, selecciona **Red** y busca **Paquete Vpn siempre activa** 2. ![always-on vpn package](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/f1d22d30-18cf-4cbe-a229-72e66f2c567d.png)

Configuración

Descripción

Nombre del paquete

Nombre del paquete de la app VPN a usar como VPN siempre activa.

Bloqueo activado

Cuando está activado, todo el tráfico se bloquea si la VPN no está conectada. Evita la fuga de datos fuera del túnel.

:::info La app VPN debe ser instalada forzosamente a través de la política antes de que la configuración de VPN siempre activa surta efecto. ::: ### Limitaciones actuales - **El Launcher básico no está disponible.** Depende del Device Policy Controller nativo de Android. El quiosco de aplicación única y el [Launcher avanzado](https://docs.applivery.com/es/device-management/android/policies/kiosk-mode/) sí funcionan, y el Launcher avanzado necesita Android 8 o superior. - **Las apps web de Managed Google Play no funcionan**, ya que no hay servicios de Google detrás. - **El soporte remoto no está disponible** en dispositivos AOSP. Está en desarrollo. :::info **Un detalle útil sobre lock task en AOSP.** El DPC añade **todas las apps de la política** a la lista de apps permitidas en lock task, y lanza en primer plano la marcada como quiosco. Eso te permite desplegar tu propio launcher como APK, marcarlo como app de quiosco y obtener acceso multiaplicación incluso en hardware donde el Launcher avanzado no es una opción. ::: :::info **En desarrollo** - **Soporte y control remoto** — visualiza y controla dispositivos AOSP de forma remota directamente desde el panel de Applivery. - **Perfil de trabajo** — Soporte de perfil de trabajo en dispositivos AOSP, permitiendo una clara separación entre datos corporativos y personales. ::: --- ## Gestión de apps Source: https://docs.applivery.com/es/device-management/android/app-management/ Description: Applivery gestiona la distribución y despliegue de apps Android en dispositivos inscritos. Controla instalaciones, actualizaciones y permisos. TL;DR: La gestión de apps Android en Applivery ofrece una plataforma centralizada para que las organizaciones distribuyan, desplieguen y mantengan apps en dispositivos Android inscritos. La Gestión de Apps de Android en Applivery te permite distribuir, desplegar y mantener apps en dispositivos Android inscritos a escala. Puedes gestionar las instalaciones de apps, controlar el comportamiento de las actualizaciones, aplicar políticas específicas de apps y configurar los permisos de las apps a través de Managed Google Play. Puedes distribuir apps Android de diferentes formas —apps públicas de Play Store, apps privadas y APKs autoalojados— y gestionar el comportamiento de las apps dentro de tus políticas. --- ## Gestión de permisos Source: https://docs.applivery.com/es/device-management/android/app-management/app-permissions/ Description: Gestiona los permisos de apps Android de forma centralizada con Applivery para mayor seguridad y menos intervención del usuario. TL;DR: Gestiona centralizadamente los permisos de apps Android con las propiedades gestionadas de Applivery para mejorar la seguridad, el cumplimiento y reducir la intervención del usuario. Answers: ¿Cómo pueden las organizaciones gestionar los permisos de apps en dispositivos Android con Applivery? · ¿Dónde se configuran los ajustes de permisos de apps en el panel de Applivery? · ¿Cuáles son las dos formas principales en que Applivery ofrece controlar los permisos de apps? · ¿Qué opciones están disponibles para la 'Política de permisos predeterminada' en Applivery? · ¿Cómo configuro permisos específicos e individuales para una app en Applivery? · ¿Qué beneficios tiene usar Applivery para la gestión granular de permisos de apps? · ¿Funciona la gestión de permisos de apps de Applivery en dispositivos AOSP? Key topics: permisos de apps, gestión de Android, propiedades gestionadas, Applivery, políticas de dispositivos, Android, AOSP La gestión de permisos de apps en dispositivos Android es una parte crítica de la movilidad empresarial, asegurando la seguridad, el cumplimiento y un comportamiento predecible en todas las flotas corporativas. Con Applivery, las organizaciones pueden configurar centralizadamente los permisos para cualquier app gestionada utilizando propiedades gestionadas, aplicando un control granular alineado con las necesidades empresariales, de seguridad y regulatorias. ### Acceso a la configuración de permisos de apps Una vez en el [**panel de Applivery**](https://dashboard.applivery.io), dirígete a cualquiera de tus políticas 1. Desde el menú lateral izquierdo, dirígete a **Apps** 2 y selecciona la **app** 3 cuyos permisos deseas gestionar. Se abrirá un panel lateral mostrando las propiedades gestionadas de la app, incluyendo la sección **Permisos** 4. ![app permissions](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/4c430ecd-d686-4137-b999-6273f66ae2b6.png) Applivery proporciona dos formas complementarias de controlar los permisos. #### Política de permisos predeterminada Esta opción establece el comportamiento global para todos los permisos requeridos por la app: - **Solicitar**: Se pregunta al usuario si desea permitir o denegar cada permiso. - **Conceder**: Todos los permisos requeridos se conceden automáticamente. - **Denegar**: Todos los permisos requeridos se deniegan automáticamente. Utiliza esta opción cuando desees aplicar una regla simple y uniforme a toda la app. #### Concesión de permisos (control granular) Para casos más avanzados, puedes configurar permisos específicos individualmente: **Añadir una nueva regla de permiso** Haz clic en **\+ Añadir elemento** para añadir una nueva regla de permiso. **Elegir el permiso** Elige el permiso de la lista desplegable (por ejemplo, cámara, ubicación, contactos). **Configurar la política** Configura la política para ese permiso específico: - **Solicitar**: El usuario decide si permitir o denegar. - **Conceder**: El permiso se concede automáticamente. - **Denegar**: El permiso se deniega automáticamente. Puedes añadir tantos permisos granulares como necesites, ideal para apps complejas que requieren acceso diferenciado. :::info Algunos permisos se comportan de forma distinta según el modo de gestión. La **ubicación**, por ejemplo, se puede pre-conceder de forma silenciosa en dispositivos Fully Managed y Dedicated, pero no dentro del perfil de trabajo en COPE o BYOD. Consulta [Gestión de la ubicación en dispositivos Android](https://docs.applivery.com/es/device-management/android/policies/location-management/) para el detalle completo. ::: ### ¿Por qué usar la gestión granular de permisos? Con Applivery, las organizaciones obtienen: - Mayor seguridad, al bloquear permisos innecesarios o arriesgados. - Mejor cumplimiento, asegurando que las apps se comporten dentro de los límites de la política. - Un despliegue más predecible y controlado. - Menor intervención del usuario, gracias a la gestión automatizada de permisos. - Adaptación flexible a las necesidades operativas de cualquier app. Configurar los permisos de apps con propiedades gestionadas en Applivery proporciona un control preciso y minimiza el riesgo, asegurando que las apps en los dispositivos corporativos operen de forma segura y en plena alineación con los requisitos organizativos. ### Soporte para dispositivos AOSP La gestión de permisos de apps funciona de la misma manera en AOSP — la misma política de permisos predeterminada (Solicitar / Conceder / Denegar) y concesiones de permisos por app, los mismos pasos de configuración. El DPC los aplica utilizando `DevicePolicyManager.setPermissionGrantState(...)`, sin necesidad de servicios de Google. Las concesiones granulares se aplican a apps dirigidas a **API 23 o superior**. --- ## Gestión de actualizaciones Source: https://docs.applivery.com/es/device-management/android/app-management/app-updates/ Description: Controla las actualizaciones de apps Android con Applivery. Configura políticas flexibles para garantizar la seguridad y minimizar interrupciones. TL;DR: Gestiona las actualizaciones de apps Android con Applivery usando modos de Alta Prioridad, Posponer y políticas configurables para mayor seguridad y control. Answers: ¿Cómo gestionar las actualizaciones de apps Android? · ¿Cuáles son las políticas de actualización de apps de Applivery? · ¿Cómo configurar actualizaciones de alta prioridad para apps Android? · ¿Cómo posponer las actualizaciones de apps Android? · ¿Cómo funcionan las actualizaciones de apps en dispositivos AOSP con Applivery? · ¿Cuáles son las condiciones predeterminadas para las actualizaciones automáticas de apps Android? · ¿Puede Applivery forzar las actualizaciones de apps Android? · ¿Qué beneficios tiene mantener las apps Android actualizadas en un entorno empresarial? Key topics: Gestión de Apps Android, Gestión de Dispositivos Móviles, Configuración de Applivery, Actualizaciones de Google Play Services, Applivery, Google Play Services, Android Mantener las apps en tus dispositivos Android actualizadas es esencial, no solo para acceder a las últimas características, sino también para garantizar la seguridad y un rendimiento óptimo. Las actualizaciones a menudo incluyen parches de seguridad que protegen contra vulnerabilidades, correcciones de errores que mejoran la estabilidad y optimizaciones que hacen que las apps funcionen de manera más eficiente. En entornos corporativos o al gestionar un gran número de dispositivos, gestionar estas actualizaciones manualmente puede ser lento e impráctico. Aquí es donde Applivery se vuelve inestimable. ### Controla las actualizaciones de apps y el tiempo de actualización Actualizar regularmente las aplicaciones en los dispositivos de tu organización asegura que los usuarios se beneficien de las nuevas funcionalidades, una seguridad mejorada y una mayor fiabilidad. Las actualizaciones de apps son gestionadas por Google a través de Google Play Services, y Applivery no puede forzar la actualización de una app (puedes leer más sobre esto [aquí](https://developers.google.com/android/management/control-app-updates)). Muchos factores pueden afectar los tiempos de actualización. - **Comportamiento de actualización predeterminado:** En la configuración predeterminada, las aplicaciones se actualizan automáticamente cuando se cumplen condiciones específicas: - El dispositivo se conecta a una red Wi-Fi. - El dispositivo está en modo de carga. - El dispositivo no está en uso activo. - La aplicación programada para una actualización no está abierta en primer plano. Google Play suele realizar comprobaciones de actualizaciones de aplicaciones diariamente. Por lo tanto, una actualización de aplicación podría tardar un máximo de 24 horas en entrar en la cola de actualización. Una vez que una aplicación está en cola, se actualizará automáticamente la próxima vez que se cumplan las condiciones anteriores. Puedes anular la configuración de actualización para personalizar aún más el comportamiento de actualización de apps en los dispositivos que gestionas: - **Alta Prioridad:** Este modo garantiza que tu app se mantenga actualizada, instalando la actualización inmediatamente tras la aprobación de Google Play. En caso de que tu dispositivo esté sin conexión cuando se lance una actualización, se actualizará automáticamente en el momento en que te reconectes a internet. :::warning Si la app está en uso cuando la actualización está lista para instalarse, la app se cerrará durante la actualización, lo que podría afectar a tus usuarios. ::: - **Modo Posponer:** Usa esta opción si quieres pausar las actualizaciones de una app, lo que evita que la app se actualice automáticamente durante 90 días iniciales después de que quedara desactualizada por primera vez. Después de este periodo de 90 días, la última versión disponible de la app se instala automáticamente usando el modo de actualización predeterminado. Una vez que la app se actualiza a la última versión disponible, comenzará un nuevo periodo de aplazamiento de 90 días a partir de la próxima vez que el desarrollador publique una nueva versión de la app. :::info El modo Posponer no impide que tus usuarios actualicen la app manualmente. Durante el periodo de aplazamiento de 90 días, tus usuarios pueden actualizar la app manualmente visitando la Google Play Store en sus dispositivos. ::: Para modificar el modo de actualización, dirígete a cualquiera de tus políticas 1, busca la sección **Apps** 2 en el menú lateral izquierdo y luego haz clic en la **app** que deseas modificar 3 el modo de actualización. Encuentra la opción **Modo de Actualización Automática** 4 en el panel lateral derecho que aparece y elige tu opción preferida. ![app auto update](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/b673fdaa-0be6-45e6-9bae-c07970c438c7.png) #### Política de actualización automática de apps Como alternativa, para configuraciones predeterminadas bajo **Modo de Actualización Automática**, puedes especificar cuándo deben ocurrir las actualizaciones configurando la **Política de Actualización Automática de Apps**. Puedes encontrar esta configuración navegando a tu política, seleccionando **Restricciones** en el menú de la izquierda, abriendo la pestaña **Apps** y localizando la configuración de la **Política de Actualización Automática de Apps** 5. ![app auto update policy](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/50c10534-529d-4a88-b3bc-b158e3ef07b3.png) Aquí, tendrás varias opciones para adaptar las actualizaciones de apps a tus necesidades: - **ELECCIÓN DEL USUARIO:** Esta opción otorga al usuario final control total sobre las actualizaciones automáticas. El administrador de la política no impone restricciones, permitiendo al usuario decidir cuándo y cómo actualizar las apps. - **NUNCA**: Este modo deshabilita completamente las actualizaciones automáticas. Las apps no se actualizarán por sí solas; la única forma de actualizar una app es manualmente a través de la App Store. - **SOLO Wi-Fi:** Las apps se actualizarán automáticamente solo cuando el dispositivo esté conectado a una red Wi-Fi. Esto ayuda a evitar el uso de datos móviles para actualizaciones grandes. - **SIEMPRE**: Las apps se actualizan automáticamente tan pronto como hay una nueva versión disponible, independientemente de la conexión de red (Wi-Fi o datos móviles). Esta es la opción más agresiva y puede generar cargos por datos móviles si no se monitoriza. Gestionar las actualizaciones de apps es una parte clave para mantener un entorno Android seguro y eficiente, especialmente en grandes flotas de dispositivos. Al aprovechar los diferentes modos de actualización junto con las opciones de control de usuario, puedes lograr el equilibrio adecuado entre seguridad y flexibilidad operativa. Un enfoque estratégico de las actualizaciones asegura que los dispositivos estén protegidos contra las últimas amenazas, se beneficien de mejoras de rendimiento y minimicen las interrupciones en la productividad del usuario final. En última instancia, una política de gestión de actualizaciones bien definida te da un control completo sobre tu ecosistema Android, manteniendo cada app actualizada y totalmente optimizada sin comprometer la eficiencia o la seguridad. ### Soporte para dispositivos AOSP En los dispositivos AOSP, las actualizaciones de apps funcionan de manera diferente: no hay Google Play ni Play Services involucrados. Las actualizaciones son impulsadas completamente por el panel de Applivery. **Sube una nueva versión** Sube una nueva versión de la app (con un `versionCode` superior) al [Self-Service de Applivery](https://docs.applivery.com/es/device-management/android/policies/agent/#portal-self-service), o actualiza la URL del APK alojado externamente. **Sincronización de política** El DPC de Applivery detecta la nueva versión en la próxima sincronización de política. **Descarga e instalación** El DPC descarga e instala el APK actualizado. La app conserva los datos de usuario a menos que los borres explícitamente con el comando remoto **Borrar datos de la app**. No existe el concepto de "modo de actualización automática de Play Store" en AOSP. Tú decides cuándo una versión está disponible al subirla; el DPC luego aplica la instalación automáticamente en todos los dispositivos inscritos asignados a esa política. :::info Las apps que fallan al instalarse (debido a una falta de coincidencia de firma, incompatibilidad ABI o SDK mínimo no cumplido) se marcan como no conformes en el siguiente informe de estado del dispositivo. ::: --- ## Bloquear y permitir apps Source: https://docs.applivery.com/es/device-management/android/app-management/block-allow-apps/ Description: Bloquea o permite apps en dispositivos Android gestionados con políticas de Applivery para reforzar la seguridad y el cumplimiento. TL;DR: Aprende a bloquear o permitir apps en dispositivos Android gestionados con Applivery para mejorar la seguridad y la productividad. Answers: ¿Qué es el bloqueo de apps en Applivery? · ¿Qué es la lista blanca de apps en Applivery? · ¿Cómo permito aplicaciones específicas en mis dispositivos usando Applivery? · ¿Qué opciones de instalación están disponibles para las apps de la lista blanca? · ¿Cómo puedo evitar que ciertas aplicaciones se ejecuten en los dispositivos inscritos? · ¿Qué sucede con una app una vez que se bloquea en Applivery? Key topics: gestión de dispositivos móviles, seguridad de apps, gestión de apps, Applivery, Google Play, Package Name, System App, Android Ya sea que tu objetivo sea mejorar la seguridad o optimizar la productividad, la capacidad de gestionar qué aplicaciones pueden o no ejecutarse en los dispositivos inscritos es crucial. - **El bloqueo de apps** implica la restricción selectiva de ciertas aplicaciones para que no se ejecuten en los dispositivos gestionados. Esto puede ser particularmente útil para mitigar riesgos de seguridad. Al crear una lista de bloqueo, los administradores pueden evitar que se inicien apps específicas, salvaguardando así los datos sensibles. - Por el contrario, la autorización de apps, a menudo denominada **lista blanca**, se centra en permitir que solo una lista predefinida de aplicaciones opere en los dispositivos inscritos. Este método se emplea cuando las organizaciones buscan optimizar la productividad asegurando que los usuarios tengan acceso solo a las herramientas esenciales. Al crear una lista blanca de apps, los administradores pueden garantizar que solo las aplicaciones aprobadas estén disponibles para su uso, minimizando posibles vulnerabilidades de seguridad. ### Autorizar una lista de apps **Navega a Políticas** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a cualquiera de tus políticas 1. **Accede a la gestión de apps** Desde el menú lateral izquierdo, dirígete a **Apps** 2 y haz clic en el botón **\+ Añadir App** 3. **Añade apps a la lista blanca** A través de cualquiera de las pestañas disponibles (Google Play, Nombre del paquete, App del Sistema o Applivery), puedes buscar y añadir las aplicaciones que formarán parte de tu lista blanca de aplicaciones. **Selecciona el modo de instalación** Solo será necesario seleccionar el modo de instalación deseado: - **Preinstalada**: La app se instala automáticamente y el usuario puede eliminarla. - **Instalación forzada**: La app se instala automáticamente y el usuario no puede eliminarla. - **Disponible**: La app está disponible para instalar. - **Requerida para la configuración**: La app se instala automáticamente y el usuario no puede eliminarla, e impedirá que la configuración se complete hasta que la instalación finalice. ![add app](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/e9a2cba9-1862-4ab8-8594-0c14c5ea4f20.png) ### Bloquear una lista de apps **Navega a Políticas** Al igual que si estuvieras configurando una lista blanca de apps, en el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a cualquiera de tus políticas. **Accede a la gestión de apps** Desde el menú lateral izquierdo, dirígete a **Apps** y haz clic en el botón **\+ Añadir App**. **Bloquea apps** Esta vez, al elegir el tipo de instalación de la aplicación, deberás seleccionar la opción **Bloqueada**. La app será bloqueada y los usuarios no podrán instalarla. Si la app se instaló bajo una política anterior, se desinstalará. ![block app](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ab69dfc4-4ab9-4a66-a552-a67e0eebf939.png) --- ## Propiedades gestionadas de Google Chrome Source: https://docs.applivery.com/es/device-management/android/app-management/chrome-managed-properties/ Description: Todo lo que puedes configurar en Google Chrome para Android a través de Applivery: despliegue, propiedades gestionadas, filtrado de URLs, modo quiosco y verificación en el dispositivo. TL;DR: Despliega Chrome en una política Android y configura sus propiedades gestionadas en el mismo sitio. Hay más de 150 propiedades disponibles, los valores de lista necesitan cadenas JSON serializadas, y chrome://policy confirma lo que ha llegado realmente al dispositivo. Answers: ¿Cómo se gestiona Chrome en Android con Applivery? · ¿Qué son las propiedades gestionadas de Chrome? · ¿Cómo bloqueo o permito sitios web en Chrome desde Applivery? · ¿Cómo configuro la página de inicio, el modo incógnito o el gestor de contraseñas? · ¿Cómo verifico que una configuración de Chrome se ha aplicado en el dispositivo? · ¿Se puede usar Chrome en modo quiosco? Key topics: Despliegue de Chrome, Categorías de propiedades gestionadas, Formato de los valores, Verificación con chrome://policy, Chrome en modo quiosco, Applivery, Google Chrome, Android, Android Enterprise, Managed Google Play, Chrome Enterprise Chrome suele ser el navegador que realmente usa tu flota Android, lo que lo convierte en una de las apps que más rendimiento te da configurar de forma centralizada. Applivery lo gestiona igual que cualquier otra app de Managed Google Play: la despliegas mediante una política y, dentro de esa misma política, configuras sus **propiedades gestionadas** (managed configuration), el mecanismo que usa Google para exponer las políticas de Chrome Enterprise en Android. Desde ahí controlas el filtrado de URLs, la privacidad, la seguridad y el comportamiento general del navegador, sin tocar el dispositivo. ### Cómo funciona la gestión de Chrome en Applivery Chrome no tiene una pantalla de configuración propia y separada dentro de Applivery. Se gestiona con el mismo mecanismo genérico que se usa para cualquier app de Managed Google Play que exponga configuración gestionada: - **Despliegue de la app.** Añades Chrome a una política como cualquier otra app de Google Play, normalmente como app forzada, ya que la mayoría de dispositivos Android Enterprise la traen de fábrica. - **Propiedades gestionadas.** Google define un esquema de configuración para Chrome (las políticas de Chrome Enterprise, en su variante para Android) y lo publica en Google Play. Applivery detecta ese esquema automáticamente y lo muestra como un formulario editable dentro de la política, sin que nadie en Applivery tenga que mantener una lista propia. - **Aplicación en el dispositivo.** El DPC de Applivery aplica los valores mediante `DevicePolicyManager.setApplicationRestrictions(...)`. Esto funciona igual en dispositivos Android Enterprise (AMAPI) y en dispositivos AOSP sin servicios de Google, siempre que la app declare su esquema de restricciones. :::info El listado de propiedades disponibles lo define Google y Chrome, no Applivery. Applivery únicamente detecta y expone ese esquema, y por eso el mismo mecanismo que sirve para Chrome sirve para cualquier otra app gestionada. Consulta [Propiedades gestionadas de apps](https://docs.applivery.com/es/device-management/android/app-management/managed-apps-properties/) para la versión genérica de este flujo. ::: ### Configuración **Abre la política** Entra en el [**panel de Applivery**](https://dashboard.applivery.io/) y abre la política donde quieres gestionar Chrome. **Añade la app** Ve a la sección **Apps** del menú lateral y pulsa **\+ Añadir App**. **Selecciona Google Chrome** Busca **Google Chrome** en el listado de Managed Google Play y selecciónala. Se abrirá un panel lateral con todas las propiedades gestionadas disponibles para esa versión de Chrome. ![chrome managed properties](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/737cb7e5-9081-40a6-bd47-5891cf258483.png) **Rellena las propiedades** Configura los campos que necesites. Las categorías de más abajo recorren todo lo disponible. **Guarda y despliega** Pulsa **Guardar cambios** y despliega la política al grupo de dispositivos correspondiente. Los cambios se aplican automáticamente, normalmente en pocos minutos. ### Categorías de propiedades gestionadas disponibles Chrome expone en Android una parte muy amplia de sus políticas de Chrome Enterprise, más de 150 propiedades distintas, aunque con un subconjunto más reducido que en escritorio. La excepción más importante: **Chrome para Android no soporta extensiones de navegador**, por lo que todas las políticas relacionadas con extensiones (`ExtensionInstallForcelist`, `ExtensionInstallAllowlist`, `ExtensionInstallBlocklist`, `ExtensionSettings`, `ExtensionInstallSources`, `ExtensionAllowedTypes`, `ExtensionDeveloperModeSettings`, `BlockExternalExtensions`, `EnterpriseHardwarePlatformAPIEnabled`) no aplican en Android y no aparecerán como configurables. A continuación se agrupan por función las propiedades más relevantes para un despliegue MDM. Es un resumen funcional de qué hace cada una, no una transcripción de la documentación de Google. #### 1\. Control de acceso web

Propiedad

Qué permite configurar

URLBlocklist

Patrones de URL bloqueados, hasta 1.000. ["*"] bloquea todo.

URLAllowlist

Excepciones a URLBlocklist. Tiene precedencia sobre el bloqueo.

IncognitoModeUrlBlocklist / IncognitoModeUrlAllowlist

Listas de bloqueo y excepción específicas del modo incógnito, independientes de las generales.

HttpAllowlist

Hosts exentos de la actualización forzada a HTTPS.

HSTSPolicyBypassList

Hosts que se saltan la precarga HSTS.

SafeBrowsingAllowlistDomains

Dominios excluidos de las comprobaciones de Safe Browsing.

LookalikeWarningAllowlistDomains

Dominios excluidos del aviso de "sitio parecido a otro conocido".

CertificateTransparencyEnforcementDisabledForUrls / ...ForCas

Excepciones a la obligatoriedad de Certificate Transparency.

AllHttpAuthSchemesAllowedForOrigins

Orígenes donde se permiten todos los esquemas de autenticación HTTP, ignorando AuthSchemes.

SSLErrorOverrideAllowed / SSLErrorOverrideAllowedForOrigins

Si el usuario puede continuar tras un aviso de error SSL, de forma global o para orígenes concretos.

:::warning Applivery tiene una página propia con la sintaxis exacta de estos filtros. Consulta [Filtros URL](https://docs.applivery.com/es/device-management/android/troubleshooting/url-filtering/) antes de escribir tus reglas. El formato es `[scheme://][.]host[:port][/path][@query]`. ::: #### 2\. Permisos y comportamiento del contenido web

Propiedad

Qué permite configurar

DefaultCookiesSetting, CookiesAllowedForUrls, CookiesBlockedForUrls, CookiesSessionOnlyForUrls, BlockThirdPartyCookies

Comportamiento de cookies por defecto, por sitio y de terceros.

DefaultGeolocationSetting, GeolocationBlockedForUrls, PreciseGeolocationAllowedForUrls

Acceso de los sitios a la ubicación del usuario.

DefaultNotificationsSetting, NotificationsAllowedForUrls, NotificationsBlockedForUrls

Notificaciones push de sitios web.

DefaultJavaScriptSetting, JavaScriptAllowedForUrls, JavaScriptBlockedForUrls

Ejecución de JavaScript, global o por sitio.

DefaultJavaScriptJitSetting y sus variantes por sitio

Compilación JIT del motor JS: rendimiento frente a superficie de ataque.

DefaultJavaScriptOptimizerSetting y sus variantes por sitio

Optimizaciones avanzadas del motor JS.

DefaultPopupsSetting, PopupsAllowedForUrls, PopupsBlockedForUrls

Ventanas emergentes.

DefaultSensorsSetting y sus variantes por sitio

Acceso a sensores de movimiento y luz.

DefaultSerialGuardSetting, SerialAllowAllPortsForUrls, SerialAskForUrls, SerialBlockedForUrls

Acceso a puertos serie mediante la Web Serial API.

DefaultWebBluetoothGuardSetting

Acceso a dispositivos Bluetooth cercanos.

DefaultWebUsbGuardSetting, WebUsbAllowDevicesForUrls, WebUsbAskForUrls, WebUsbBlockedForUrls

Acceso a dispositivos USB conectados.

DefaultIdleDetectionSetting y sus variantes por sitio

Detección de inactividad del usuario mediante la Idle Detection API.

DefaultClipboardSetting, ClipboardAllowedForUrls, ClipboardBlockedForUrls

Acceso de los sitios al portapapeles.

DefaultAutomaticDownloadsSetting y sus variantes por sitio

Descarga automática de múltiples archivos.

AutoplayAllowed, AutoplayAllowlist

Reproducción automática de contenido multimedia.

PaymentMethodQueryEnabled

Si los sitios pueden consultar si el usuario tiene métodos de pago guardados.

ScreenCaptureAllowed y las políticas *CaptureAllowedByOrigins

Permiso para compartir pantalla, ventana o pestaña desde una web.

WebXRImmersiveArEnabled

Sesiones de realidad aumentada vía WebXR.

LocalNetworkAccess*, LocalNetworkAllowedForUrls, LoopbackNetworkAllowedForUrls y sus equivalentes de bloqueo

Acceso de los sitios a la red local o al propio dispositivo (loopback). Vinculado a la restricción Local Network Access de Chrome.

#### 3\. Privacidad y datos de navegación

Propiedad

Qué permite configurar

IncognitoModeAvailability

Permite, desactiva o fuerza siempre el modo incógnito.

BrowsingDataLifetime

Retención máxima por tipo de dato (historial, contraseñas, autocompletado y otros), en horas.

SavingBrowserHistoryDisabled

Desactiva el guardado del historial de navegación.

SyncTypesListDisabled

Excluye tipos de datos concretos (marcadores, contraseñas, pestañas) de la sincronización.

HistoryClustersVisible

Muestra u oculta la vista de historial agrupado por temas.

NTPContentSuggestionsEnabled

Sugerencias de contenido en la pestaña nueva.

UrlKeyedAnonymizedDataCollectionEnabled

Envío de URLs anonimizadas a Google para mejorar búsquedas y navegación.

ReduceAcceptLanguageEnabled

Reduce la cabecera Accept-Language por privacidad.

DomainReliabilityAllowed

Envío de diagnósticos de fiabilidad de dominio.

MetricsReportingEnabled

Envío de informes anónimos de uso y fallos.

FeedbackSurveysEnabled

Encuestas de producto integradas en Chrome.

RestrictAccountsToPatterns

Qué cuentas de Google son visibles dentro de Chrome, por patrón de nombre.

#### 4\. Contraseñas, autocompletado y autenticación

Propiedad

Qué permite configurar

PasswordManagerEnabled

Si Chrome puede guardar contraseñas nuevas.

PasswordLeakDetectionEnabled

Comprueba si las credenciales introducidas han aparecido en una filtración.

PasswordSharingEnabled

Compartir contraseñas guardadas con miembros de un grupo familiar.

ThirdPartyPasswordManagersAllowed

Si se puede usar un gestor de contraseñas de terceros configurado en Android en lugar del de Chrome.

AutofillAddressEnabled / AutofillCreditCardEnabled

Autocompletado de direcciones y tarjetas de pago.

BrowserSignin

Si el usuario puede iniciar sesión en Chrome con su cuenta de Google. En Android no admite el modo forzado.

AndroidEntraSsoEnabled

Inicio de sesión automático en propiedades de Microsoft mediante el broker de autenticación de Entra ID.

AuthSchemes, AuthServerAllowlist, AuthNegotiateDelegateAllowlist, AuthAndroidNegotiateAccountType, DisableAuthNegotiateCnameLookup, NtlmV2Enabled, GloballyScopeHTTPAuthCacheEnabled

Autenticación integrada corporativa (Kerberos, NTLM, Negotiate) contra servidores internos.

AutoSelectCertificateForUrls

Selección automática de certificado cliente por patrón de sitio.

WebAuthenticationRemoteDesktopAllowedOrigins

Orígenes de apps de escritorio remoto autorizados a hacer peticiones WebAuthn.

AllowWebAuthnWithBrokenTlsCerts

Permite WebAuthn en sitios con certificados TLS con errores.

OverrideSecurityRestrictionsOnInsecureOrigin

Exime a orígenes concretos de las restricciones de contexto seguro, útil para apps internas sin TLS.

#### 5\. Seguridad y Safe Browsing

Propiedad

Qué permite configurar

SafeBrowsingProtectionLevel

Nivel de Navegación Segura: desactivada, estándar o mejorada.

SafeBrowsingExtendedReportingEnabled

Envío de datos adicionales a Google para mejorar la detección de amenazas.

SafeBrowsingProxiedRealTimeChecksAllowed

Comprobaciones en tiempo real vía proxy que no exponen la IP del usuario.

DisableSafeBrowsingProceedAnyway

Impide al usuario continuar tras un aviso de sitio malicioso.

AdsSettingForIntrusiveAdsSites

Bloquea anuncios en sitios marcados con publicidad intrusiva.

DownloadRestrictions

Nivel de restricción sobre las descargas consideradas peligrosas.

DisableScreenshots

Bloquea las capturas de pantalla realizadas mediante atajos o extensiones.

SafeSitesFilterBehavior

Filtro de contenido para adultos basado en la API de SafeSearch de Google.

ForceGoogleSafeSearch

Fuerza el SafeSearch de Google Search.

ForceYouTubeRestrict

Fuerza un nivel mínimo de modo restringido en YouTube.

CACertificates, CACertificatesWithConstraints, CADistrustedCertificates, CAHintCertificates, CAPlatformIntegrationEnabled

Gestión de certificados raíz de confianza: añadir, restringir o marcar como no confiables.

HttpsOnlyMode, HttpsUpgradesEnabled, EncryptedClientHelloEnabled

Forzado de HTTPS y cifrado del ClientHello TLS (ECH).

PreferSlowCiphers, PreferSlowKexAlgorithms

Preferencia por algoritmos criptográficos de cumplimiento normativo, por ejemplo CNSA.

SitePerProcessAndroid

Aísla cada sitio en su propio proceso (Site Isolation) en dispositivos con más de 1 GB de RAM.

#### 6\. Funciones de IA generativa integradas Chrome incorpora varias funciones de IA (Gemini, AI Mode, autocompletado inteligente) que también puedes controlar por managed configuration:

Propiedad

Qué permite configurar

AIModeSettings

Disponibilidad del modo IA de Google en la barra de direcciones y la pestaña nueva.

GeminiSettings

Disponibilidad general de la integración de Gemini en Chrome.

GeminiActOnWebSettings, GeminiActOnWebAllowedForURLs, GeminiActOnWebBlockedForURLs

Si Gemini puede actuar directamente sobre páginas web en nombre del usuario, con restricción opcional por URL.

FindAndFillWithGeminiSettings

La función "Buscar y rellenar con Gemini".

FindsSettings

Chrome Finds, búsqueda asistida por IA sobre el contenido de la página.

AutofillPredictionSettings

Autocompletado de formularios asistido por IA generativa.

SearchContentSharingSettings

Si se puede compartir contenido de la página con AI Mode o Lens desde el panel lateral.

ThirdPartyAiChatSettings

Integraciones de IA de terceros en la barra de direcciones, cuando el buscador predeterminado no es Google.

GenAILocalFoundationalModelSettings

Descarga y uso del modelo de IA local para inferencia en el dispositivo.

:::info Todas estas políticas de IA responden a `GenAiDefaultSettings` cuando se dejan sin definir. Si tu organización tiene una postura general sobre IA generativa, fija primero ese valor por defecto y después afina cada función. ::: #### 7\. Navegación, marcadores y buscador

Propiedad

Qué permite configurar

HomepageLocation

URL de la página de inicio.

HomepageIsNewTabPage

Usa la pestaña nueva como página de inicio.

ShowHomeButton

Muestra el botón de inicio en la barra de herramientas.

BookmarkBarEnabled / EditBookmarksEnabled

Visibilidad de la barra de marcadores y si el usuario puede editarlos.

ManagedBookmarks

Despliega una carpeta de marcadores predefinidos, con subcarpetas, que el usuario no puede modificar.

La familia DefaultSearchProvider* (Enabled, Name, SearchURL, SuggestURL, ImageURL, Encodings, AlternateURLs y sus variantes *PostParams)

Configura o fuerza tu propio buscador predeterminado en lugar de dejarlo a elección del usuario.

SearchSuggestEnabled

Sugerencias de búsqueda en la barra de direcciones.

ContextualSearchEnabled

La función Touch to Search.

TranslateEnabled

Traducción integrada de páginas.

PrintingEnabled

Si se permite imprimir desde Chrome.

QRCodeGeneratorEnabled

El generador de códigos QR integrado.

ShoppingListEnabled

Seguimiento de precios de productos vistos en el navegador.

EnableMediaRouter

Disponibilidad de Google Cast.

ListenToThisPageEnabled

Lectura en voz alta de páginas web.

SharedClipboardEnabled

Envío de texto entre Chrome de escritorio y un dispositivo Android vinculado por cuenta.

#### 8\. Sesión, cuenta y gestión en la nube

Propiedad

Qué permite configurar

TosDialogBehavior

Omite el diálogo de Términos de Servicio en el primer uso. Solo aplica a Chrome Custom Tabs (CCT) en dispositivos totalmente gestionados.

CloudManagementEnrollmentToken

Token para que Chrome se registre en Chrome Enterprise Core, la gestión en la nube de Google, en paralelo a la gestión vía Applivery y AMAPI.

CloudPolicyOverridesPlatformPolicy, CloudUserPolicyMerge, CloudUserPolicyOverridesCloudMachinePolicy

Reglas de precedencia entre políticas cloud (Chrome Enterprise Core) y políticas de plataforma, las que llegan vía Applivery.

PolicyAtomicGroupsEnabled, PolicyDictionaryMultipleSourceMergeList, PolicyListMultipleSourceMergeList

Reglas de fusión cuando la misma política llega desde más de una fuente de gestión.

:::info Este bloque solo es relevante si, además de Applivery, tu organización gestiona Chrome desde la consola de administración de Google (Chrome Enterprise Core). Si Applivery es la única fuente de gestión, normalmente no hace falta tocar estas propiedades. ::: #### 9\. Red, proxy y rendimiento Chrome también expone un bloque amplio de políticas de infraestructura: DNS (`DnsOverHttpsMode`, `DnsOverHttpsTemplates`, `BuiltInDnsClientEnabled`), proxy (`ProxySettings`, límites de conexiones por proxy), WebRTC (`WebRtcEventLogCollectionAllowed`, `WebRtcUdpPortRange`) y actualizaciones de componentes (`ComponentUpdatesEnabled`). Son relevantes sobre todo en entornos con proxy corporativo obligatorio o políticas de red restrictivas. No se detallan aquí fila a fila por ser de uso poco frecuente en un despliegue MDM estándar, pero siguen exactamente el mismo mecanismo de propiedades gestionadas que el resto. #### Políticas internas del motor de renderizado Chrome publica además un número considerable de políticas internas del motor de renderizado (banderas de compatibilidad web temporales, comportamiento de back/forward cache, Service Workers, CORS) pensadas para migraciones de la plataforma web más que para administración MDM. No se listan aquí por tener poca relevancia práctica para un admin de IT. Si en algún momento necesitas una de ellas, se configura exactamente igual que el resto: la buscas por nombre en el formulario de propiedades gestionadas de Chrome dentro de la política de Applivery. :::info El formulario que verás realmente en Applivery para la app Chrome se genera dinámicamente a partir del esquema que declara Google en Play, por lo que puede variar ligeramente según la versión de Chrome publicada. Antes de dar por buena la disponibilidad de un campo muy concreto, compruébalo directamente en el panel al seleccionar la app. ::: ### Formato de los valores: cuidado con listas y booleanos Al rellenar propiedades gestionadas para Chrome, ten en cuenta dos cosas: - Los valores de tipo **lista**, como `URLBlocklist` o `URLAllowlist`, deben introducirse como una **cadena JSON serializada**, no como un array nativo. Por ejemplo, `["facebook.com"]` como texto, no como una lista de campos separados. Está verificado empíricamente para Chrome en Android mediante `chrome://policy`, con `Status: OK`. - Los valores **booleanos**, como `SavingBrowserHistoryDisabled`, y los de **tipo entero o enum**, como `IncognitoModeAvailability` o `SafeBrowsingProtectionLevel`, se envían como el valor numérico o `true`/`false` que define el esquema de Chrome, no como texto libre. :::warning Si un campo de tipo lista no se aplica, o el dispositivo parece ignorarlo, revisa primero el formato (cadena JSON serializada) antes de asumir que la propiedad no está soportada. ::: ### Verifica la configuración con chrome://policy Una vez desplegada la política, la forma más fiable de confirmar que Chrome ha recibido la configuración es en el propio dispositivo: **Abre Chrome** Abre Chrome en el dispositivo gestionado. **Ve a chrome://policy** Navega a `chrome://policy`. **Busca tu propiedad** Localiza la propiedad que has configurado, por ejemplo `URLBlocklist`. **Comprueba el estado** Confirma que **Status** aparece como **OK**. Un error de parseo o "Ignored" significa que el valor no se ha podido aplicar, normalmente por un problema de formato o porque la propiedad no está soportada en esa versión de Chrome. **Muestra el valor** Pulsa **Show value** para confirmar que el contenido aplicado coincide con lo que configuraste en Applivery. :::info `chrome://policy` es la fuente de verdad del propio Chrome, independiente de Applivery. Si el estado allí es correcto, la configuración ha llegado bien al dispositivo. ::: ### Chrome en modo quiosco Chrome también puede actuar como navegador de una **app web en modo quiosco de Applivery**. Añade Chrome desde la pestaña de Google Play con el tipo de instalación **Forzar instalación** y asócialo como navegador de la app web dentro de la política. Esto te permite mostrar una URL concreta a pantalla completa, como app única del dispositivo. Consulta [Apps web](https://docs.applivery.com/es/device-management/android/app-management/web-apps/) y [Modo quiosco](https://docs.applivery.com/es/device-management/android/policies/kiosk-mode/) para el resto de opciones, incluidos el launcher básico, el launcher avanzado y el soporte AOSP. ### Resolución de problemas

Síntoma

Causa probable

El campo de lista no bloquea nada

El valor no está serializado como cadena JSON.

chrome://policy muestra un error de parseo

Formato de valor incorrecto para el tipo de campo: lista frente a booleano frente a entero.

Una propiedad esperada no aparece en el formulario de Applivery

Puede no estar disponible en la versión de Chrome publicada en Play para ese dispositivo, o requerir una versión mínima de Android. Compruébalo en el panel antes de asumir que falta soporte.

Los cambios no llegan al dispositivo

Revisa que la política se haya desplegado al grupo correcto de dispositivos, no solo guardado.

--- ## Conectar Google Play Console Source: https://docs.applivery.com/es/device-management/android/app-management/connect-google-play-console/ Description: Integra tu cuenta de Google Play Console con Applivery MDM para una gestión avanzada de apps privadas. Controla el despliegue y la distribución de apps. TL;DR: Conecta Google Play Console con Applivery MDM para un control avanzado de la gestión y el despliegue de apps privadas. Answers: ¿Cómo conectar Google Play Console con Applivery MDM? · ¿Cómo gestionar apps privadas con Applivery MDM? · ¿Qué es Managed Google Play? · ¿Cómo desplegar apps privadas usando Google Play Console y Applivery? · ¿Cómo encontrar el ID de organización de Applivery? · ¿Cuánto tiempo tarda Google en hacer visibles las apps privadas? · ¿Se puede usar Google Play Console en dispositivos AOSP con Applivery MDM? Key topics: Integración de Google Play Console, Configuración de Applivery MDM, Gestión de apps privadas, Managed Google Play, Google Play Console, Applivery MDM, Google, Android :::warning Conectar una cuenta de Google Play Console requiere Google Mobile Services y **no está disponible en dispositivos AOSP**. En AOSP, la distribución de apps privadas se gestiona a través del [Self-Service de Applivery](https://docs.applivery.com/es/device-management/android/policies/agent/#portal-self-service) — no se necesita una cuenta de Google Play. Consulta [Gestión de Android AOSP](https://docs.applivery.com/es/device-management/android/aosp/) para más detalles. ::: Applivery MDM se basa en Managed Google Play de Google para la gestión y distribución de apps. El Managed Google Play estándar será suficiente para tu caso de uso si deseas utilizar apps públicas de Google ya disponibles en Google Play. También te permitirá desplegar y gestionar apps privadas de una manera muy sencilla, aunque limitada. Sin embargo, si necesitas gestionar apps privadas de una manera muy avanzada, a veces preferirás utilizar tu propia cuenta de Google Play Console para gestionar tus apps. Este podría ser el caso si deseas: - Tener control total sobre la cuenta de Google Play Console. - Conectar tus propios pipelines de CI/CD para automatizar el despliegue de apps privadas. - Compartir tus apps privadas con otras organizaciones. **Inicia sesión en Google Play Console** Ve a la [Google Play Console](https://play.google.com/console) e inicia sesión con tus credenciales. Una vez que hayas iniciado sesión, selecciona una de tus cuentas de desarrollador. ![developer-account | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/02d8387b-824b-445b-bab8-feecf8e90c64.png) **Configura los ajustes de la app** Una vez dentro de Google Play Console, selecciona una de tus apps y dirígete a **Configuración > Ajustes avanzados > Managed Google Play**. En la sección Organizaciones, verás la lista de organizaciones que tienen acceso a esa app. ![managed-google-play | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ecdad579-5a63-4f50-bbe5-b2dba80213fd.png) **Añade la organización de Applivery** Haz clic en el botón **Añadir organización** para añadir tu organización de Applivery MDM. El formulario solicitará tu nombre y el ID de organización de Applivery. Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), navega a la sección **Configuración** y, desde el menú lateral izquierdo, selecciona **Configuración Android**. En la parte superior, encontrarás el ID de Enterprise de Applivery. ![enterprise id](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/8f73b2cb-7461-49bb-8e7f-845bd3d8cb25.png) **Guarda los cambios** Haz clic en **Añadir** y luego en **Guardar cambios**. Ahora tu app privada será visible en el Managed Google Play de Applivery MDM, y podrás seleccionarla como cualquier otra aplicación desde la sección **Apps** de tus políticas. Simplemente haz clic en el botón **\+ Añadir App** y busca el nombre de la app o el nombre del paquete. :::info Google podría tardar **hasta 72 horas** en hacer visibles tus apps privadas en las nuevas organizaciones. Recomendamos planificar esta configuración para cualquier despliegue crítico. ::: --- ## Personalizar Managed Google Play Source: https://docs.applivery.com/es/device-management/android/app-management/customize-managed-google-play-layout/ Description: Personaliza el diseño de Managed Google Play con colecciones de apps para simplificar el acceso en tus dispositivos Android. TL;DR: Applivery permite personalizar el diseño de Managed Google Play organizando apps en colecciones para una mejor experiencia de usuario en Android. Answers: ¿Se puede personalizar Managed Google Play en dispositivos AOSP? · ¿Cuál es la ventaja de personalizar el diseño de Managed Google Play? · ¿Cómo empiezo a personalizar Managed Google Play en Applivery? · ¿Cómo creo una nueva colección de apps en Managed Google Play? · ¿Qué ven los empleados tras guardar las colecciones de Managed Google Play? Key topics: Personalización de Managed Google Play, Organización de apps en colecciones, Gestión de apps Android con Applivery, Mejora de la productividad en MDM, Applivery, Managed Google Play, Android Enterprise, Google Mobile Services, AOSP, MDM :::warning La personalización del diseño de Managed Google Play requiere Google Mobile Services y **no está disponible en dispositivos AOSP**. Los dispositivos AOSP no tienen acceso a Google Play; las apps se distribuyen a través del [Applivery Self-Service](https://docs.applivery.com/es/device-management/android/policies/agent/#portal-self-service) en su lugar. ::: Personalizar el diseño de Managed Google Play permite a las organizaciones crear una tienda de apps estructurada y fácil de usar para su flota Android. Los administradores de TI pueden organizar las apps aprobadas en colecciones, páginas y grupos, asegurando que los empleados encuentren e instalen rápidamente las herramientas relevantes. Este enfoque personalizado aumenta la productividad y la claridad, permitiendo a las empresas presentar las apps de trabajo por categoría y simplificar la navegación, proporcionando una experiencia intuitiva y de marca para los usuarios finales en todos los dispositivos gestionados. ### Configuración de Play Store Una vez en el [**panel de Applivery**](https://dashboard.applivery.io), dirígete a cualquiera de tus políticas 1. Desde el menú lateral izquierdo, dirígete a **Apps** 2 y haz clic en el botón **\+ Añadir App** 3. ![add app](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ab8de9c1-6b8b-42a8-83d9-706ee93132d5.png) Esto abrirá tu **iFrame de Managed Google Play**. Una vez cargado, haz clic en **Organizar apps** 4 para empezar a organizar el diseño de tus apps, luego selecciona **Crear una colección** 5. ![organize Apps](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/0fe43eb7-5630-4804-9efd-f49fabc36b0f.png) Introduce el nombre que desees para la colección y haz clic en **Siguiente**. Luego, selecciona las apps que te gustaría incluir y haz clic en **Añadir apps** 6. Tu colección aparecerá ahora en la lista de colecciones creadas. Finalmente, haz clic en **Guardar**. ![create collection](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/f48655b6-a215-4b81-9796-053576abe0e6.png) Una vez guardada la política, los empleados que accedan a Managed Google Play desde sus dispositivos verán una sección dedicada de **Apps de trabajo**. Allí, encontrarán las colecciones que tú hayas creado y podrán descargar directamente las apps incluidas en cada una. ![device play store](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/b2fdc7a2-1bdb-47ce-9432-56f378498b93.png) Las colecciones en Managed Google Play permiten a las organizaciones centralizar y simplificar el acceso a las apps relacionadas con el trabajo. Esta característica ayuda a los administradores a asegurar que los empleados puedan encontrar fácilmente las herramientas que necesitan, aumentando la productividad y minimizando los riesgos de seguridad. Con solo unos pocos pasos, puedes crear un espacio de trabajo más organizado, seguro y eficiente. :::tip Revisa y actualiza regularmente tus colecciones de Managed Google Play para asegurar que los empleados tengan acceso a las apps más relevantes y actualizadas. ::: --- ## Aplicaciones predeterminadas Source: https://docs.applivery.com/es/device-management/android/app-management/default-applications/ Description: Fija el navegador, el marcador, la app de SMS, la cartera o el launcher predeterminados en dispositivos Android gestionados desde tu política de Applivery, y evita que el usuario los cambie. TL;DR: Fija el navegador, el marcador, la app de SMS, el asistente, la cartera o el launcher predeterminados desde tu política de Android en Applivery, usando una lista priorizada de apps candidatas. Answers: ¿Cómo fijo el navegador predeterminado en dispositivos Android gestionados? · ¿Cómo fuerzo un marcador predeterminado con Android MDM? · ¿Qué es defaultApplicationSettings en la Android Management API? · ¿Puedo impedir que el usuario cambie la app predeterminada en Android? · ¿Qué versiones de Android admiten las aplicaciones predeterminadas? · ¿Por qué no se aplica mi aplicación predeterminada? Key topics: Aplicaciones predeterminadas, Políticas de Android Enterprise, Tipos de aplicación y ámbitos, Informes de estado y no conformidad, Applivery, Android, Android Enterprise, Android Management API (AMAPI), Google, Google Play Store Android deja que sea el usuario quien elija qué app gestiona los roles clave del sistema: qué navegador abre un enlace, qué app hace una llamada, cuál recibe los SMS. En una flota corporativa esa elección no suele ser algo que quieras dejar abierto. Si la mitad de tus dispositivos abre los enlaces corporativos en un navegador que no gestionas, o un técnico atiende llamadas de trabajo desde un marcador personal, pierdes consistencia y control. Las **aplicaciones predeterminadas** te permiten decidir esos roles de forma centralizada. Defines qué app debe encargarse de cada rol del sistema, Applivery lo envía a través del campo `defaultApplicationSettings` de la política de la Android Management API (AMAPI), y el usuario ya no puede cambiarlo mientras la configuración siga activa. Usos habituales: - Forzar un navegador corporativo, por ejemplo Chrome, como navegador predeterminado. - Fijar el marcador o la app de SMS corporativa en dispositivos de empresa. - Establecer el asistente de voz o la cartera digital predeterminados en una flota gestionada. - Fijar el launcher (pantalla de inicio) en dispositivos totalmente gestionados. :::warning No lo confundas con **Persistent Preferred Activities**. AMAPI dispone de otro mecanismo más antiguo, `persistentPreferredActivities`, que también fija un manejador de intents por defecto, por ejemplo para el modo quiosco. Google indica expresamente que `defaultApplicationSettings` y `persistentPreferredActivities` **no** deben configurarse para el mismo dominio de intent, como la navegación web, porque el resultado es impredecible. ::: ### Cómo funciona Cada app predeterminada que fijas es una entrada del array `defaultApplicationSettings` de la política, y cada entrada se compone de tres elementos:

Elemento

Qué hace

Tipo (defaultApplicationType)

El rol del sistema que quieres fijar: navegador, marcador, SMS, etc. Consulta la tabla siguiente para ver todos los tipos soportados.

Aplicaciones (defaultApplications)

Una lista priorizada de apps candidatas, por packageName. AMAPI elige la primera de la lista que esté instalada en el dispositivo y sea válida para ese rol.

Ámbitos (defaultApplicationScopes)

Dónde se aplica la configuración: Fully Managed, perfil de trabajo, perfil personal o una combinación.

La lista priorizada es lo que hace esto práctico en flotas con hardware mixto. Pon tu app preferida en primer lugar y una alternativa en segundo, y cada dispositivo se resolverá con la que realmente tenga. Para que una app que no sea del sistema pueda establecerse como predeterminada, la huella (fingerprint) de su certificado de firma en el dispositivo debe coincidir con la obtenida de Google Play Store, o con una de las entradas declaradas en `signingKeyCerts` para esa app en la política. ### Tipos de aplicación predeterminada soportados

Tipo

Descripción y requisitos

DEFAULT_ASSISTANT

App de asistente de voz. Solo válido para SCOPE_FULLY_MANAGED. Requiere Android 16+ en dispositivos totalmente gestionados.

DEFAULT_BROWSER

Navegador predeterminado. Requiere Android 16+.

DEFAULT_CALL_REDIRECTION

App de redirección de llamadas. No aplicable a SCOPE_PERSONAL_PROFILE. Requiere Android 16+.

DEFAULT_CALL_SCREENING

App de filtrado de llamadas. No aplicable a SCOPE_PERSONAL_PROFILE. Requiere Android 16+.

DEFAULT_DIALER

Marcador telefónico. Soportado en dispositivos totalmente gestionados desde Android 14/15, y en todos los modos de gestión desde Android 16.

DEFAULT_HOME

Launcher o pantalla de inicio. Solo válido para SCOPE_FULLY_MANAGED. Requiere Android 16+.

DEFAULT_SMS

App de SMS. No aplicable a SCOPE_WORK_PROFILE. Soportado en dispositivos de empresa desde Android 16.

DEFAULT_WALLET

App de cartera digital. Rol cross-profile. Soportado en dispositivos de empresa desde Android 16.

:::info Algunos roles, como `DEFAULT_WALLET`, se aplican de forma transversal entre perfiles. En un dispositivo de empresa con perfil de trabajo puedes fijar la app predeterminada en el perfil de trabajo o en el personal, pero no en ambos a la vez. ::: ### Ámbitos de aplicación - `SCOPE_FULLY_MANAGED`: se aplica a dispositivos totalmente gestionados (Device Owner). - `SCOPE_WORK_PROFILE`: se aplica al perfil de trabajo, tanto en dispositivos de empresa con perfil de trabajo (COPE) como en dispositivos personales con perfil de trabajo (BYOD). - `SCOPE_PERSONAL_PROFILE`: se aplica al perfil personal en dispositivos de empresa con perfil de trabajo. Cuando fijas una app predeterminada para `SCOPE_FULLY_MANAGED` o `SCOPE_WORK_PROFILE`, esa app necesita una entrada correspondiente en la sección **Aplicaciones** de la política, con un `installType` distinto de `BLOCKED`. Cuando el ámbito objetivo es `SCOPE_PERSONAL_PROFILE`, solo puedes establecer como predeterminadas apps de sistema preinstaladas. ### Compatibilidad por modo de gestión y versión de Android

Modo de gestión

Android 14 – 15

Android 16+

Fully Managed

Solo DEFAULT_DIALER

Todos los tipos soportados

De empresa con perfil de trabajo (COPE)

No soportado

Perfil de trabajo: BROWSER, CALL_REDIRECTION, CALL_SCREENING, DIALER, WALLET.
Perfil personal: BROWSER, DIALER, SMS, WALLET.

Propiedad personal con perfil de trabajo (BYOD)

No soportado

Perfil de trabajo: BROWSER, CALL_REDIRECTION, CALL_SCREENING, DIALER.
Perfil personal: no soportado.

### Antes de empezar - Un dispositivo con Android 14 o superior. Se recomienda Android 16+, ya que desbloquea todos los tipos de app predeterminada. - Un modo de gestión de Android Enterprise compatible (Fully Managed, COPE o BYOD con perfil de trabajo), según el tipo de app predeterminada que quieras fijar. - Las apps candidatas añadidas a la sección **Aplicaciones** de la política con un `installType` distinto de `BLOCKED`, salvo las apps de sistema preinstaladas del perfil personal. - El `packageName` exacto de cada app candidata. - La confirmación de que esa misma política no tiene ninguna entrada de `persistentPreferredActivities` para el mismo dominio de intent, para evitar conflictos. ### Configuración **Ve a Políticas** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a **Políticas** 1 y selecciona la política Android que quieres modificar. **Añade las apps candidatas** En la sección **Apps** 2 de la política, añade todas las apps que vayas a usar como predeterminadas (navegador, marcador, etc.) con un `installType` distinto de `BLOCKED`, por ejemplo `AVAILABLE` o `FORCE_INSTALLED`. ![android apps](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/06e7e486-ca35-4452-a128-8c7c9c414ee0.png) **Accede a Todas las propiedades** En el menú lateral izquierdo, haz clic en la sección **Todas las propiedades** 3. **Localiza Default Application Settings** En el campo de búsqueda, escribe `defaultApplicationSettings` para localizar el objeto de configuración **Default Application Settings**. **Define la app predeterminada** Configura los tres valores de esta entrada: - **Scope**: Fully Managed, Work Profile o Personal Profile. - **Type**: Assistant, Browser, Call Redirection, Call Screening, Dialer, Home, SMS o Wallet. - **Package Name**: el package name de la aplicación que quieres como predeterminada para el tipo que acabas de seleccionar. ![default app settings](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/e097a0c8-25e8-432f-9947-3ff4529989d1.png) Repite el proceso para cada rol que quieras fijar. **Activa el informe de estado (opcional)** Si quieres recibir información sobre qué predeterminadas se han aplicado realmente, activa `defaultApplicationInfoReportingEnabled` dentro de `statusReportingSettings`. **Guarda y sincroniza** Guarda la política y sincronízala con tus dispositivos, ya sea automáticamente en el siguiente check-in o forzando la sincronización manual desde la ficha del dispositivo. ### Ejemplo de política Esta política fija Chrome como navegador predeterminado y define una lista priorizada de marcadores, con el informe de estado activado: ```json { "applications": [ { "packageName": "com.android.chrome", "installType": "AVAILABLE" }, { "packageName": "com.google.android.dialer", "installType": "AVAILABLE" }, { "packageName": "com.samsung.android.dialer", "installType": "AVAILABLE" } ], "statusReportingSettings": { "defaultApplicationInfoReportingEnabled": true }, "defaultApplicationSettings": [ { "defaultApplicationType": "DEFAULT_BROWSER", "defaultApplications": [ { "packageName": "com.android.chrome" } ], "defaultApplicationScopes": [ "SCOPE_FULLY_MANAGED", "SCOPE_WORK_PROFILE" ] }, { "defaultApplicationType": "DEFAULT_DIALER", "defaultApplications": [ { "packageName": "com.google.android.dialer" }, { "packageName": "com.samsung.android.dialer" } ], "defaultApplicationScopes": [ "SCOPE_FULLY_MANAGED", "SCOPE_WORK_PROFILE", "SCOPE_PERSONAL_PROFILE" ] } ] } ``` En este ejemplo, AMAPI intentará establecer `com.google.android.dialer` como marcador predeterminado. Si esa app no está instalada en el dispositivo, probará con `com.samsung.android.dialer`, siguiendo el orden de prioridad de la lista `defaultApplications`. ### Informe de estado A partir de Android 16, los informes de estado del dispositivo incluyen el campo `defaultApplicationInfo` siempre que `defaultApplicationInfoReportingEnabled` esté activado en `statusReportingSettings`. Para cada tipo de aplicación, el informe te indica: - `packageName`: la app actualmente predeterminada para ese tipo, tanto si la fijó la política como si la estableció el sistema o la eligió el usuario. - `defaultApplicationSettingAttempts`: el resultado de cada intento de aplicar las apps de tu lista priorizada. Es lo que tienes que mirar cuando una app de mayor prioridad no llegó a establecerse y necesitas saber por qué. En dispositivos totalmente gestionados el informe cubre todos los tipos de aplicación. En dispositivos con perfil de trabajo cubre solo los tipos soportados para ese perfil. ### Motivos de no conformidad

Motivo

Qué significa

API_LEVEL

La función no está soportada en la versión de Android del dispositivo.

MANAGEMENT_MODE

La función no está soportada para el modo de gestión del dispositivo, o ninguno de los ámbitos indicados en la política es aplicable a dicho modo (razón específica DEFAULT_APPLICATION_SETTING_UNSUPPORTED_SCOPES).

APP_NOT_INSTALLED

Ninguna de las apps de la lista priorizada está instalada en el dispositivo.

INVALID_VALUE

Al menos una app está instalada, pero la configuración no puede aplicarse por otro motivo; por ejemplo, la app no es válida para ese rol. En el perfil personal se reporta un INVALID_VALUE genérico, sin revelar el estado de instalación de las apps personales.

### Consideraciones importantes - Nunca configures `defaultApplicationSettings` y `persistentPreferredActivities` para el mismo dominio de intent, como la navegación web, en la misma política. El comportamiento se vuelve impredecible. - Cada app candidata debe existir en la sección **Aplicaciones** de la política con un `installType` distinto de `BLOCKED`, salvo las apps de sistema del perfil personal. - Para apps que no sean del sistema, el certificado de firma en el dispositivo debe coincidir con el de Google Play Store o con una entrada declarada en `signingKeyCerts`. - La compatibilidad real depende de la versión de Android y del modo de gestión de cada dispositivo. Revisa la tabla de compatibilidad antes de desplegar nada. - Para roles cross-profile como `DEFAULT_WALLET`, no puedes fijar la predeterminada en el perfil de trabajo y en el personal al mismo tiempo. - Una vez aplicada la política, el usuario no puede cambiar manualmente la app predeterminada de ese rol mientras la configuración siga activa. ### Verificación y solución de problemas **Sincroniza el dispositivo** Después de guardar la política, sincroniza el dispositivo manualmente desde su ficha en Applivery, o espera al siguiente check-in. **Revisa el informe de estado** Si has activado `defaultApplicationInfoReportingEnabled`, revisa el informe de estado del dispositivo para confirmar qué app quedó fijada como predeterminada para cada tipo. **Pruébalo en el dispositivo** Lanza la acción correspondiente en el dispositivo (abrir un enlace, iniciar una llamada) y comprueba que se ejecuta directamente con la app configurada, sin que aparezca el selector de apps. **Consulta los detalles de no conformidad** Si el comportamiento no es el esperado, revisa los detalles de no conformidad del dispositivo (`API_LEVEL`, `MANAGEMENT_MODE`, `APP_NOT_INSTALLED`, `INVALID_VALUE`) para identificar la causa. **Vuelve a comprobar la app** Confirma que la app candidata está realmente instalada y que su `installType` en la política no es `BLOCKED`. Las aplicaciones predeterminadas convierten una preferencia del usuario en un ajuste gestionado. Combinadas con una lista priorizada de candidatas, te dan un comportamiento predecible en una flota que mezcla hardware, versiones de Android y modos de gestión, y eliminan las dudas sobre qué app se encarga de los roles de los que realmente depende tu organización. --- ## Instalación forzosa de apps Source: https://docs.applivery.com/es/device-management/android/app-management/forced-install-apps/ Description: Instala apps Android de forma automática en dispositivos gestionados con Managed Google Play o Applivery Self-Service para toda tu organización. TL;DR: Instala y gestiona apps automáticamente en dispositivos Android con Applivery y Managed Google Play para una gestión de dispositivos móviles optimizada. Answers: ¿Qué es la instalación automática de apps con Applivery? · ¿Cómo habilita Applivery la instalación automática de apps en dispositivos Android? · ¿Qué tipos de apps puedo instalar automáticamente con Applivery y Managed Google Play? · ¿Cuáles son los tipos de instalación de apps disponibles en Applivery para dispositivos Android? · ¿Cuáles son los requisitos previos para configurar la instalación automática de apps con Applivery? · ¿Funciona la instalación automática de apps de Applivery a través de Managed Google Play en dispositivos AOSP? · ¿Cómo se instalan apps de forma forzada en dispositivos AOSP usando Applivery? Key topics: Managed Google Play, Instalación automática de apps, Android Enterprise, MDM de Applivery, Políticas de gestión de apps, Android, Google Play Store, Applivery La **instalación automática de apps** permite a los administradores de TI desplegar aplicaciones de forma remota en dispositivos Android gestionados sin requerir interacción del usuario. Con Applivery, las aplicaciones pueden instalarse de forma silenciosa y eficiente en flotas de cualquier tamaño, ideal para asegurar que todos los empleados dispongan de las herramientas críticas que necesitan para el trabajo, el cumplimiento de seguridad o entornos en modo quiosco. Las apps se asignan dentro de las políticas y se envían directamente desde el panel de Applivery, simplificando el despliegue y reduciendo las necesidades de soporte. Los administradores obtienen control total sobre qué apps se instalan, actualizan o eliminan, y pueden automatizar los despliegues para nuevos dispositivos, cambios de rol o actualizaciones, garantizando configuraciones consistentes en toda la organización. Applivery soporta tanto apps [de sistema](https://docs.applivery.com/es/device-management/android/app-management/system-apps/) como [de terceros](https://docs.applivery.com/es/device-management/android/app-management/private-app-managed-google-play/), con funciones avanzadas para configurar [propiedades gestionadas](https://docs.applivery.com/es/device-management/android/app-management/managed-apps-properties/), automatizar actualizaciones y hacer cumplir la conformidad de las apps, haciendo que la gestión de dispositivos sea sencilla y robusta para entornos empresariales. ### Managed Google Play El secreto detrás de la instalación automática de apps en Android Enterprise —y, por supuesto, con Applivery— es **Managed Google Play**. Piensa en ello como una versión especial de Google Play Store, diseñada específicamente para tu organización. Con Managed Google Play, **tú controlas** qué apps están disponibles para tus empleados y cómo se instalan. Applivery se conecta directamente a tu cuenta de Managed Google Play, permitiéndote gestionar y distribuir apps **de forma centralizada y automática** —¡no se necesitan instalaciones manuales! ### Cómo configurar la instalación automática de apps **Asegúrate de que tus dispositivos estén inscritos** Para asegurar que todo funcione sin problemas, tus dispositivos Android ya deben estar registrados y gestionados bajo Android Enterprise en Applivery. Esto significa que tu [cuenta de Android Enterprise está configurada correctamente](https://docs.applivery.com/es/device-management/android/get-started/) y tus dispositivos están inscritos, ya sean dispositivos propiedad de la empresa, Perfiles de trabajo o de otro tipo. **Añade y aprueba tus apps en Managed Google Play** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io), dirígete a cualquiera de tus políticas 1. Desde el menú lateral izquierdo, selecciona **Apps** 2 y haz clic en el botón **\+ Añadir App** 3. ![add app](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/9b2dbdc5-97ff-4784-8761-3631da886f4f.png) Se abrirá el **iFrame de Managed Google Play**, permitiéndote seleccionar entre los siguientes tipos de apps: - **Apps públicas** 4: Si las apps están disponibles en Google Play Store, simplemente búscalos y apruébalos directamente desde la sección de Managed Google Play en tu panel de Applivery. Una vez aprobadas, puedes gestionarlas y asignarlas a tus dispositivos. - **Apps privadas** 5: Para apps desarrolladas internamente para tu empresa, puedes subirlas como [**apps privadas**](https://docs.applivery.com/es/device-management/android/app-management/private-app-managed-google-play/) a Managed Google Play directamente desde Applivery. Solo tu organización tendrá acceso a estas apps. - **Web Apps** 6: También puedes convertir tus sitios web favoritos en [**Web Apps**](https://docs.applivery.com/es/device-management/android/app-management/web-apps/) dentro de Managed Google Play, y luego desplegarlas automáticamente en los dispositivos como si fueran apps nativas. ![managed google play](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/c6b3442b-ea74-43cb-a699-2eb8165ee18d.png) **Asignación y tipo de instalación** El tipo de instalación decide si la app llega sola al dispositivo, si el usuario puede quitársela de encima y si la configuración inicial espera por ella. Son tipos de instalación de Android Enterprise, así que el comportamiento de abajo es de Android, no de Applivery.

Tipo de instalación

Se instala sola

Comportamiento

Forzar instalación

Sí

Se instala al margen de cualquier ventana de mantenimiento y el usuario no puede eliminarla.

Preinstalada

Sí

Se instala automáticamente, pero el usuario sí puede eliminarla después.

Disponible

No

Se ofrece en Managed Google Play para que la instale el usuario. Es el valor por defecto cuando no se define tipo de instalación.

Bloqueada

No

No puede instalarse, ni aunque el usuario la busque en Managed Google Play. Si estaba instalada por una política anterior, se desinstala, y también se bloquea su funcionalidad de instant app.

Requerida para la configuración

Sí

Se instala automáticamente, no se puede eliminar, y la configuración inicial del dispositivo no termina hasta que la instalación se completa.

Quiosco

Sí

Se fija como intent de inicio preferido y se permite en el modo lock task. La configuración inicial espera por ella, el usuario no puede eliminarla y la barra de estado se desactiva automáticamente. Solo una app por política puede usarlo.

:::warning **Preinstalada se envía una sola vez y no se reenvía.** Si la app desaparece después del dispositivo —porque el usuario la eliminó o por cualquier otro motivo— la política **no** la vuelve a poner. Es la consecuencia lógica de permitir que el usuario pueda eliminarla. Para recuperar apps **Preinstaladas** que falten, cámbialas temporalmente a **Forzar instalación**, deja que los dispositivos sincronicen y devuélvelas a su sitio. Volver a ponerlas como **Preinstalada** no desinstala nada. ::: ![app install type](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/26bd603c-e61e-4e5f-8f85-2d17976891e2.png) :::info Ten en cuenta que también hay una **configuración importante a nivel de política** que afecta al comportamiento de la opción de instalación **Disponible**. El **Modo Play Store** controla qué apps son visibles para los usuarios en Play Store y cómo el dispositivo gestiona las apps que se eliminan de la política. Por defecto, está configurado en **lista blanca**, lo que significa que solo las apps incluidas en la política están disponibles, y cualquier app no incluida en la política se desinstalará automáticamente. También puedes configurarlo en **lista negra**, donde todas las apps están disponibles por defecto, y solo las apps que marques explícitamente como **bloqueadas** serán restringidas o eliminadas del dispositivo. ::: La instalación automática de apps de Applivery a través de Managed Google Play facilita mucho la gestión de dispositivos Android. Al configurar las apps como **obligatorias**, puedes asegurar que tus aplicaciones empresariales se desplieguen de forma rápida, eficiente y consistente en todos los dispositivos. ### Soporte para dispositivos AOSP :::warning La instalación automática de apps a través de **Managed Google Play** requiere Google Mobile Services y **no está disponible en dispositivos AOSP**. ::: En dispositivos AOSP, las apps se instalan de forma forzada a través del [**Self-Service de Applivery**](https://docs.applivery.com/es/device-management/android/policies/agent/#portal-self-service). Para instalar una app de forma forzada: **Añade las apps a una política** Consulta nuestra documentación, [Cómo distribuir apps privadas de Android vía MDM](https://docs.applivery.com/es/device-management/android/app-management/private-app-distribution/), y sigue los pasos descritos allí. **Define el tipo de instalación** Configura el tipo de instalación en **Instalación forzosa** o **Quiosco**. El DPC descargará e instalará silenciosamente el APK durante la próxima sincronización de la política. Los tipos de instalación disponibles en AOSP son:

Tipo de instalación

Comportamiento

Instalación forzosa

La app se instala silenciosamente en la primera sincronización y se mantiene instalada. Los usuarios no pueden desinstalarla.

Quiosco

La app se instala de forma forzada y se fija a la pantalla en modo Kiosk de una sola app.

No existe el concepto de **Disponible** o **Bloqueada** a través de Google Play en AOSP — las apps no incluidas en la política simplemente no se distribuyen al dispositivo. --- ## Propiedades gestionadas de las apps Source: https://docs.applivery.com/es/device-management/android/app-management/managed-apps-properties/ Description: Configura propiedades de apps gestionadas en Android con Applivery para personalizar su comportamiento de forma remota y garantizar una experiencia uniforme. TL;DR: Configure de forma remota los ajustes de apps Android con las propiedades gestionadas de Applivery para experiencias de usuario consistentes y seguras. Answers: ¿Qué son las propiedades gestionadas en Applivery? · ¿Cómo se configuran las propiedades gestionadas de una app en Applivery? · ¿Qué tipo de ajustes se pueden configurar con las propiedades gestionadas? · ¿Cuáles son los beneficios de usar propiedades gestionadas con Applivery? · ¿Son compatibles las propiedades gestionadas con dispositivos AOSP? · ¿Dónde se configuran las propiedades gestionadas en Applivery? Key topics: Propiedades gestionadas, Applivery, Configuración de apps Android, Políticas MDM, Android, MDM, SSL Al gestionar dispositivos Android con Applivery, no se trata solo de instalar o bloquear apps. Muchas aplicaciones permiten ajustar su comportamiento a través de lo que se conoce como **propiedades gestionadas**. Estas propiedades le permiten preconfigurar ciertos aspectos de las apps (como URLs, permisos, comportamiento predeterminado, etc.) incluso antes de que el usuario las abra por primera vez. Todo se realiza desde el panel de Applivery, sin necesidad de tocar el dispositivo. ### ¿Qué son las propiedades gestionadas? Las **propiedades gestionadas** son opciones de configuración que una app ofrece cuando se gestiona a través de un sistema MDM. Por ejemplo, una app de correo electrónico podría permitirle preconfigurar el servidor, el puerto y si se requiere SSL. Applivery detecta automáticamente estas propiedades en apps compatibles y le permite modificarlas desde el panel. ### ¿Cómo configurarlas? **Navega a Políticas** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a cualquiera de tus **políticas 1.** Selecciona la sección **Apps** 2 en el menú de la izquierda y haz clic en el botón **\+ Añadir App** 3. ![add app](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/052e37a7-4cf2-49e3-898d-e51a7b2d2db2.png) **Elije una app** Elije una **app** 4 de la lista y, al hacer clic en ella, aparecerá un menú lateral que mostrará todas las **propiedades configurables disponibles** 5. **Configura las propiedades gestionadas** Simplemente rellena los campos según los ajustes que desees aplicar. **Guarda y despliega** Una vez que hayas terminado, haz clic en el botón **Guardar cambios** 6 y despliega la política al grupo de dispositivos seleccionado; los ajustes se aplicarán automáticamente. ![managed properties](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/d51b87c2-6a45-4054-b011-5c80db8eaee9.png) Las propiedades gestionadas son una herramienta potente para personalizar el comportamiento de las apps en dispositivos gestionados, sin depender del usuario final. Ayudan a ahorrar tiempo, reducir errores de configuración y garantizar una experiencia de usuario más consistente y segura. Todo desde el panel de Applivery, con solo unos pocos clics. ### Soporte para dispositivos AOSP Las propiedades gestionadas de las apps son totalmente compatibles con AOSP — mismos pasos, misma experiencia. El DPC de Applivery las aplica en el momento de la instalación usando `DevicePolicyManager.setApplicationRestrictions(...)`, sin requerir servicios de Google. Cualquier app que exponga un esquema de configuración gestionada (`` en su manifiesto) funciona de la misma manera. --- ## Configurar Microsoft Defender Source: https://docs.applivery.com/es/device-management/android/app-management/microsoft-defender/ Description: Configura Microsoft Defender para Android en Applivery en 3 pasos. Protege tus dispositivos con anti-phishing y VPN sin interacción del usuario. TL;DR: Añade Microsoft Defender a tu política Android en Applivery, configura sus Propiedades gestionadas y despliega. Defender se configurará automáticamente en los dispositivos inscritos antes de que el usuario lo abra. Answers: ¿Cómo configuro Microsoft Defender para Android de forma remota con Applivery? · ¿Cuáles son las principales opciones de configuración de Microsoft Defender en Applivery? · ¿En qué tipos de dispositivos están disponibles la protección antiphishing y VPN de Microsoft Defender? · ¿Cómo activo la protección de Microsoft Defender en el perfil personal de dispositivos COPE? · ¿Cuándo surte efecto la configuración de Microsoft Defender en dispositivos Android? Microsoft Defender para Android admite la configuración remota a través de [propiedades gestionadas](https://docs.applivery.com/es/device-management/android/app-management/managed-apps-properties/), lo que significa que puedes controlar su comportamiento directamente desde el panel de Applivery, sin necesidad de interacción del usuario. La configuración se envía al dispositivo antes de que el usuario abra la app por primera vez. **Añadir Microsoft Defender a tu política** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a cualquiera de tus políticas 1 o [crea una nueva](https://docs.applivery.com/es/device-management/general-settings/create-policies/)**,** y selecciona la sección **Apps** 2 del menú de la izquierda. Haz clic en **\+ Añadir App** 3 y busca **Microsoft Defender: Antivirus** en la pestaña Managed Google Play. ![add app](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/052e37a7-4cf2-49e3-898d-e51a7b2d2db2.png) **Configurar propiedades gestionadas** Una vez que selecciones la app, se abrirá un panel lateral con todas las propiedades gestionadas disponibles. ![microsoft defender managed properties](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/706bc0f3-ef80-409a-8a9b-55aaf529f0ba.png) Rellena los parámetros según las necesidades de tu organización:

Parámetro

Predeterminado

Descripción

Anti-Phishing

1 (activado)

Protege contra URLs maliciosas. Disponible solo en dispositivos totalmente administrados y dedicados.

VPN

1 (activado)

Dirige el tráfico del dispositivo a través de Defender para la inspección de amenazas en tiempo real.

Microsoft Defender

1 (activado)

Interruptor principal de protección. Desactivarlo desactiva todas las funciones activas de Defender.

Defender en perfil personal (COPE)

No configurado

Extiende la protección de Defender al perfil personal en dispositivos inscritos en COPE.

Ocultar URLs en informes

No configurado

Evita que las URLs se registren en los informes de seguridad de Defender.

:::info Mantén **Anti-Phishing** y **Protección de Defender** configurados en `1`. Desactivar cualquiera de ellos dejaría a los dispositivos sin detección activa de amenazas ni cobertura anti-phishing. ::: :::warning La protección Anti-Phishing y VPN solo se aplica a dispositivos **totalmente administrados** y **dedicados**. En dispositivos COPE, utiliza la configuración **Defender en perfil personal** para extender la cobertura al perfil personal. ::: **Guardar y desplegar** Haz clic en **Guardar cambios** y despliega la política en tus dispositivos. Defender se configurará automáticamente, antes de que el usuario abra la app por primera vez. --- ## Distribución de apps privadas vía MDM Source: https://docs.applivery.com/es/device-management/android/app-management/private-app-distribution/ Description: Distribuye apps Android privadas en dispositivos gestionados con Applivery. Controla versiones y accesos sin depender de tiendas externas. TL;DR: Distribuye apps Android internas de forma segura en dispositivos gestionados con Applivery, evitando App Stores públicas y manteniendo control total sobre versiones y accesos. Answers: ¿Qué es distribución de apps privadas de Applivery ? · ¿Cuáles son los principales beneficios de usar Applivery para la distribución de apps privadas? · ¿Puede Applivery distribuir apps a dispositivos AOSP? · ¿Cuándo es especialmente útil la Distribución de Apps de Applivery? · ¿Cómo añado una app privada a una política de dispositivos en Applivery? · ¿Cuáles son los requisitos para que funcione la distribución de apps privadas de Applivery? · ¿La Distribución de Apps de Applivery requiere una cuenta de Google Play? Key topics: distribución de apps, Android Enterprise, gestión de dispositivos móviles, Applivery, Google Play La Distribución de Apps de Applivery permite a las organizaciones **gestionar y distribuir de forma segura apps privadas en dispositivos Android totalmente administrados** sin depender de App Stores externas como Google Play. Al combinar la Distribución de Apps con la gestión de dispositivos en un modelo de despliegue de Android Enterprise (Totalmente administrado), los administradores pueden mantener un control total sobre el versionado de las apps, los permisos de acceso y los flujos de trabajo de despliegue desde un panel de Applivery centralizado. :::info Los **dispositivos AOSP** también pueden distribuir apps privadas a través del [**Self-Service de Applivery**](https://docs.applivery.com/es/device-management/android/policies/agent/#portal-self-service) utilizando el mismo flujo de trabajo, sin necesidad de una cuenta de Google Play. ::: Este enfoque es especialmente valioso cuando: - Se distribuyen apps internas o exclusivas de la empresa. - La app no está destinada a su publicación en Google Play. - Se requiere un control estricto sobre las versiones de Build y los despliegues por fases. - Las apps deben desplegarse en grupos de dispositivos, segmentos o políticas específicos. Con Applivery, las apps privadas pueden crearse y configurarse directamente dentro de la plataforma, actualizarse mediante cargas de build controladas, distribuirse automáticamente a través de políticas y gestionarse junto con otros recursos y configuraciones empresariales, lo que garantiza una estrategia de movilidad Android Enterprise segura, conforme y totalmente integrada. **Crea tu primera app** Puedes seguir las instrucciones sobre cómo crear tu primera app siguiendo [este enlace](https://docs.applivery.com/es/app-distribution/getting-started/create-first-app/). **Carga tu primera build** Puedes seguir las instrucciones sobre cómo cargar tu primera Build siguiendo [este enlace](https://docs.applivery.com/es/app-distribution/getting-started/upload-first-build/). **Añade tu app a una política** Ahora, navega a cualquiera de tus políticas 1. Desde el menú de la izquierda, dirígete a **Apps** 2 y haz clic en el botón **\+ Añadir App** 3. Luego selecciona la pestaña **Applivery** 4 y selecciona la **app** 5 que acabas de subir. Después de seleccionar la app, podrás elegir la build específica según tus requisitos y definir el tipo de instalación. ![add app from app distribution](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/cee02304-6fa6-495b-8f56-793d5f9f093a.png) :::warning Esta característica requiere que el [Agente MDM de Applivery](https://docs.applivery.com/es/device-management/android/policies/agent/) esté habilitado a nivel de política, que la app se haya abierto al menos una vez y que se hayan concedido todos los permisos necesarios. ::: La gestión y distribución de apps privadas a través de la Distribución de Apps de Applivery proporciona a las organizaciones un flujo de trabajo de despliegue seguro, centralizado y totalmente controlado. Al crear tu app, subir builds y asignar la app a través de políticas o el despliegue directo en dispositivos, puedes asegurar que los usuarios correctos reciban la versión correcta en el momento adecuado. Este enfoque elimina la dependencia de App Stores externas, simplifica la gestión de versiones y permite despliegues controlados en toda tu flota de dispositivos. Con las capacidades integradas de gestión de dispositivos de Applivery, la distribución de apps privadas se convierte en una parte integral de tu estrategia general de movilidad empresarial, mejorando la eficiencia operativa mientras se mantiene la gobernanza y la seguridad. --- ## Distribución de apps privadas con Managed Google Play Source: https://docs.applivery.com/es/device-management/android/app-management/private-app-managed-google-play/ Description: Sube apps privadas de Android a Managed Google Play. Crea, actualiza y controla las actualizaciones para los dispositivos de tu organización. TL;DR: Gestiona y distribuye apps privadas de Android con Applivery MDM a través de Managed Google Play Console. Answers: ¿Cuáles son los métodos para distribuir apps privadas con Applivery Device Management? · ¿Se pueden distribuir apps privadas a través de Managed Google Play en dispositivos AOSP? · ¿Cómo subo una nueva app privada a Managed Google Play usando Applivery? · ¿Cuánto tiempo tarda una app privada en estar disponible después de subirla a Managed Google Play? · ¿Cómo actualizo una app privada existente en Managed Google Play a través de Applivery? · ¿Cuáles son los modos de actualización automática disponibles para apps en la Gestión de Dispositivos de Applivery? · ¿Puede Applivery forzar actualizaciones inmediatas para apps privadas en dispositivos? · ¿Dónde puedo realizar ediciones avanzadas o personalizar la apariencia de mi app privada? Key topics: Gestión de Apps Privadas, Applivery MDM, Google Play Console, Distribución de Apps Android, Actualizaciones de Apps, Applivery, Android, Google Play Services, Fastlane, Bitrise :::warning La distribución de apps privadas a través de Managed Google Play requiere Google Mobile Services y **no está disponible en dispositivos AOSP**. En AOSP, las apps privadas se distribuyen directamente a través del [**Self-Service de Applivery**](https://docs.applivery.com/es/device-management/android/policies/agent/#portal-self-service). Consulta [Gestión de Android AOSP](https://docs.applivery.com/es/device-management/android/aosp/) para más detalles. ::: La Gestión de Dispositivos de Applivery te permite gestionar y distribuir tus apps privadas de tres maneras diferentes: - Como una app privada autohospedada gestionada fuera de Google Play Console (puedes leer más [aquí](https://docs.applivery.com/es/app-distribution/platforms/android/self-hosted-private-apps/)). - Como una app privada autohospedada gestionada a través de la Distribución de Apps de Applivery (puedes leer más [aquí](https://docs.applivery.com/es/device-management/android/app-management/private-app-distribution/)). - Como una app privada gestionada a través de [Google Play Console](https://play.google.com/console). Ofrece dos opciones: 1. Utilizar la cuenta de Managed Google Play Console de Google que se creará automáticamente al subir apps privadas a través de tu Managed Google Play. 2. Utilizar tu propia Google Play Console para configuraciones avanzadas, requisitos de automatización y mayor flexibilidad. Puedes leer más sobre cómo conectar tu cuenta de desarrollador de Google Play Console existente con Applivery [aquí](https://docs.applivery.com/es/device-management/android/app-management/connect-google-play-console/). Nos centraremos en el tercer escenario (3.1), utilizando la cuenta de Managed Google Play Console de Google. ### Crear y cargar una app privada **Navega a Políticas y Apps** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io), dirígete a cualquiera de tus políticas 1. Desde el menú lateral izquierdo, dirígete a **Apps** 2 y haz clic en el botón **\+ Añadir App** 3. ![add app](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/99357efb-6f20-4548-a9c9-d0df179cd02e.png) **Accede a Managed Google Play y Private Apps** Luego selecciona la pestaña **Google Play** 4. Una vez dentro de tu Managed Google Play, dirígete a la opción del menú lateral izquierdo **Private Apps** 5. ![private app managed google play](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/f6616a2f-af35-4c99-b7b8-7b2cc2ad8712.png) **Sube tu app** Ahora, haz clic en el botón circular **+** 6 para empezar a crear y subir tu primera app privada. Elige un nombre para tu app y busca en tu unidad para seleccionar un archivo APK. :::warning Ten en cuenta que vas a subir una nueva app privada a Google Play Console, por lo que Google reservará y bloqueará el nombre del paquete de tu app (es decir: `com.applivery.kioskapp`) para esta organización, y ya no podrás usarlo de nuevo en ninguna otra app u organización. Te recomendamos encarecidamente que elijas cuidadosamente el nombre del paquete o incluso que añadas un sufijo para fines de prueba. ::: ![Add app to policy](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/17c88c43-4fc1-4cdf-86a3-8fbab0a0b2b4.png) :::warning Una vez cargada, **tu app puede tardar entre 2 y 48 horas en estar completamente disponible** en tu cuenta. Ten en cuenta que este plazo depende del proceso de revisión y publicación de Google. ::: ### Actualizar una app privada o realizar ediciones avanzadas Probablemente querrás actualizar tus apps privadas de vez en cuando o realizar ediciones avanzadas para cambiar el icono, la descripción, el idioma o cualquier otro aspecto de tu app. Estas operaciones se pueden realizar desde Applivery a través de Google Play Console. #### Subir una nueva versión de tus apps privadas **Navega a Políticas y Apps** Desde una de tus políticas 1, dirígete a **Apps** 2 y haz clic en el botón **\+ Añadir App** 3. ![add app](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/4a3a6078-c736-446e-89d3-98cc38b57ea9.png) **Accede a Managed Google Play y selecciona la App** Luego selecciona la pestaña **Google Play** 4. Una vez dentro de tu Managed Google Play, dirígete a la opción del menú lateral izquierdo **Private Apps** 5 y selecciona una de las **apps** 6. ![private app management](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/9125925f-c4b5-4603-81f6-d286d076cb62.png) **Edita la app y sube una nueva versión** Luego haz clic en **Editar** 7 junto al botón Seleccionar. ![edit private app](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/b351e7ca-6d22-4627-a580-60838ee7b725.png) Por último, haz clic en **editar** 8 de nuevo junto al nombre del archivo APK y selecciona un archivo de tu sistema de archivos. Google Play analizará el paquete y, una vez finalizado, te permitirá pulsar el botón **Guardar** 9 para empezar a subir el archivo. :::warning Ten en cuenta que **debes aumentar el número de versión y el código de versión de tu app** antes de subir una nueva versión. En cualquier otro caso, la subida será rechazada. ::: ![Save private app](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/8a9c4303-cc2c-4d24-87e7-b7c7c65ae8c9.png) #### Controlar las actualizaciones de la app y el tiempo de actualización Actualizar regularmente las apps en los dispositivos de tu organización garantiza que los usuarios se beneficien de las funcionalidades más recientes, una seguridad mejorada y una mayor fiabilidad. Las actualizaciones de apps son gestionadas por Google a través de Google Play Services, y Applivery no puede forzar la actualización de una app (puedes leer más sobre esto [aquí](https://developers.google.com/android/management/control-app-updates)). Muchos factores pueden afectar los tiempos de actualización. - **Comportamiento de actualización predeterminado:** En la configuración predeterminada, las apps se actualizan automáticamente cuando se cumplen condiciones específicas: - El dispositivo se conecta a una red Wi-Fi. - El dispositivo está en modo de carga. - El dispositivo no está en uso activo. - La app programada para una actualización no está abierta en primer plano. :::warning Google Play suele realizar comprobaciones de actualizaciones de apps diariamente. Por lo tanto, una actualización de app podría tardar un máximo de 24 horas en entrar en la cola de actualización. Una vez que una app está en la cola, se actualizará automáticamente la próxima vez que se satisfagan las condiciones anteriores. ::: Puedes anular la configuración de actualización para personalizar aún más el comportamiento de actualización de la app en los dispositivos que gestionas: - **Alta Prioridad:** Este modo garantiza que tu app se mantenga actualizada, actualizándola inmediatamente tras la aprobación de Google Play. En caso de que tu dispositivo esté sin conexión cuando se lance una actualización, se actualizará automáticamente en el momento en que te reconectes a internet. :::warning Si la app está en uso cuando la actualización está lista para instalarse, la app se cerrará durante la actualización, lo que podría afectar a tus usuarios. ::: - **Modo Pospuesto:** Utiliza esta opción si quieres pausar las actualizaciones de una app, lo que impide que la app se actualice automáticamente durante un período inicial de 90 días después de que se quede desactualizada por primera vez. Después de este período de 90 días, la última versión disponible de la app se instala automáticamente utilizando el modo de actualización predeterminado. Una vez que la app se actualiza a la última versión disponible, comenzará un nuevo período de aplazamiento de 90 días a partir de la próxima vez que el desarrollador publique una nueva versión de la app. :::warning El modo Pospuesto no impide que tus usuarios actualicen la app manualmente. Durante el período de aplazamiento de 90 días, tus usuarios pueden actualizar la app manualmente visitando Google Play Store en sus dispositivos. ::: **Navega a la configuración de la app** Para modificar el modo de actualización, dirígete a cualquiera de tus políticas 1, busca la sección **Apps** 2 en el menú lateral izquierdo y luego haz clic en la app que quieres modificar 3 el modo de actualización. **Modifica el Modo de Actualización Automática** Encuentra la opción **Modo de Actualización Automática** 4 en el panel deslizante que aparece a la derecha y elige tu opción preferida. ![app auto update](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/6f48187c-e33b-4b98-8491-52de8da31681.png) #### Realizar ediciones avanzadas También puedes personalizar completamente el aspecto de tu app en tu Managed Google Play desde el botón **Realizar Ediciones Avanzadas** que encontrarás debajo de tus apps privadas. Serás redirigido a **Google Play Console**, donde podrás personalizar completamente cada aspecto de tu app e incluso cargar nuevas versiones de una manera más avanzada (o incluso automatizada) a través de herramientas como [Fastlane](https://docs.applivery.com/es/app-distribution/ci-cd/fastlane/) o [Bitrise](https://docs.applivery.com/es/app-distribution/ci-cd/bitrise/). ![applivery-mdm-google-play-console-edits](https://www.applivery.com/wp-content/uploads/2021/12/applivery-mdm-google-play-console-edits-1024x651.png "applivery-mdm-google-play-console-edits | Applivery") --- ## Apps del sistema Source: https://docs.applivery.com/es/device-management/android/app-management/system-apps/ Description: Controla las apps del sistema Android con políticas de Applivery. Ideal para configuraciones de modo quiosco. TL;DR: Gestiona apps del sistema Android en políticas de Applivery para un mayor control de la funcionalidad del dispositivo, especialmente en modo quiosco. Answers: ¿Qué son las apps del sistema Android en Applivery? · ¿Cómo añado una app del sistema a una política de Applivery? · ¿Dónde puedo encontrar una lista de los nombres de paquete de las apps del sistema en Applivery? · ¿Cuál es el primer paso para gestionar apps del sistema Android con Applivery? · ¿Qué debo hacer después de seleccionar una app del sistema en Applivery? · ¿Cuál es el paso final para añadir una app del sistema a una política de Applivery? · ¿Por qué gestionar apps del sistema con Applivery? Key topics: Políticas de Applivery, Gestión de apps del sistema Android, Configuración de modo quiosco, Applivery, Android, MDM Con Applivery, también puedes gestionar apps del sistema Android. Esta funcionalidad proporciona un mayor control sobre cualquier app en los dispositivos de tu flota Android. Es particularmente útil para configuraciones de modo quiosco, donde quieres que los usuarios tengan acceso solo a un conjunto específico de apps. ### Añadir apps del sistema a las políticas **Navegar a Políticas** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io), dirígete a cualquiera de tus políticas 1. Desde el menú lateral izquierdo, dirígete a **Apps** 2 y haz clic en el botón **\+ Añadir App** 3. ![add app](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/478927ae-7df5-4139-9bbe-d00b5963177b.png) **Seleccionar app del sistema** Luego selecciona la pestaña **App del sistema** 4. Verás un menú desplegable donde puedes seleccionar la app del sistema que quieres gestionar o pegarla. :::info Una vez que habilites la configuración **Informes de aplicación activados** en la sección de **Reportes** a nivel de política, **la lista completa de apps** —incluidas las apps del sistema— **estará disponible** en el detalle del **Dispositivo,** en la sección de **Apps**. Esto facilita encontrar los nombres de paquete requeridos. ::: ![system Apps](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/b0327e12-b31f-4601-9022-a47e6108c719.png) **Confirmar selección** Una vez que hayas seleccionado la app, haz clic en **Seleccionar**. **Elegir tipo de instalación** Finalmente, elige un tipo de instalación que se adapte a tus necesidades y añade la app a la lista de aplicaciones gestionadas dentro de tu política. --- ## Permitir apps de fuentes desconocidas Source: https://docs.applivery.com/es/device-management/android/app-management/untrusted-app-installs/ Description: Configura dispositivos Android para permitir apps de fuentes desconocidas con políticas de Applivery. Supera las restricciones de seguridad predeterminadas. TL;DR: Habilita la instalación de apps de fuentes desconocidas en dispositivos Android mediante las políticas MDM y la configuración del dispositivo de Applivery. Answers: ¿Por qué Android bloquea las apps de fuera de Google Play Store? · ¿Cómo permito la instalación de apps de fuentes desconocidas a través de Applivery? · ¿Qué es la configuración 'Play Store Mode' en Applivery? · ¿Qué sucede si mi administrador de TI me impide habilitar las fuentes desconocidas? · ¿Puedo personalizar el mensaje de bloqueo que ven los usuarios al intentar instalar apps no fiables? · ¿Los usuarios necesitan otorgar permisos en su dispositivo incluso si la política permite fuentes desconocidas? · ¿Dónde puedo encontrar instrucciones para otorgar permisos de dispositivo para fuentes desconocidas? · Si tengo un Perfil de trabajo, ¿dónde se pueden instalar apps no fiables? Key topics: Configuración de seguridad de Android, Políticas MDM de Applivery, Configuración de la 'Untrusted Apps Policy', Configuración de 'Play Store Mode', Otorgar permisos de dispositivo, Android, Google Play Store, Applivery, Administrador de TI ![unknown-sources](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/651d6b07-cbbf-476d-9144-229f31f94b6d.jpg "unknown-sources | Applivery") El sistema operativo Android incluye una función de seguridad integrada que bloquea la instalación de apps de fuentes externas a Google Play Store. Esto significa que si intentas instalar una app descargada de una fuente que no sea Google Play Store, es posible que encuentres varios mensajes de advertencia. Por defecto, el permiso para instalar apps de fuentes que no sean Google Play Store está deshabilitado. Esto significa que ningún dispositivo podrá descargar, configurar o instalar una app no autorizada a menos que se permita explícitamente a través de una política. ![blocked by it admin](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/4b385066-06c6-4166-85c4-fc640e1a6029.png) :::danger Bloqueado por tu administrador de TI. Si tienes preguntas, contacta con tu administrador de TI. Si un usuario intenta habilitar esta configuración en su dispositivo, encontrará un mensaje de bloqueo de su administrador de TI y no podrá habilitarla. ::: :::info Estos mensajes se pueden personalizar utilizando la propiedad [Mensaje de Soporte Corto](https://docs.applivery.com/es/device-management/android/policies/personalized-support-messages/). ::: ### Configuración de tu política Una vez en el [**panel de Applivery**](https://dashboard.applivery.io) dirígete a cualquiera de tus políticas 1. Desde el menú lateral izquierdo, selecciona **Restricciones** 2, localiza la sección **App**, y luego busca la configuración **Anulaciones de seguridad avanzadas** > **Política de aplicaciones no fiables** 3. :::warning Para dispositivos con perfil de trabajo, las instalaciones de apps no fiables solo se pueden permitir dentro del perfil personal. Alternativamente, se pueden habilitar en todo el dispositivo. ::: ![untrusted Apps](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/8a240bee-067c-4e1b-b057-b07d098a7159.png) Ahora, localiza la configuración **Modo Play Store** 4 (que no debe confundirse con Modo personal Play Store) y establécela en **Lista negra**. Con esta configuración, **todas las apps están disponibles**, y cualquier app que no deba estar en el dispositivo debe ser explícitamente **marcada como BLOQUEADA** en la política de aplicaciones. ![play store mode](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/d11bf46e-7d7f-4251-8e20-6c6d347b32ca.png) ### Configuraciones adicionales en el dispositivo Como se mencionó anteriormente, el permiso para instalar apps de fuentes que no sean Google Play Store está deshabilitado por defecto. Incluso si la instalación de apps de fuentes desconocidas está permitida a través de una política, el usuario aún debe otorgar los permisos necesarios directamente en su dispositivo. Para aprender a otorgar estos permisos, consulta nuestra documentación sobre [instalación de apps de fuentes desconocidas](https://docs.applivery.com/es/app-distribution/platforms/android/unknown-sources/). --- ## Apps web Source: https://docs.applivery.com/es/device-management/android/app-management/web-apps/ Description: Añade apps web a dispositivos Android con Applivery MDM mediante políticas. Incluye configuración de accesos directos y modo quiosco. TL;DR: Crea y configura apps web en Android fácilmente con Applivery para un despliegue y gestión optimizados, incluyendo la configuración de modo quiosco. Answers: ¿Cómo añado una app web a una política de dispositivos Android en Applivery? · ¿Qué detalles necesito configurar para una app web en Applivery? · ¿Cómo me aseguro de que una app web esté en la pantalla de inicio del dispositivo? · ¿Cómo muestro una app web en modo quiosco usando Applivery? · ¿Cómo puedo restringir el acceso a URL cuando uso una app web en modo quiosco? · ¿Cómo permito el acceso a mi app web en modo quiosco? · ¿Dónde encuentro la opción de apps web en Applivery? Key topics: Creación de apps web, Configuración de Applivery, Gestión de dispositivos Android, Configuración de modo quiosco, Control de acceso a URL, Applivery, Android, Google Chrome, Google Play Las apps web se pueden añadir fácilmente a la pantalla de inicio de los dispositivos Android, proporcionando acceso rápido a tus páginas web o enlaces favoritos. ### Añade tu app web a una política de dispositivos **Navega a Políticas** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a cualquiera de tus políticas 1. Desde el menú lateral izquierdo, dirígete a **Apps** 2 y haz clic en el botón **\+ Añadir App** 3. ![add app](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/64b3464d-a8e1-4afc-8429-bdcac4e7d6e7.png) **Añade una app web** En el menú lateral izquierdo de la pestaña **Google Play**, encontrarás un icono de globo etiquetado como **Apps web** 4. Usa el botón **+** 5 situado en la parte inferior derecha de la pantalla para añadir tu primera app web. ![web Apps](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/4200fb5c-9239-4a4e-aa02-da43ca2dfe52.png) **Configura los detalles de la app web** - Asigna un **título** a la app web que servirá como el nombre mostrado a los usuarios del dispositivo en el icono de la app. - Añade la **URL** de la app web que se lanzará cuando el usuario del dispositivo toque la app. - Elige el **modo de visualización** que determina cómo el navegador presenta el contenido del sitio web. - Además, tienes la opción de proporcionar un **icono** para tu app web. Este icono debe ser un archivo JPG o PNG rectangular con una resolución de 512×512. En caso de que no se especifique un icono, se utilizará un icono de maletín predeterminado. **Creación de la app web** Después de incorporar toda la información necesaria, procede haciendo clic en el botón **Crear**. Esta acción resultará en la adición de una nueva app web. :::warning Puede tardar unos minutos en estar completamente accesible. Sin embargo, una vez que esté preparada, puedes tratarla como cualquier otra app añadiéndola a la lista de Apps. ::: Elegir el tipo de instalación **Forzar instalación** coloca el icono de la app web en la pantalla de inicio del dispositivo y evita que el usuario la elimine. No es un requisito: una app web se distribuye como cualquier otra app, así que **Disponible** también funciona — en ese caso es el usuario quien la añade desde la tienda gestionada de Play. :::info **El requisito de `FORCE_INSTALLED` es del navegador, no de la app web.** Una app web es un acceso directo que necesita un navegador instalado para abrirse, así que Chrome es el que tiene que ir en instalación forzada. La app web en sí puede quedar como disponible. ::: ![configure web app](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/26c9a744-07c8-4f7a-bb97-7dbae3ce04db.png) ### Apps web en modo quiosco Para mostrar tu app web en modo quiosco, necesitarás incluir un navegador. Puedes optar por la app Google Chrome desde la pestaña **Google Play** y elegir el tipo de instalación **Forzar instalación**. Además, cambia el tipo de instalación de tu app web a **Quiosco**. ![chrome force install](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/06b83d66-5a47-4f45-a566-45d2fdaa5e37.png) Una vez que hayas incluido Google Chrome en tu lista de apps, haz clic en ella para continuar. Esta acción mostrará un menú lateral, donde podrás configurar las [**propiedades gestionadas de la app**](https://docs.applivery.com/es/device-management/android/app-management/managed-apps-properties/). Para restringir el acceso a una lista de URL, navega a la configuración **Bloquear acceso a una lista de URL**, donde tendrás dos opciones: - Bloquear una lista de URL siguiendo este formato: `["URL bloqueada 1", "URL bloqueada 2"]`. - Alternativamente, bloquea el acceso a todas las URL excepto la especificada en **Permitir acceso a una lista de URL** definiendo `["*"]`. Si quieres permitir a los usuarios del dispositivo abrir tu app web, es crucial configurar el ajuste **Permitir acceso a una lista de URL** con la URL específica de tu app web. ![chrome configurations](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/d26014b2-3979-4eaf-bab9-0b832bc2a0a5.png) --- ## Comandos Source: https://docs.applivery.com/es/device-management/android/commands/ Description: Applivery permite ejecutar comandos MDM remotos en dispositivos Android gestionados. TL;DR: Los comandos MDM de Android de Applivery simplifican el control de dispositivos con ejecución remota y aplicación de políticas. Answers: ¿Qué son los comandos MDM de Android? · ¿Cómo ejecutar comandos remotos en Applivery? · ¿Qué comandos están disponibles para dispositivos Android? · ¿Cómo aplicar políticas usando comandos de Applivery? · ¿Qué acciones remotas puedo realizar con los comandos MDM de Android? · ¿Se necesita acceso físico para usar los comandos MDM de Android? · ¿Para qué tipo de dispositivos están diseñados los comandos MDM de Android? · ¿Qué información se documenta sobre los comandos MDM de Android? Key topics: Comandos MDM de Android, Applivery, Gestión Remota de Dispositivos, Aplicación de Políticas de Dispositivos, Android, Comandos MDM Los comandos de Android te permiten realizar acciones remotas en tiempo real en dispositivos Android gestionados — como bloquear un dispositivo, restablecer una contraseña, borrar datos, reiniciarlo o actualizar su configuración sin necesidad de acceso físico. Cada comando remoto disponible para Android incluye cuándo usarlo y qué sucede en el dispositivo cuando se ejecuta. --- ## Gestión de eSIM Source: https://docs.applivery.com/es/device-management/android/commands/esim-management/ Description: Gestiona perfiles eSIM en dispositivos Android con Applivery aprovechando las funciones de Android 15. Aprovisiona y elimina eSIMs de forma remota. TL;DR: Gestiona perfiles eSIM de Android fácilmente con Applivery y Android 15 para un despliegue optimizado y seguridad mejorada. Answers: ¿Cuáles son los requisitos para la gestión de eSIM de Applivery? · ¿Qué pueden hacer los administradores de TI con las funciones de gestión de eSIM de Applivery? · ¿Cómo añado una eSIM a un dispositivo usando Applivery? · ¿Cómo elimino una eSIM de un dispositivo con Applivery? · ¿Está disponible la gestión de eSIM en dispositivos AOSP? · ¿Pueden los administradores de TI controlar si los usuarios pueden añadir eSIM en dispositivos corporativos? Key topics: Gestión de eSIM en Android, Integración con Applivery, Funciones de Android 15, Aprovisionamiento de eSIM, Eliminación de eSIM, Android, Android 15, Applivery, eSIM, ICCID, EID, eUICC, perfil de trabajo, Android Management API :::warning La gestión de eSIM utiliza la Android Management API (AMAPI) y requiere los Google Mobile Services. Esta característica **no está disponible en dispositivos AOSP**. ::: Android 15 simplifica el proceso de añadir, eliminar y aprovisionar perfiles eSIM tanto en dispositivos propiedad de la empresa como en dispositivos BYOD gestionados. Esto significa que los administradores de TI pueden ahora aprovechar una experiencia más unificada y consistente en todos los tipos de dispositivos, ayudando a las organizaciones a reducir la complejidad operativa y mejorar la eficiencia del despliegue. Applivery se integra a la perfección con estas nuevas capacidades, permitiendo a los administradores gestionar centralizadamente las eSIM en toda su flota Android. Al usar Applivery, puedes de forma remota: - Instalar y aprovisionar nuevos perfiles eSIM. - Eliminar o reemplazar eSIM existentes. - Solicitar el EID de un dispositivo para aprovisionar eSIMs en dispositivos con perfil de trabajo. - Borrar las eSIMs descargadas como parte de un borrado del dispositivo. - Automatizar flujos de trabajo de eSIM para la inscripción de dispositivos o transiciones de usuarios. - Mantener una experiencia de conectividad móvil consistente y segura sin la necesidad de manipulación de SIM físicas. ### Añadir una eSIM a tu dispositivo **Navegar a dispositivos** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), selecciona cualquiera de tus dispositivos. **Abrir menú de Acción** Haz clic en el botón **Acción** 1 y elige **Añadir eSIM** 2 del menú desplegable. ![action esim](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/aeacd6a9-aceb-492e-b15f-2dd4785ac613.png) Se abrirá una ventana modal donde puedes proporcionar: - El **código de activación** de la eSIM. - El **estado de activación** de la eSIM. ### Eliminar una eSIM de tu dispositivo De forma similar a añadir una eSIM, haz clic en el botón Acción — pero esta vez, selecciona **Eliminar eSIM** 3 del menú desplegable. **Navegar a dispositivos** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), selecciona cualquiera de tus dispositivos. **Abrir menú de Acción** Haz clic en el botón **Acción** y elige **Eliminar eSIM** 3 del menú desplegable. ![action remove esim](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/6c7fe8fe-aae6-4508-8132-214db8564bad.png) Se abrirá una ventana modal donde puedes proporcionar el **ICCID** de la eSIM a eliminar. ### Solicitar el EID del dispositivo (dispositivos con perfil de trabajo) Antes de poder aprovisionar una eSIM en un **dispositivo personal con perfil de trabajo**, normalmente necesitas el **EID** (identificador eUICC) del dispositivo — el identificador único del chip eSIM que las operadoras móviles usan para generar un perfil eSIM. El comando **Solicitar información** obtiene este EID. Como los dispositivos con perfil de trabajo son propiedad del usuario, este debe aprobar compartir esta información antes de que pueda devolverse. **Navegar a dispositivos** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), selecciona el dispositivo con perfil de trabajo que quieras consultar. **Abrir menú de Acción** Haz clic en el botón **Acción** y elige **Solicitar información** del menú desplegable. El comando devuelve uno de los siguientes estados: - **Succeeded**: la información del dispositivo se entregó y se devuelve el EID (uno por cada chip eUICC). - **Pending user action**: el usuario todavía no ha completado la aprobación requerida. - **User declined**: el usuario rechazó compartir la información del dispositivo. - **Unsupported**: la información solicitada no es compatible — por ejemplo, el dispositivo no admite eSIM. :::info Solicitar el EID solo es compatible con dispositivos personales con perfil de trabajo que ejecuten **Android 13 o posterior**. Fuente: [Android Management API](https://developers.google.com/android/management/reference/rest/v1/enterprises.devices/issueCommand). ::: ### Borrar las eSIMs descargadas Al borrar un dispositivo desde **Ajustes > Zona de peligro**, puedes activar la opción **Adicionalmente, borrar todas las eSIMs descargadas** para eliminar los perfiles eSIM como parte del borrado. - En **dispositivos propiedad de la empresa**, esto elimina **todas** las eSIMs del dispositivo. - En **dispositivos personales con perfil de trabajo**, esto elimina **solo** las eSIMs gestionadas añadidas a través de Applivery (mediante el comando Añadir eSIM). :::info El borrado de las eSIMs descargadas es compatible con dispositivos que ejecuten **Android 15 o posterior**. ::: ### Configuraciones de política adicionales Con las últimas actualizaciones de la Android Management API, Applivery ahora soporta una nueva configuración a nivel de política que otorga a los administradores un mayor control sobre la gestión de eSIM en dispositivos corporativos. La **Configuración de Añadir Esim Iniciada por el Usuario** permite a los administradores de TI controlar si los usuarios finales pueden añadir perfiles eSIM en dispositivos Android propiedad de la empresa. Su propósito es habilitar o restringir las adiciones de eSIM iniciadas por el usuario, ayudando a mantener la seguridad y el cumplimiento al asegurar que solo se añadan perfiles eSIM autorizados. :::info Asegúrate de que tus dispositivos ejecutan Android 15 o posterior para aprovechar al máximo estas características de gestión de eSIM. ::: --- ## Activar modo perdido Source: https://docs.applivery.com/es/device-management/android/commands/lost-mode/ Description: Bloquea y protege remotamente dispositivos Android perdidos con el modo perdido en Applivery. Protege datos de empresa y localiza el dispositivo. TL;DR: El modo perdido en Applivery permite el bloqueo y la seguridad remota de dispositivos Android, mostrando información de contacto y rastreando la ubicación para su recuperación. Answers: ¿Qué es el modo perdido de Android? · ¿Cuáles son los requisitos para activar el modo perdido en un dispositivo Android? · ¿Cómo activo el modo perdido para un dispositivo Android? · ¿Qué información se puede mostrar en un dispositivo en el modo perdido? · ¿Qué sucede cuando se activa el modo perdido en un dispositivo? · ¿Cuándo empieza un dispositivo en el modo perdido a informar de su ubicación? · ¿Cómo puedo desactivar el modo perdido en un dispositivo Android? Key topics: Gestión de dispositivos Android, Seguridad móvil, Control remoto de dispositivos, Configuración del modo perdido, Applivery, Android :::warning El modo perdido utiliza la Android Management API (AMAPI) y requiere Google Mobile Services. Esta función **no está disponible en dispositivos AOSP**. ::: Android ahora permite a los empleadores bloquear y proteger remotamente un dispositivo perdido activando el modo perdido. Este método de bloqueo también permite mostrar opcionalmente un mensaje en la pantalla del dispositivo con información de contacto útil, lo que permite a los administradores y departamentos de TI proteger mejor los datos de la organización y de los empleados mientras intentan recuperar el dispositivo. :::warning El dispositivo de destino debe estar ejecutándose en modo **Totalmente administrado**; el Perfil de trabajo es compatible con Android 13 y versiones posteriores, y los dispositivos Totalmente administrados con Android 11 y versiones posteriores. ::: ### Activar el modo perdido Para activar el modo perdido en un dispositivo Android, simplemente navega a cualquiera de tus dispositivos y, a continuación, haz clic en el botón **Acción** 1. Finalmente, selecciona Iniciar modo perdido 2. ![action lost mode](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/de98cc21-11a7-43d5-8ba0-63db61386b7f.png) Una vista modal solicitará la siguiente información: - **Mensaje de pérdida:** Un mensaje que se mostrará en la pantalla al intentar desbloquear el dispositivo. - **Número de teléfono:** Un número de teléfono al que se puede llamar para devolver el dispositivo. - **Dirección de correo electrónico:** Una dirección de correo electrónico que se puede utilizar para organizar la devolución del dispositivo. - **Dirección postal:** Dirección completa donde se puede devolver el dispositivo. - **Nombre de la organización:** Opcionalmente, también puedes proporcionar el nombre de tu empresa. Rellena los campos y haz clic en Activar. :::info Un dispositivo no puede ponerse en modo perdido si: - La contraseña del dispositivo ha sido restablecida por un administrador de TI en las últimas 12 horas. - El empleado salió manualmente del modo perdido en las últimas 12 horas. - Es un Perfil de trabajo en un dispositivo de la empresa, y el Perfil de trabajo está en pausa. ::: Una vez activado, se producirá una serie de eventos: #### Estado de Alerta ![lost mode](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/8922dd18-db32-4c9e-b8ab-7a8d66344514.png) El dispositivo suena durante un máximo de 5 minutos, lo que permite al usuario encontrar su dispositivo y sacarlo del modo perdido. La ubicación del dispositivo no se informa durante este tiempo. Si se accede al dispositivo en el estado de alerta, se presentan dos opciones: - **Este es mi dispositivo:** Permite al empleado introducir su contraseña y sacar el dispositivo del modo perdido. Si esto ocurre antes de que finalice el período de 5 minutos, no se envían datos de ubicación del dispositivo al administrador. - **He encontrado este dispositivo:** Permite a alguien que no sea el empleado detener el sonido del dispositivo. Esto mueve el dispositivo al estado de pérdida. :::info La ubicación del dispositivo solo se enviará después de 5 minutos de entrar en el estado de alerta. ::: #### Estado de Pérdida ![lost state](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/f8f7b8af-c672-40c9-80a8-bfc6d4ef404b.png) El dispositivo deja de sonar y envía actualizaciones de ubicación cada minuto. Si se accede al dispositivo en el estado de pérdida, se muestran hasta tres opciones: - **Desbloquear:** Permite al empleado introducir su código de acceso y sacar el dispositivo del modo perdido. - **Llamar al propietario:** Inicia una llamada telefónica al número proporcionado en los parámetros de inicio del modo perdido. Esta opción está oculta si no se proporciona ningún número de teléfono. - **Emergencia:** Permite el acceso al marcador de emergencia. ### Detener el modo perdido Para desactivar el mod perdido, simplemente haz clic en el botón **Acción** y luego elige Detener modo perdido 3. Confirma la acción haciendo clic de nuevo en **Detener modo perdido**. ![action stop lost mode](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/dc2b1e78-d11e-4fa9-b314-d2dc91fdfe7e.png) --- ## Comandos remotos Source: https://docs.applivery.com/es/device-management/android/commands/remote-commands/ Description: Gestiona dispositivos Android de forma remota con Applivery MDM. Ejecuta comandos de bloqueo, restablecimiento de contraseña, reinicio y gestión de eSIM. TL;DR: Applivery MDM permite a administradores de TI gestionar dispositivos Android remotamente con comandos de bloqueo, restablecimiento de contraseña, reinicio y gestión de eSIM, mejorando seguridad y control. Answers: ¿Cómo ofrece Applivery MDM capacidades de comandos remotos para dispositivos Android? · ¿Cómo puedo bloquear un dispositivo Android de forma remota con Applivery MDM? · ¿Cuándo debo usar el comando 'Restablecer contraseña' en Applivery MDM? · ¿Puedo establecer una nueva contraseña al usar el comando remoto 'Restablecer contraseña'? · ¿Cuál es el propósito del comando 'Reiniciar' en Applivery MDM? · ¿Cómo gestiono perfiles eSIM de forma remota con Applivery MDM? · ¿Qué hace el comando 'Deshabilitar' en Applivery MDM? · ¿Qué sucede cuando 'Renuncio a la propiedad' de un dispositivo COPE? Key topics: Gestión de dispositivos Android, Comandos remotos, Applivery MDM, Android Management API, Applivery, Dispositivos Android, Google Applivery MDM utiliza la [Android Management API](https://developers.google.com/android/management/introduction) (AMAPI) para proporcionar capacidades robustas de comandos remotos para la gestión de dispositivos Android. Al depender de las amplias funciones de AMAPI, Applivery garantiza la ejecución fluida de acciones remotas, permitiendo a los administradores de TI mantener el control y aplicar políticas de seguridad de forma efectiva en su flota de dispositivos. Esta integración simplifica la gestión de dispositivos al permitir la intervención remota sin necesidad de acceso físico. ### Bloquear **Disponible para dispositivos Totalmente administrados**, este comando fuerza a un dispositivo Android a bloquear su pantalla inmediatamente simulando la expiración del tiempo de espera de la pantalla. Es útil para garantizar la seguridad del dispositivo en situaciones que requieren un bloqueo instantáneo. **Navega al dispositivo** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), navega a cualquiera de tus dispositivos y haz clic en el botón **Acción** 1. **Selecciona Bloquear** En el menú desplegable, selecciona **Bloquear** 2. ![action lock](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/b39b8524-f8f6-4616-9606-b2f440c71793.png) Aparecerá una ventana modal pidiéndote que introduzcas la **Duración** en segundos. Esto establece cuánto tiempo permanecerá activo el comando. Expirará si el dispositivo no ejecuta el comando dentro de este tiempo. No hay límite máximo para la duración. ### Restablecer contraseña **Disponible para dispositivos Totalmente administrados**. Restablecer la contraseña es útil cuando un usuario la ha olvidado, cuando el dispositivo cambia de usuario, si hay sospechas de acceso no autorizado, o cuando se aplican nuevas políticas de seguridad. También se recomienda para dispositivos perdidos o robados para evitar el acceso no autorizado y proteger la información sensible. **Navega al dispositivo y haz clic en el botón Acción** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), navega a cualquiera de tus dispositivos y haz clic en el botón **Acción** 1. **Selecciona Restablecer contraseña** En el menú desplegable, selecciona **Restablecer contraseña** 2. ![action reset password](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/71e3ab2d-7daa-4a95-b385-ab749e009df1.png) Una ventana modal te pedirá que especifiques el parámetro **Duración** en segundos. Esto define cuánto tiempo permanece válido el comando; si el dispositivo no ejecuta el comando dentro de este tiempo, expirará. No hay límite máximo de duración. Puedes configurar ajustes adicionales para mejorar la seguridad y el control después de un restablecimiento de contraseña: - **No permitas que otros administradores vuelvan a cambiar la contraseña hasta que el usuario la haya introducido:** Esto asegura que ningún otro administrador pueda modificar la contraseña una vez que se ha restablecido, forzando al usuario a introducir la nueva contraseña antes de que se permitan más cambios. - **No pedir credenciales de usuario en el arranque del dispositivo**: Permite que el dispositivo se inicie sin pedir inmediatamente al usuario que introduzca la nueva contraseña después de un reinicio. - **Bloquear el dispositivo después de restablecer la contraseña**: Bloquea automáticamente el dispositivo después del restablecimiento de la contraseña, aumentando la seguridad hasta que el usuario introduzca la nueva contraseña. - **Establecer nueva contraseña**: Te permite especificar directamente la nueva contraseña que se aplicará al dispositivo. Para dispositivos Android 14, la nueva contraseña debe tener al menos 6 caracteres si es numérica; de lo contrario, el comando fallará con un error de `Invalid value`. :::info Si no habilitas la opción **Establecer nueva contraseña**, el comando, por defecto, **deshabilitará la contraseña del dispositivo**. ::: :::warning **En un dispositivo ya bloqueado con una contraseña desconocida, este comando no puede funcionar.** Desde Android 8, el método antiguo de restablecimiento lanza una excepción de seguridad, así que el DPC tiene que usar un token de restablecimiento que haya sido **provisionado previamente** y **activado**, entendiendo por activado que el usuario desbloqueó el dispositivo al menos una vez tras la provisión. Los tokens sin activar se almacenan solo en memoria y se pierden al reiniciar. Es una limitación de la plataforma que afecta por igual a cualquier MDM, no algo propio de Applivery. En esos casos, comprueba si el bloqueo procede de Find My Device de Google, que permite establecer un PIN nuevo en remoto. ::: #### Solución de problemas: el comando Restablecer contraseña falla al instante Si envías un comando Restablecer contraseña y falla casi de inmediato — aunque el dispositivo aparece como conectado a Wi-Fi — es muy probable que el dispositivo esté en estado **Before First Unlock (BFU)**. **¿Qué es el estado BFU?** Cuando `encryptionPolicy` está configurado como `ENABLED_WITH_PASSWORD` en tu política, el dispositivo requiere que el usuario introduzca su PIN al arrancar antes de que se pueda descifrar el almacenamiento. Si el dispositivo se reinició y el usuario no puede introducir su PIN, el dispositivo queda bloqueado en estado BFU. En estado BFU, todo el espacio de usuario de Android está congelado — incluido Android Device Policy, el componente responsable de comunicarse con Applivery. El dispositivo puede ver la red Wi-Fi a nivel del sistema operativo (por eso aparece como conectado en el panel), pero la capa MDM está completamente inactiva: no hay ningún proceso en ejecución que pueda recibir ni ejecutar comandos desde Applivery. Por eso el comando Restablecer contraseña falla al instante — el dispositivo nunca lo recibe. **Solución** No existe ninguna solución remota en este escenario. Es necesario acceder físicamente al dispositivo: - **Introducir el PIN físicamente**: si existe alguna posibilidad de que el usuario recuerde su PIN, esta es la solución más sencilla. - **Restablecimiento de fábrica desde el modo de recuperación**: mantén pulsada la combinación de botones físicos al arrancar para acceder al modo de recuperación y realiza un restablecimiento de fábrica. El dispositivo perderá todos los datos locales, pero volverá a ser gestionable. **Prevención** Para evitar este escenario en el futuro, configura `encryptionPolicy` como `ENABLED_WITHOUT_PASSWORD` en tu política de Android. Esto sigue aplicando el cifrado completo del dispositivo, pero no requiere el PIN al arrancar — lo que significa que Android Device Policy se inicia con normalidad tras un reinicio y los comandos remotos como Restablecer contraseña funcionarán correctamente. :::info Para una explicación completa de todos los valores de `encryptionPolicy` y cómo elegir entre ellos, consulta [Política de encriptación](https://docs.applivery.com/es/device-management/android/policies/encryption-policy/). ::: ### Reiniciar **Disponible para dispositivos Totalmente administrados**. Enviar un comando de reinicio es útil en varias situaciones clave. Ayuda a resolver problemas de rendimiento liberando RAM, aplica actualizaciones del sistema que requieren un reinicio para surtir efecto, y corrige errores menores como apps que no responden o conflictos de controladores. También se recomienda cuando un dispositivo ha estado funcionando durante períodos prolongados sin reiniciar, lo que puede afectar la estabilidad. Además, cuando se aplican nuevas configuraciones o políticas de seguridad a través de Applivery, puede ser necesario un reinicio para que estos cambios surtan efecto. **Navega al dispositivo** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), navega a cualquiera de tus dispositivos y haz clic en el botón **Acción** 1. **Selecciona Reiniciar** En el menú desplegable, selecciona **Reiniciar** 2. ![action reboot](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/4502dfc1-300b-4211-af3d-56930cdd539f.png) Una ventana modal te pedirá que especifiques el parámetro **Duración** en segundos. Esto define cuánto tiempo permanece válido el comando; si el dispositivo no ejecuta el comando dentro de este tiempo, expirará. No hay límite máximo de duración. ### eSIM Estos comandos proporcionan la capacidad de añadir o eliminar perfiles eSIM de forma remota en **dispositivos Android compatibles** (Android 15 y superiores), eliminando la dependencia de las tarjetas SIM físicas. Esto simplifica la configuración y el mantenimiento de los dispositivos, permitiendo una implementación más rápida y un mejor control sobre el acceso a la red móvil, todo gestionado de forma remota desde un panel centralizado. **Navega al dispositivo** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), navega a cualquiera de tus dispositivos y haz clic en el botón **Acción** 1. **Selecciona Añadir eSIM o Eliminar eSIM** En el menú desplegable, selecciona **Añadir eSim** 2 o **Eliminar eSim** 3. ![actions esim](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/7b5cbbda-cb98-4fb2-ab7e-bd7340457aab.png) #### Añadir eSIM Cuando seleccionas el comando Add eSIM, una ventana modal te pedirá que especifiques configuraciones adicionales, como el **código de activación de la eSIM** y el **estado de activación**, así como el parámetro **Duración** descrito en comandos anteriores. #### Eliminar eSIM Cuando seleccionas el comando Eliminar eSIM, una ventana modal te pedirá que especifiques configuraciones adicionales, como el **ICCID de la eSIM** a eliminar, así como el parámetro **Duración** descrito en comandos anteriores. #### Solicitar información (EID del dispositivo) **Disponible para dispositivos personales con perfil de trabajo** (Android 13 o superior). Este comando obtiene el **EID** (identificador eUICC) del dispositivo — el identificador único del chip eSIM que las operadoras móviles necesitan para aprovisionar un perfil eSIM. Como estos dispositivos son propiedad del usuario, este debe aprobar compartir la información antes de que pueda devolverse. Selecciona **Solicitar información** en el menú **Acción**. El comando informa de uno de estos estados: - **Succeeded**: la información del dispositivo se entregó y se devuelve el EID (uno por cada chip eUICC). - **Pending user action**: el usuario todavía no ha completado la aprobación requerida. - **User declined**: el usuario rechazó compartir la información del dispositivo. - **Unsupported**: la información solicitada no es compatible — por ejemplo, el dispositivo no admite eSIM. :::info Todos estos comandos anteriores también se pueden ejecutar desde la pestaña **Comandos** del dispositivo. ::: ### Deshabilitar **Disponible para todos los modos de gestión**, este comando te permite deshabilitar de forma remota un dispositivo Android bloqueándolo y deshabilitando todas las apps y funciones. Mientras está deshabilitado, el dispositivo se vuelve inaccesible para el uso regular, lo que ayuda a prevenir el acceso no autorizado y a mejorar la seguridad en casos de pérdida, robo o aplicación de políticas. Además, se puede utilizar para restringir el uso del dispositivo fuera del horario laboral programado. El dispositivo se puede volver a habilitar más tarde para restaurar la funcionalidad completa. **Navega al dispositivo** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), navega a cualquiera de tus dispositivos y haz clic en el botón **Acción** 1. **Selecciona Deshabilitar** En el menú desplegable, selecciona **Deshabilitar** 2. ![action disable](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/02eb930e-c7a7-4e3f-8a29-074233c47d26.png) ### Renunciar a la propiedad **Disponible para dispositivos COPE (Company-Owned, Personally Enabled)**, este comando te permite eliminar de forma remota el Perfil de trabajo y todas las políticas de gestión corporativa de un dispositivo. Efectivamente, devuelve el dispositivo a un estado de uso personal mientras conserva cualquier dato, apps y configuraciones asociadas con el o los perfiles personales del usuario. Esta acción es particularmente útil en escenarios como la desvinculación de empleados, la transferencia de la propiedad de un dispositivo o la reutilización de dispositivos para uso no corporativo. Garantiza que los datos corporativos se borren de forma segura, sin afectar el contenido personal del usuario. Una vez ejecutado, el dispositivo ya no será gestionado por Applivery y se comportará como un dispositivo Android estándar no gestionado. **Navega a la pestaña de Comandos** Ve a la pestaña de **Comandos** 1 de cualquiera de tus dispositivos Android COPE. **Selecciona Renunciar a la propiedad** Selecciona **Renunciar a la propiedad** 2. ![action relinquish ownership](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/947ba4e2-82bb-4ec0-bb3b-b2f468deec22.png) Una ventana modal te pedirá que especifiques el parámetro **Duración** en segundos. Esto define cuánto tiempo permanece válido el comando; si el dispositivo no ejecuta el comando dentro de este tiempo, expirará. No hay límite máximo de duración. :::info Todos los comandos mencionados anteriormente también se pueden ejecutar desde la sección **Zona de peligro** dentro de la pestaña de **Ajustes**, dependiendo del modo de gestión del dispositivo. ::: ### Soporte para dispositivos AOSP En los dispositivos AOSP, los comandos remotos se envían a través de **Pushy** (no AMAPI) y son ejecutados por el DPC de Applivery contra las API nativas de Android. Los comandos se confirman al recibirse y de nuevo al completarse, por lo que el panel de Applivery siempre muestra el ciclo de vida completo. Los siguientes comandos son compatibles con AOSP:

Comando

Efecto

Bloquear dispositivo

Bloquea el dispositivo inmediatamente.

Restablecer contraseña

Restablece la contraseña de la pantalla de bloqueo. Subopciones: Don’t ask for credentials on boot, Lock after reset, Set new password.

Reiniciar

Reinicia el dispositivo.

Brrar datos de una app

Borra datos y caché de uno o más paquetes gestionados.

Desenrolar

Elimina el DPC de Applivery como Device Owner y borra el estado almacenado del dispositivo.

Los comandos son accesibles desde la página de detalles del dispositivo en el menú **Acción** o en la pestaña de **Comandos**. :::warning La gestión de eSIM, el modo perdido y la renuncia a la propiedad son comandos basados en AMAPI y **no están disponibles en dispositivos AOSP**. ::: --- ## Limitaciones de permisos COPE Source: https://docs.applivery.com/es/device-management/android/cope-permission-limits/ Description: Los dispositivos Android COPE separan perfiles de trabajo y personal. Esta guía detalla las limitaciones de permisos en EMM. TL;DR: Los dispositivos Android COPE limitan los permisos a Perfil de trabajo, protegiendo el perfil personal del control corporativo. Answers: ¿Cuáles son las limitaciones de los dispositivos COPE? · ¿Cómo funcionan los permisos en Android COPE? · ¿Se puede bloquear el restablecimiento de fábrica en COPE? · ¿Qué es un Perfil de trabajo? · Cómo gestionar permisos en un Perfil de trabajo Key topics: Gestión de permisos Android COPE, Limitaciones del Perfil de trabajo, Privacidad en EMM, Políticas de dispositivos, Android, COPE, EMM, Applivery, Perfil de trabajo, Google Play, Bluetooth En la moderna Gestión de Movilidad Empresarial (EMM), el modelo COPE (propiedad corporativa, uso personal) se ha convertido en una opción preferida para las organizaciones que desean la propiedad total del dispositivo, al mismo tiempo que permiten el uso personal. Este escenario de uso mixto proporciona flexibilidad a los empleados, pero también introduce limitaciones técnicas que afectan directamente la forma en que se comportan las propiedades gestionadas y los permisos a nivel de app en los dispositivos Android COPE. Debido a que la inscripción COPE separa el dispositivo en dos espacios distintos —un perfil de trabajo totalmente administrado y un perfil personal fuera del control corporativo—, ciertas políticas, restricciones y otorgamientos de permisos simplemente **no pueden aplicarse a nivel de dispositivo**. Esto difiere significativamente de las implementaciones totalmente administradas, dedicadas o gestionadas por el trabajo, donde la empresa tiene un control administrativo más amplio. ### Limitaciones clave #### Los permisos se aplican solo al perfil de trabajo Cualquier permiso otorgado, denegado o requerido a través de propiedades gestionadas afecta solo a las apps dentro del perfil de trabajo. Los administradores no pueden imponer permisos en las apps del perfil personal. #### Los permisos sensibles no pueden ser preotorgados por TI Incluso dentro del perfil de trabajo, permisos como la cámara, la ubicación o el micrófono no siempre pueden ser auto-otorgados. El usuario debe aprobarlos manualmente. #### El restablecimiento de fábrica no puede ser bloqueado Los usuarios conservan la capacidad de restablecer todo el dispositivo a la configuración de fábrica. En modo COPE, las soluciones EMM —incluido Applivery— no pueden deshabilitar ni restringir esta opción. #### El control de ubicación es limitado Los administradores pueden solicitar o restringir el acceso a la ubicación **solo dentro del perfil de trabajo**. No pueden forzar el seguimiento de ubicación en todo el dispositivo ni imponer un acceso continuo a la ubicación. Consulta [Gestión de la ubicación en dispositivos Android](https://docs.applivery.com/es/device-management/android/policies/location-management/) para ver cómo cambia el control de ubicación según el modo de gestión. #### Los permisos de llamadas telefónicas y SMS no son gestionables Las llamadas y los SMS pertenecen al perfil personal por diseño; por lo tanto, los permisos relacionados no pueden ser restringidos, otorgados o controlados desde el perfil de trabajo. #### Las restricciones globales a nivel de dispositivo no pueden ser impuestas Las políticas relacionadas con los requisitos de bloqueo de pantalla, la desactivación de la cámara, el control de Bluetooth o la modificación de la configuración de red del sistema se aplican solo al perfil de trabajo y no afectan el uso personal. #### Los permisos sensibles del perfil personal no pueden ser controlados El acceso a contactos, registros de llamadas, SMS, almacenamiento compartido y otros recursos sensibles a la privacidad no puede ser otorgado o denegado automáticamente por el EMM —ni en el perfil personal ni, en algunos casos, incluso dentro del perfil de trabajo. ### Tabla resumen

Permiso

¿Puede ser preotorgado o bloqueado?

ACCESS_FINE_LOCATION / ACCESS_COARSE_LOCATION

❌

CAMERA

❌

RECORD_AUDIO

❌

READ_EXTERNAL_STORAGE / WRITE_EXTERNAL_STORAGE

❌

READ_CONTACTS

❌

READ_CALL_LOG / WRITE_CALL_LOG / PROCESS_OUTGOING_CALLS

❌

READ_SMS / SEND_SMS / RECEIVE_SMS / READ_MMS

❌

READ_CALENDAR / WRITE_CALENDAR

❌

BODY_SENSORS / ACTIVITY_RECOGNITION

❌

Bloquear restablecimiento de fábrica

❌

Estas limitaciones surgen del enfoque de privacidad por diseño de Android para la inscripción COPE. El sistema operativo garantiza intencionadamente que los datos personales, la actividad y las capacidades a nivel de sistema permanezcan bajo el control del usuario, impidiendo que los administradores configuren o restrinjan silenciosamente ciertos comportamientos, incluso en hardware propiedad de la empresa. En los dispositivos COPE gestionados a través de Applivery, las políticas y los permisos se aplican de forma completa y exclusiva al perfil de trabajo, mientras que el perfil personal permanece protegido del control administrativo. Esto también significa que ciertas acciones —como bloquear los restablecimientos de fábrica, imponer restricciones a nivel de dispositivo o otorgar automáticamente permisos sensibles a través de propiedades gestionadas— no son técnicamente posibles. Comprender estas limitaciones es esencial al diseñar políticas corporativas, asegurando que las estrategias de gestión estén alineadas con las capacidades reales de COPE y las protecciones de privacidad integradas de Android. --- ## Inscripción de dispositivos Source: https://docs.applivery.com/es/device-management/android/enrollment/ Description: Inscribe dispositivos Android en Applivery. Métodos disponibles: manual, Inscripción inteligente, Zero-Touch y Samsung Knox Mobile Enrollment. TL;DR: Inscribe fácilmente tus dispositivos Android en Applivery para una gestión segura de dispositivos móviles. Answers: ¿Cómo inscribir un dispositivo Android en Applivery? · ¿Cuáles son los pasos para la inscripción Android en Applivery? · ¿Cómo gestionar dispositivos Android con Applivery? · ¿Cuál es el proceso de inscripción Android de Applivery? · ¿Cómo configurar dispositivos Android para MDM con Applivery? · ¿Qué beneficios ofrece la inscripción de dispositivos Android en Applivery? · ¿Cómo solucionar problemas de inscripción Android en Applivery? Key topics: Inscripción de dispositivos Android, MDM de Applivery, Gestión de dispositivos móviles, Android, Applivery, MDM Inscribir un dispositivo Android en Applivery lo registra en la plataforma MDM y aplica automáticamente las políticas, apps y configuración de tu organización. Applivery es compatible con múltiples métodos de inscripción de Android Enterprise para cubrir escenarios tanto de dispositivos corporativos como BYOD. Elige el método de inscripción adecuado para tu implementación: código QR, Zero-Touch, Inscripción inteligente o COPE. --- ## Inscripción manual Source: https://docs.applivery.com/es/device-management/android/enrollment/manual-enrollment/ Description: Inscribe dispositivos Android en Applivery MDM mediante código QR o alfanumérico. Ideal para flotas pequeñas o configuraciones puntuales sin Zero-Touch. TL;DR: Inscribe dispositivos Android en Applivery MDM con métodos manuales, Smart Enrollments o Zero-Touch, y comprende las opciones de gestión disponibles. Answers: ¿Cómo inscribir un dispositivo Android en Applivery? · ¿Cuáles son los métodos de inscripción de Android Enterprise? · ¿Cómo configurar un Perfil de trabajo en Android? · ¿Cómo inscribir un dispositivo Android Totalmente administrado? · ¿Qué es la inscripción Android Zero-Touch? Key topics: Métodos de inscripción de Android, Opciones de gestión de Android Enterprise, Proceso de inscripción manual, Configuración de Perfil de trabajo, Configuración de dispositivo Totalmente administrado, Android Enterprise, Applivery, Google Workspace, Google Admin Console, App Android Device Policy Una vez que tengas tu [Android Enterprise](https://docs.applivery.com/es/device-management/android/get-started/) configurado y hayas [establecido tu primera política de Android](https://docs.applivery.com/es/device-management/general-settings/create-policies/), puedes empezar a inscribir tus dispositivos Android. Echemos un vistazo. ### Opciones de inscripción Applivery soporta múltiples formas de inscribir tus dispositivos Android: - Inscripción manual a través de un código QR o código alfanumérico. - Inscripciones automáticas a través de [Inscripciones inteligentes](https://docs.applivery.com/es/device-management/android/enrollment/smart-enrollment/). - [Android Zero-Touch](https://docs.applivery.com/es/device-management/android/enrollment/zero-touch-enrollment/), diseñado para la inscripción automatizada. ### Opciones de gestión Como parte de Android Enterprise, existen varias formas de gestionar tus dispositivos, dependiendo del caso de uso: - **Dispositivos propiedad de la empresa:** También conocidos como **Totalmente administrado**, este es el modo de funcionamiento que proporciona control total sobre el dispositivo. Requiere un restablecimiento de fábrica (borrado) del dispositivo para iniciar una inscripción limpia. - **Propiedad de la empresa, habilitado para uso personal**: Son dispositivos propiedad de la empresa que los empleados pueden usar tanto para fines personales como laborales. - **Dispositivos dedicados**: Dispositivos propiedad de la empresa asignados a un empleado o tarea específica, utilizados únicamente para fines laborales y Totalmente administrado por la organización. - **Bring Your Own Device (BYOD):** También conocido como **Perfil de trabajo**, se refiere a dispositivos personales que los empleados utilizan para el trabajo. El espacio corporativo estará completamente cifrado y tendrás control total sobre él. Los dispositivos pueden inscribirse y desinscribirse del Perfil de trabajo sin requerir un restablecimiento de fábrica. ### Inscripción manual (código o QR) :::warning Si [Google Workspace](https://docs.applivery.com/es/device-management/integrations/sso/google-workspace/) está configurado como tu IDP y experimentas algún problema durante el proceso de inscripción, deberás revisar tu configuración en la [Google Admin Console](https://admin.google.com/). ::: Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), navega a **Dispositivos** y haz clic en **\+ Inscribir dispositivo**. Rellena el formulario de la siguiente manera: **Configurar ajustes de inscripción** - **Plataforma:** Asegúrate de elegir **Android** como Plataforma. - **Modo de gestión:** Elige entre Totalmente administrado y Perfil de trabajo, como se describió anteriormente. - **Empleado del dispositivo:** Usuario propietario del dispositivo. Puedes crear un nuevo empleado introduciendo la dirección de correo electrónico. - **Política:** Elige la política a aplicar al dispositivo. Puedes hacerlo en Políticas si aún no la has creado. Alternativamente, puedes crear una nueva política aquí y configurarla más tarde. - **Etiquetas**: Define etiquetas para organizar, agrupar y filtrar dispositivos de manera eficiente. - **Nombre de visualización (opcional):** Un nombre amigable para identificar fácilmente el dispositivo entre los demás. - **Caduca después de:** El tiempo de expiración del token de inscripción que se generará. - **Enviar correo electrónico de instrucciones al empleado (opcional):** Elige si deseas enviar una notificación al usuario, incluyendo las instrucciones de inscripción que variarán según el modo de inscripción. ![android manual enrollment](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/e19274d1-2deb-4547-8cf4-6e6c68eb5667.png) :::info También puedes crear [inscripciones masivas](https://docs.applivery.com/es/device-management/general-settings/bulk-enrollment/). Para ello, simplemente abre el menú desplegable junto a **\+ Inscribir dispositivo** y selecciona **\+ Inscribir múltiples dispositivos**. Se creará una inscripción para cada empleado del dispositivo seleccionado. Si no se encuentra el correo electrónico de un empleado del dispositivo, se creará automáticamente un nuevo empleado del dispositivo. ::: **Inscribir el dispositivo** Una vez creada la inscripción, se añadirá a la lista de dispositivos. Haz clic en ella para mostrar los detalles e instrucciones de inscripción. ![android manual enrollment instructions](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/190b3f10-aeeb-4a78-bbc4-9e161064ec48.png) :::warning Las instrucciones variarán según el modo de inscripción y el tipo de dispositivo. Sin embargo, en la mayoría de los casos, necesitarás usar un código QR para inscribir el dispositivo. En resumen, la inscripción requiere los siguientes pasos. ::: **Totalmente administrado** 1. Enciende tu dispositivo borrado o restablecido de fábrica. 1. **Opción 1**: En la pantalla de Bienvenida, selecciona tu idioma. 2. **Opción 2**: Toca 6 veces sobre el mensaje de **Bienvenida** hasta acceder a la opción de lector de QR. 2. Conéctate a tu **Wi-Fi** y luego elige **SIGUIENTE**. 3. Acepta los **Términos y condiciones de Google** y luego elige **SIGUIENTE**. 4. En la pantalla de inicio de sesión de Google, introduce **afw#setup** en lugar de una cuenta de Gmail y luego elige **SIGUIENTE**. 5. En la pantalla Inscribir este dispositivo, permite que tu dispositivo **escanee un código QR o elige introducir el código de inscripción manualmente**. 6. Por último, sigue cuidadosamente todos los pasos en la pantalla de tu dispositivo para completar la inscripción. **Perfil de trabajo** 1. Ve a **Ajustes > Google > Configurar Perfil de trabajo**. Alternativamente, puedes abrir una URL proporcionada o escanear un código QR. 2. Espera a que se abra la **App Android Device Policy**. En caso de que aún no esté instalada en tu dispositivo, espera a la descarga/instalación de la App Android Device Policy en tu dispositivo. Se abrirá automáticamente una vez instalada. 3. En algunas versiones de Android, se te pedirá que introduzcas un código de inscripción o **escanees un código QR** para completar la configuración del Perfil de trabajo. 4. Por último, sigue cuidadosamente todos los pasos en la pantalla de tu dispositivo para completar la inscripción. ![manual enrollment instructions for Work Profile](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/948e0225-e309-49c4-9189-3f90096c3910.png) --- ## Inscripción con Samsung KME Source: https://docs.applivery.com/es/device-management/android/enrollment/samsung-knox-mobile-enrollment/ Description: Integra Samsung Knox Mobile Enrollment (KME) con Applivery para el aprovisionamiento y la inscripción automatizada de dispositivos a escala. TL;DR: Automatiza la inscripción de dispositivos Samsung con KME y inscripciones inteligentes de Applivery, configurando un perfil KME con JSON simplificado. Answers: ¿Qué es Samsung Knox Mobile Enrollment (KME)? · ¿Cuáles son los beneficios de usar KME con Applivery? · ¿Qué modos de inscripción soporta KME con Applivery? · ¿Dónde puedo encontrar la configuración JSON para KME? · ¿Cómo configurar un perfil KME en el portal de Samsung? · ¿Cómo asignar un perfil KME a dispositivos Samsung? Key topics: Gestión de dispositivos móviles, Inscripción Android, Samsung Knox Mobile Enrollment, Samsung, Applivery, Android [Samsung Knox Mobile Enrollment](https://www.samsungknox.com/en/solutions/it-solutions/knox-mobile-enrollment) (KME) es un potente marco de incorporación que permite a las organizaciones aprovisionar dispositivos Samsung de forma automática y a escala. Garantiza que cada dispositivo corporativo —nuevo o recién restablecido— se configure con los ajustes de gestión correctos tan pronto como se conecta a internet. Cuando se combina con las [Inscripciones inteligentes de Applivery](https://docs.applivery.com/es/device-management/android/enrollment/smart-enrollment/), KME permite un flujo de aprovisionamiento totalmente automatizado, seguro y sin intervención, lo que hace que la implementación de dispositivos sea más rápida, consistente y libre de errores. **Obtener la configuración JSON** El primer paso es recopilar la configuración JSON necesaria para Samsung KME. Este JSON contiene los parámetros de inscripción requeridos para que Applivery configure el dispositivo automáticamente durante el aprovisionamiento. Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a **Automatización** 1, selecciona **Inscripciones inteligentes** 2 y elige **Android** como plataforma en el menú de la izquierda. ![create android Smart Enrollment](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/b48047d9-9cc3-408f-b326-5c419862a01f.png) :::info Samsung Knox Mobile Enrollment soporta los modos de inscripción **Propietadio del dispositivo**, **dispositivo dedicado** y **COPE**. ::: :::info Puedes obtener más información sobre las inscripciones inteligentes de Android siguiendo [este enlace](https://docs.applivery.com/es/device-management/android/enrollment/smart-enrollment/). ::: En inscripción inteligente que quieras usar, haz clic en el **menú de tres puntos** 3 en el lado derecho y selecciona **Zero-touch**. A continuación, selecciona el botón **Copiar JSON** 4 para copiar el bloque JSON. ![Zero-touch json](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/1fa5585e-0120-4b79-9e21-0ba1fba67161.png) ##### Validar la configuración JSON Una vez que hayas copiado el código JSON, debes validar su estructura y prepararlo para su uso con KME. Abre un validador JSON, como [jsonlint](https://jsonlint.com/), y pega el JSON copiado en él. Valida la estructura y asegúrate de que no haya errores de sintaxis. Si aparecen errores, revisa el JSON en busca de comas, comillas o corchetes que falten. ##### Eliminar secciones JSON no requeridas Samsung KME requiere una versión simplificada del JSON. Algunas secciones generadas por las inscripciones inteligentes de Applivery deben eliminarse antes de la carga. - Revisa el código JSON validado. - Identifica los elementos no requeridos para la integración de KME. - Elimina cuidadosamente las secciones innecesarias sin alterar la estructura. El JSON resultante debería ser similar al ejemplo proporcionado: ```json { "com.google.android.apps.work.clouddpc.EXTRA_ENROLLMENT_TOKEN": "YOUR_TOKEN_HERE" } ``` **Configurar el portal KME** ##### Crear un nuevo perfil KME Ahora crearás un [perfil Samsung KME](https://signin.samsungknox.com/auth?redirectUrl=https://signin.samsungknox.com/) que incluye la configuración de Applivery. Primero, navega a la sección **Perfiles** 5, luego haz clic en **Crear perfil** 6 en la esquina superior derecha. ![kme-create-profile | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/53e44ccb-5ca5-4fef-859c-f354b0fc1f8d.png "kme-create-profile | Applivery") Nombra el perfil según el tipo de implementación (DO, COPE, Dedicated, etc.) y selecciona la casilla **EMM** y, opcionalmente, **Knox Service Plugin**. Luego, haz clic en **Siguiente**. ![kme-profile | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/3f54665b-6289-4601-aa1b-9d7fb0fab043.png "kme-profile | Applivery") Rellena los campos **Nombre de la empresa**, **Correo electrónico de soporte** y **Número de teléfono de soporte**. Luego, en **Información de EMM**, selecciona **Otro** en el desplegable. Para **Enlace al APK del agente**, usa `https://play.google.com/managed/downloadManagingApp?identifier=setup`. Luego haz clic en **Siguiente**. ![kme-emm-info | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/8524c162-94ab-43bf-aa37-cc4424faf775.png "kme-emm-info | Applivery") En la página siguiente, localiza la sección **DPC Extras** y pega el JSON limpio directamente en el campo. Completa cualquier configuración adicional que tu organización requiera, incluyendo: - **Apps del sistema** para el perfil corporativo. - Configuración de las **pantallas de inscripción**. - **Acuerdo legal** (opcional). Una vez completado, haz clic en **Siguiente**. ![dpc-extras | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/6ed3403b-f141-4e97-a4b7-ca9dab4d9978.png "dpc-extras | Applivery") ##### Asignar el perfil a los dispositivos Verifica que todas las configuraciones —incluido el JSON de Applivery— se hayan añadido correctamente, luego haz clic en **Crear y asignar** para guardar el perfil. Finalmente, asigna tu nuevo perfil a los dispositivos Samsung que deseas gestionar. Selecciona los dispositivos que deseas aprovisionar, elige el perfil que creaste y asígnalo, y confirma la asignación para aplicar la configuración. ![assign-device | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/978dfb74-6d7f-4af9-9de0-681fe97939ad.png "assign-device | Applivery") Una vez asignado, cualquier dispositivo que sea **restablecido de fábrica** o **encendido por primera vez** activará automáticamente Samsung KME tan pronto como se conecte a internet, iniciando una inscripción de Applivery totalmente automatizada. ¡Tu flujo de trabajo de aprovisionamiento KME ya está listo para su implementación! --- ## Inscripciones inteligentes Source: https://docs.applivery.com/es/device-management/android/enrollment/smart-enrollment/ Description: Automatiza la inscripción de dispositivos Android con inscripciones inteligentes. Define reglas y asigna políticas según datos de usuario o dispositivo. TL;DR: Las inscripciones inteligentes para Android automatizan la inscripción de dispositivos y la asignación de políticas según reglas y condiciones predefinidas, permitiendo experiencias Zero-Touch. Answers: ¿Qué son las inscripciones inteligentes? · ¿Para qué se pueden usar las inscripciones inteligentes? · ¿Cómo creo una inscripción inteligente? · ¿Qué modos de gestión puedo especificar durante una inscripción inteligente? · ¿Qué son los Campos Auxiliares en las inscripciones inteligentes? · ¿Cómo limito la inscripción según la información de usuario o dispositivo? · ¿Cómo asigno una inscripción inteligente a un dispositivo? · ¿Para qué sirve la opción 'Auto-continuar'? Key topics: Configuración de inscripción inteligente, Aplicación de condiciones y reglas, Despliegue de inscripciones inteligentes, Campos auxiliares, Android, MDM, SSO, IMEI, Serial Number, Applivery Si alguna vez has soñado con automatizar el 100% del proceso de inscripción de dispositivos y la asignación condicional de políticas basada en datos de usuario (nombre, correo electrónico, Grupos de Usuarios) o datos del dispositivo (IMEI, Serial Number, etc.), las **inscripciones inteligentes** son la herramienta que estabas buscando. ### Introducción Las inscripciones inteligentes son la forma más eficiente de gestionar la inscripción de dispositivos de manera desatendida, ya que te permitirán **definir un conjunto de reglas y condiciones que deben cumplirse para que un dispositivo sea inscrito** y, además, te permitirán **asignar políticas condicionalmente** basadas en estos conjuntos de reglas. Las inscripciones inteligentes son útiles para: - Limitar la inscripción de dispositivos: - Basada en la autenticación de usuario a través de [integraciones SSO](https://docs.applivery.com/es/platform/authentication/sso/) (Grupos de Usuarios o patrones de correo electrónico). - Basada en la información del dispositivo (IMEI, número de serie). - Asignar diferentes políticas condicionalmente basadas en reglas. - Automatizar inscripciones Android para habilitar experiencias Zero-Touch desatendidas. ### Configuración de inscripciones inteligentes Comencemos a configurar tu primera inscripción inteligente. Primero dirígete a **Automatización** 1, selecciona **Inscripciones inteligentes** 2 y elige **Android** 3 como plataforma en el menú de la izquierda. Luego haz clic en el botón **\+ Crear inscripción inteligente** 4. ![create android Smart Enrollment](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/53b49e4c-29d7-4f10-8fac-4b191c42f881.png) **Configurar inscripciones inteligentes** 1. **Nombre:** Elige un nombre descriptivo para tu nueva inscripción inteligente. 2. **Descripción:** Elige una descripción descriptiva para tu nueva Inscripción inteligente. 3. **Modo de gestión**: Especifica el método de gestión de dispositivos que se aplicará durante este proceso de inscripción inteligente. 4. **Proveedores de acceso**: Se mostrarán los proveedores SSO configurados a nivel de Workspace. Sin embargo, también puedes configurar la integración específica a nivel de inscripción inteligente haciendo clic en **Anular**. 5. **Política:** Elige la política que se aplicará al dispositivo desde la biblioteca de políticas. Si aún no tienes ninguna política predefinida, simplemente escribe un nombre y se creará una nueva política vacía. 6. **Segmento destino**: Elige el [Segmento](https://docs.applivery.com/es/device-management/general-settings/segments/) al que se asignarán los dispositivos inscritos. 7. **Etiquetas**: Se utilizan para filtrar y agrupar. :::info Cuando el proveedor de inicio de sesión está configurado como **Anónimo**, puedes habilitar la opción **Continuar automáticamente**, que permite a los dispositivos continuar la inscripción automáticamente cuando no se requiere interacción del usuario. ::: ![Smart Enrollment form](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/033d2a9c-7f45-4f77-bf7a-23a81c92386b.png) **Configurar Campos Auxiliares** 8. **Campos auxiliares**: Al rellenar este formulario, podrás configurar etiquetas de dispositivo durante la inscripción. ![auxiliary fields](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/43dd8611-201d-483b-8028-74ce07e89da8.png) Mediante el uso de campos auxiliares, puedes definir una estructura de inscripción flexible que se adapte a las características organizativas de tu empresa. Esto permite a los usuarios inscribir sus dispositivos según requisitos específicos, al tiempo que permite a los administradores aplicar diferentes configuraciones basadas en estas selecciones. Estos campos auxiliares se pueden utilizar para generar etiquetas de dispositivo durante la inscripción, que funcionan como parámetros condicionales. Puedes crear tantos campos como necesites y luego asociarlos con las políticas correspondientes para cada escenario. Después de continuar, se presentarán al usuario los menús desplegables definidos en los campos auxiliares, según los requisitos de la organización. Una vez seleccionados los campos requeridos, el usuario se autenticará utilizando el método habilitado por la organización, y se aplicarán las políticas adecuadas según las etiquetas asignadas. Luego, el dispositivo completará la inscripción y aplicará las configuraciones en segundo plano. **Configurar Patrón de Nombre de Visualización** 9. **Patrón de nombre de visualización**: Asigna un nombre de visualización combinando propiedades del dispositivo. ![interpolation tags](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/aad8c3c4-1394-4e55-8a1d-0346d312d058.png) Si haces clic en **Guardar** en este punto, habrás terminado de configurar tu Inscripción inteligente básica y podrás empezar a inscribir dispositivos. **Aplicación de condiciones y reglas** Ahora que tienes tu Inscripción inteligente básica configurada, puedes añadir **Condiciones** 5 y **Reglas** 6 que la harán más inteligente. ![conditions and rules](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/8eb5b076-a8b7-4ecd-bb1e-bbf9fdf504c0.png) Utiliza la opción **Añadir condición** para habilitar límites de inscripción basados en información de usuario (como patrones de correo electrónico o grupos) e información del dispositivo (IMEI, número de serie y campos auxiliares). Puedes utilizar operadores condicionales para hacerlo tan complejo como necesites. ![conditions](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/2755c5b4-6889-4a69-8fbe-d66f8e0fbbf7.png) También puedes utilizar la opción **Añadir regla adicional** para crear grupos de condiciones, cada uno de ellos con una política objetivo. Como verás, cada grupo de condiciones también tendrá tantas **Condiciones** como necesites. ![rules](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ee6c2fae-6b0d-405b-bb53-e3812bd75497.png) Una vez hecho, haz clic en **Guardar**. **Despliegue de inscripciones inteligentes ** Para completar el proceso, deberás asignar inscripciones inteligentes a tus dispositivos Android. Simplemente haz clic en los tres puntos verticales junto a cualquiera de tus inscripciones inteligentes y selecciona **Ver instrucciones** 7. Esta acción te dará acceso al panel lateral de instrucciones, donde podrás seguir fácilmente los pasos proporcionados. ![view instructions](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ad76e252-677a-4fac-b20c-1a3b734f5827.png) ### Soporte para dispositivos AOSP Las inscripciones inteligentes son totalmente compatibles con los dispositivos AOSP y se configuran exactamente igual: mismos campos, mismos campos auxiliares, mismas condiciones y reglas, y los mismos pasos de despliegue descritos arriba. No hay una configuración aparte ni nada extra que activar. Para consultar la lista completa de lo que Applivery gestiona en hardware sin GMS, consulta [Android Open Source Project (AOSP)](https://docs.applivery.com/es/device-management/android/aosp/). --- ## Inscripción Zero-touch Source: https://docs.applivery.com/es/device-management/android/enrollment/zero-touch-enrollment/ Description: Configura la inscripción Zero-touch de Android en Applivery para el aprovisionamiento automático y masivo de dispositivos Android corporativos. TL;DR: La inscripción Zero-touch de Android automatiza la configuración y el despliegue de dispositivos, simplificando la gestión para las organizaciones. Answers: ¿Qué es la inscripción Zero-touch de Android? · ¿Cuáles son las ventajas de la inscripción Zero-touch de Android? · ¿Qué requisitos previos tiene la inscripción Zero-touch de Android? · ¿Está disponible la inscripción Zero-touch de Android para dispositivos AOSP? · ¿Cómo puedo obtener una cuenta del portal Zero-touch? · ¿Cómo integro Applivery con Android Zero-touch? · ¿Cómo obtengo el JSON para el campo DPC extras en Applivery? · ¿Cómo asigno una configuración a un dispositivo en el portal Zero-touch? Key topics: Configuración de la inscripción Zero-touch de Android, Integración de Applivery con Zero-touch, Configuración de dispositivos en el portal Zero-touch, Obtención del JSON para DPC extras, Asignación de configuraciones a dispositivos, Google, Android, Applivery, Android Device Policy :::warning La inscripción Zero-touch es un servicio de Google que requiere Google Mobile Services (GMS) y **no está disponible en dispositivos AOSP**. Para inscribir dispositivos AOSP, usa el aprovisionamiento con código QR. Consulta [Gestión de Android AOSP](https://docs.applivery.com/es/device-management/android/aosp/) para más detalles. ::: La inscripción Zero-touch de Android o el aprovisionamiento Zero-touch de Android (ZTP) es un método de inscripción de dispositivos proporcionado por Google que agiliza la inscripción y el despliegue sencillo de dispositivos Android propiedad de la organización de forma masiva. ### Ventajas de Zero-touch - Configuración única. - Facilita el despliegue de dispositivos empresariales a gran escala. - Permite a los revendedores añadir dispositivos al portal, simplificando el proceso de inscripción. - Los administradores pueden configurar el dispositivo con las apps y perfiles necesarios, y estos se aplican automáticamente al activar el dispositivo. ### Requisitos previos para Zero-touch - La inscripción Zero-touch de Android es compatible con dispositivos que ejecutan Android 9.0 o posterior, comprados a [revendedores asociados específicos](https://androidenterprisepartners.withgoogle.com/resellers/). - Necesitas una cuenta del portal Zero-touch, que puedes obtener contactando a tu revendedor. :::warning Se requiere una cuenta de Google (asociada a tu correo electrónico corporativo) para configurar el portal Zero-touch de Android. ::: #### Integra Applivery con Zero-touch **Vincula Zero-touch a Applivery** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io), dirígete a la sección de **Configuración** y selecciona **Android** **Zero-touch** 1 en el menú de la izquierda. Deberás vincular tu cuenta Zero-touch a Applivery y seguir los pasos en pantalla. ![Zero-touch-portal-1](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/6413e02d-a3a8-4507-b85a-65f6da126941.png "Zero-touch-portal-1 | Applivery") **Visualiza los dispositivos en el portal Zero-touch** Una vez que la integración se haya completado con éxito, solo tienes que hacer clic en **Visualizar dispositivos en el portal Zero-touch** 2. ![view Devices in the Zero-touch portal](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/190464dd-d5f5-4e27-ab89-77940eec3460.png) **Añade una nueva configuración** Se abrirá una nueva ventana en tu navegador, donde encontrarás la sección de **Configuraciones** 3. Puedes añadir una nueva configuración simplemente haciendo clic en el botón **\+ Añadir configuración** 4 situado en el lado derecho de la pantalla. ![Zero-touch-portal-3](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/38c40062-5da5-4554-9057-9bb6782172a2.png "Zero-touch-portal-3 | Applivery") **Configura el DPC** :::warning En esta etapa, debes proporcionar un nombre para la configuración y rellenar los campos obligatorios. Presta mucha atención al seleccionar **Android Device Policy** en el campo DPC correspondiente. Además, puedes aprender cómo obtener el JSON para el campo **DPC extras** [aquí](#obtén-el-json-para-el-campo-dpc-extras). ::: ![Zero-touch-portal-4](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/b165febd-19be-41eb-bade-9c0d139a55f8.png "Zero-touch-portal-4 | Applivery") **Guarda la configuración** El último paso en el portal es asociar la configuración creada con los dispositivos. Para ello, simplemente selecciona la configuración que se aplicará automáticamente a los dispositivos añadidos y haz clic en el botón **Guardar**. ![Zero-touch-portal-5](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/92b6dbb6-4f0c-41b7-85a2-3158f9e756fa.png "Zero-touch-portal-5 | Applivery") #### Añade la configuración a tus dispositivos Una vez creada la configuración, navega a la sección de **Dispositivos** desde el menú lateral izquierdo. Aquí, encontrarás una lista de dispositivos actualmente activos con Zero-touch que necesitan que se les asigne una configuración. Esto asegura que la inscripción automática apunte a la configuración correcta, permitiendo que el dispositivo se inscriba correctamente. ![Zero-touch-Devices-1](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/3d052ea2-99bd-44c9-8215-cdbe24918369.png "Zero-touch-devices-1 | Applivery") Para asignar una configuración, selecciona **Editar** en el dispositivo deseado. Luego, elige la configuración adecuada del menú desplegable. ![Zero-touch-Devices-2](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/e585b1a4-92e4-4b10-9397-4946cd36ab4f.png "Zero-touch-devices-2 | Applivery") A partir de este momento, el dispositivo se inscribirá automáticamente en Applivery después de un restablecimiento de fábrica, sin requerir ninguna acción adicional. #### Obtén el JSON para el campo DPC extras **Navega a las inscripciones inteligentes de Android** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io), navega a **Automatización** 4, selecciona **Inscripciones inteligentes** 5, y elige **Android** 6 como plataforma en el menú de la izquierda. **Selecciona Zero-touch** Luego, haz clic en los **puntos verticales** 7 situados al final de la inscripción inteligente que deseas configurar dentro del portal Zero-touch y selecciona **Zero-touch** 8. ![Zero-touch](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/c54a4e42-c82b-4b77-9c62-41c6b94b65ef.png) **Copia el JSON** Aparecerá una vista modal que te permitirá introducir configuraciones adicionales y **Copiar** 9 el **JSON** necesario para los DPC extras. ![copy json](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/4a6deb1e-84a1-403e-94b4-1142c7a90458.png) --- ## Lista de funcionalidades Source: https://docs.applivery.com/es/device-management/android/feature-list/ Description: Lista completa de funciones de Android Enterprise en Applivery: gestión de dispositivos, seguridad, control de apps y opciones de inscripción. TL;DR: Applivery es compatible con todas las funciones de Android Enterprise, ofreciendo gestión completa de dispositivos, seguridad y control de apps para Android. Answers: ¿Qué funciones de Android Enterprise son compatibles con Applivery? · ¿Cómo inscribir dispositivos Android con Applivery? · ¿Qué funciones de seguridad están disponibles en Applivery para Android Enterprise? · ¿Cómo gestiona Applivery las apps en Android Enterprise? · ¿Cuáles son los beneficios de usar Applivery para la gestión de Android Enterprise? · ¿Cómo configurar Perfil de trabajo en Android con Applivery? · ¿Cómo usar Zero-Touch Enrollment con Applivery? Key topics: Inscripción de Dispositivos, Seguridad de Dispositivos, Gestión de Apps, Gestión de Dispositivos, Android Enterprise, Applivery, Google Play, Google, NFC, MDM, APK, AAB Applivery es compatible con el conjunto completo de funciones de Android Enterprise. Dado que Applivery cumple totalmente con todos los modos de gestión de Android Enterprise, todas las funciones de Android Enterprise están disponibles por defecto. Sin embargo, puedes encontrar la lista completa de funciones de Android Enterprise [aquí](https://developers.google.com/android/work/requirements). ### Versiones mínimas de Android El agente de Applivery admite **Android 7.0 (API 24) y superiores**. La mayoría de funciones va a partir de ahí, pero unas cuantas necesitan una versión más reciente: conviene comprobarlo antes de dimensionar un despliegue sobre hardware antiguo.

Funcionalidad

Versión mínima

Notas

Gestión de dispositivos general

Android 7.0 (API 24)

La base del agente.

Launcher avanzado

Android 8

El launcher multiaplicación propio de Applivery.

Ajustes de personalización del quiosco: Navegación del sistema, Barra de estado, Configuración del dispositivo, Acciones del botón de encendido, Advertencias de error del sistema

Android 9

Consulta Modo quiosco.

Launcher básico

—

No disponible en dispositivos AOSP. Depende del Device Policy Controller nativo de Android.

:::warning **Una funcionalidad por debajo de su versión mínima se descarta en silencio.** El dispositivo reporta `nonComplianceReason: API_LEVEL` en sus comprobaciones de conformidad, pero no falla nada ni se reinicia nada: el ajuste simplemente no surte efecto. ::: ### Inscripción de dispositivos - **Inscripción en modo totalmente administrado:** Los usuarios finales pueden inscribir un dispositivo totalmente administrado o dedicado introduciendo `afw#setup` en el asistente de configuración del dispositivo. - **Inscripción de dispositivos NFC:** Los administradores de TI pueden “tocar” dispositivos nuevos o restablecidos de fábrica con la app de inscripción NFC de Applivery para inscribir un dispositivo (WIP). - **Inscripción de dispositivos con código QR:** Los administradores de TI pueden usar el dispositivo nuevo o restablecido de fábrica para escanear un código QR generado por el panel de Applivery para inscribir el dispositivo. - **Inscripciones inteligentes:** Automatiza la inscripción de dispositivos y la asignación de políticas basándose en reglas y condiciones predefinidas, lo que permite experiencias Zero-Touch. - **Inscripción de perfil de trabajo:** Los usuarios finales pueden inscribir un perfil de trabajo después de descargar Android Device Policy de Google Play. - **Inscripción Zero-Touch:** La inscripción a través de Zero-Touch es un proceso simplificado para que los dispositivos Android se inscriban en la gestión empresarial. En el primer arranque, los dispositivos comprueban si se les ha asignado una configuración empresarial. Si es así, el dispositivo inicia el método de inscripción de dispositivo totalmente administrado y descarga la app de controlador de políticas de dispositivo correcta, que luego completa la configuración del dispositivo gestionado. ### Seguridad del dispositivo - **Desafío de seguridad del dispositivo:** Los administradores de TI pueden establecer y aplicar un desafío de seguridad del dispositivo (por ejemplo, PIN/patrón/contraseña) de un tipo y complejidad determinados en los dispositivos gestionados. - **Desafío de seguridad del perfil de trabajo:** Los administradores de TI pueden establecer y aplicar un desafío de seguridad para las apps y los datos en el perfil de trabajo que es independiente y tiene requisitos diferentes al desafío de seguridad del dispositivo. - **Gestión avanzada de contraseñas:** Los administradores de TI pueden configurar ajustes avanzados de contraseña en los dispositivos. - **Borrado y bloqueo remotos:** Los administradores de TI pueden usar el panel de Applivery para bloquear y borrar de forma remota los datos de trabajo de un dispositivo gestionado. - **Aplicación de cumplimiento:** Si un dispositivo no cumple con las políticas de seguridad, las reglas de cumplimiento establecidas restringen automáticamente el acceso a los datos de trabajo. - **Políticas de seguridad predeterminadas:** Aplica las políticas de seguridad especificadas en los dispositivos por defecto, sin requerir que los administradores de TI configuren o personalicen ningún ajuste en el panel de Applivery. Algunos ejemplos son el acceso a funciones de depuración bloqueado por defecto o la instalación de apps de fuentes desconocidas bloqueada por defecto. - **Políticas de seguridad para dispositivos dedicados:** Los usuarios no pueden escapar de un dispositivo dedicado bloqueado para habilitar otras acciones. - **Aplicación de Verify Apps:** Los administradores de TI pueden habilitar Verify Apps en los dispositivos. Verify Apps escanea las apps instaladas en dispositivos Android en busca de malware antes y después de su instalación, ayudando a garantizar que los datos corporativos no puedan ser comprometidos por apps maliciosas. - **Gestión de seguridad de hardware:** Los administradores de TI pueden bloquear elementos de hardware de un dispositivo para garantizar la prevención de pérdida de datos. Algunos ejemplos son: los administradores de TI pueden impedir que los usuarios monten medios externos físicos, impedir que los usuarios compartan datos desde su dispositivo usando NFC beam, o impedir que los usuarios transfieran archivos por USB. ### Gestión de Apps - **Distribución silenciosa de apps:** Los administradores de TI pueden distribuir silenciosamente apps de trabajo en los dispositivos de los usuarios sin ninguna interacción del usuario. Incluye la instalación, actualización y desinstalación de apps en dispositivos gestionados. - **Gestión de configuración gestionada:** Los administradores de TI pueden ver y establecer silenciosamente configuraciones gestionadas para cualquier app que admita configuraciones gestionadas. - **Gestión y lista blanca del catálogo de apps:** Los administradores de TI pueden configurar el catálogo de apps de trabajo desde el panel de Applivery añadiendo apps a la lista blanca o a la lista negra. - **Aprobación programática de apps:** Los administradores de TI pueden buscar apps, aprobar apps y aprobar nuevos permisos de apps sin salir del panel. - **Gestión básica del diseño de la Store:** Los usuarios finales pueden usar la app Managed Google Play Store en sus dispositivos para instalar y actualizar apps de trabajo. Por defecto, Managed Google Play Store muestra todas las apps aprobadas para un usuario en una única lista. Este diseño se conoce como diseño básico de la Store. - **Gestión de apps privadas alojadas por Google:** Los administradores de TI pueden actualizar apps privadas alojadas por Google a través del panel en lugar de a través de la consola de Google Play. - **Gestión de apps privadas autoalojadas:** Los administradores de TI pueden configurar y publicar apps privadas autoalojadas. A diferencia de las apps privadas alojadas por Google, los APKs / AABs no están alojados por Google Play. En su lugar, Applivery ayuda a los administradores de TI a alojar APKs en los servidores de Applivery, y ayuda a proteger las apps autoalojadas asegurando que solo se puedan instalar cuando estén autorizadas por Managed Google Play. - **Gestión de Web Apps:** Los administradores de TI pueden crear y distribuir Web Apps en el panel de Applivery. ### Gestión de Dispositivos - **Gestión de políticas de permisos en tiempo de ejecución:** Los administradores de TI pueden establecer silenciosamente una respuesta predeterminada a todas las solicitudes de permisos en tiempo de ejecución realizadas por las apps de trabajo. Los administradores de TI deben poder elegir entre las siguientes opciones al establecer una política de permisos en tiempo de ejecución predeterminada para su organización: preguntar (permite a los usuarios elegir), permitir o denegar. - **Gestión del estado de concesión de permisos en tiempo de ejecución:** Después de establecer una política de permisos en tiempo de ejecución predeterminada, los administradores de TI pueden establecer silenciosamente respuestas para permisos específicos de cualquier app de trabajo creada en API 23 o superior. - **Gestión de configuración de Wi-Fi:** Los administradores de TI pueden aprovisionar silenciosamente configuraciones de Wi-Fi empresariales en dispositivos gestionados, incluyendo SSID, contraseña y muchas otras configuraciones avanzadas. - **Gestión de seguridad de Wi-Fi:** Los administradores de TI pueden aprovisionar configuraciones de Wi-Fi empresariales en dispositivos que incluyen las siguientes funciones de seguridad avanzadas (Identidad, Certificados para autorización de cliente y certificados CA). - **Gestión avanzada de Wi-Fi:** Los administradores de TI pueden bloquear las configuraciones de Wi-Fi en dispositivos gestionados para evitar que los usuarios creen nuevas configuraciones o modifiquen las configuraciones corporativas. Los usuarios no pueden modificar ninguna configuración de Wi-Fi. - **Gestión de cuentas:** Los administradores de TI pueden garantizar que solo las cuentas corporativas autorizadas puedan interactuar con los datos corporativos, para servicios como almacenamiento SaaS y apps de productividad, o correo electrónico. Sin esta función, los usuarios pueden añadir cuentas personales a aquellas apps corporativas que también admiten cuentas de consumidor, lo que les permite compartir datos corporativos con esas cuentas personales. Los administradores de TI pueden impedir que los usuarios añadan o modifiquen cuentas. - **Gestión de servicios de accesibilidad:** Los administradores de TI pueden controlar qué servicios de accesibilidad se pueden habilitar en los dispositivos de los usuarios. Si bien los servicios de accesibilidad son herramientas potentes para usuarios con discapacidades o que están temporalmente imposibilitados de interactuar completamente con su dispositivo, pueden interactuar con datos corporativos de formas que no cumplen con la política corporativa. Esta función permite a los administradores deshabilitar cualquier servicio de accesibilidad que no sea del sistema. - **Gestión de ubicación compartida:** Los administradores de TI pueden impedir que los usuarios compartan datos de ubicación con apps en el perfil de trabajo. De lo contrario, la configuración de ubicación del perfil de trabajo es configurable por el usuario en Ajustes. - **Gestión avanzada de ubicación compartida:** Los administradores de TI pueden aplicar una configuración de ubicación compartida determinada en un dispositivo gestionado. Esta función puede garantizar, por ejemplo, que las apps corporativas siempre tengan acceso a datos de ubicación de alta precisión, o que los usuarios no consuman batería adicional restringiendo la configuración de ubicación al modo de ahorro de batería. Los administradores de TI pueden establecer los servicios de ubicación del dispositivo en cada uno de los siguientes modos: alta precisión, solo sensores (por ejemplo, GPS, pero sin incluir la ubicación proporcionada por la red), ahorro de batería (que limita la frecuencia de actualización) y Desactivado. - **Gestión de protección de restablecimiento de fábrica:** Permite a los administradores de TI proteger los dispositivos propiedad de la empresa contra robos, asegurando que solo los usuarios autorizados puedan restablecer los dispositivos de fábrica. Los administradores también pueden deshabilitar la protección de restablecimiento de fábrica por completo si introduce complejidades operativas cuando los dispositivos se devuelven a TI. - **Control avanzado de apps:** Los administradores de TI pueden impedir que el usuario desinstale o modifique de otro modo las apps gestionadas a través de Ajustes, por ejemplo, forzando el cierre de la app o borrando la caché de datos de una app. - **Gestión de captura de pantalla:** Los administradores de TI pueden impedir que los usuarios realicen capturas de pantalla al usar apps gestionadas. Esto incluye bloquear apps para compartir pantalla y apps similares (como Google Assistant) que aprovechan las capacidades de captura de pantalla del sistema. - **Deshabilitar cámaras:** Los administradores de TI pueden deshabilitar el uso de las cámaras del dispositivo por parte de las apps gestionadas. - **Reiniciar dispositivo de forma remota:** Los administradores de TI pueden reiniciar de forma remota los dispositivos gestionados. - **Gestión de radio del sistema:** Los administradores de TI pueden impedir que los usuarios modifiquen la configuración de la red móvil, configurar si el dispositivo permite datos móviles en roaming, configurar si el dispositivo puede realizar llamadas salientes, excluyendo las llamadas de emergencia, configurar si el dispositivo puede enviar y recibir mensajes SMS, impedir que los usuarios utilicen su dispositivo como punto de acceso portátil mediante tethering, establecer el tiempo de espera de Wi-Fi en predeterminado, solo mientras está enchufado, o nunca, e impedir que los usuarios configuren o modifiquen las conexiones Bluetooth existentes. - **Gestión de audio del sistema:** Los administradores de TI pueden controlar silenciosamente las funciones de audio del dispositivo, incluyendo silenciar el dispositivo, impedir que los usuarios ajusten la configuración de volumen e impedir que los usuarios desactiven el micrófono del dispositivo. Los administradores de TI pueden silenciar silenciosamente los dispositivos gestionados, impedir que los usuarios modifiquen la configuración de volumen del dispositivo e impedir que los usuarios desactiven el micrófono del dispositivo. - **Gestión del reloj del sistema:** Los administradores de TI pueden controlar la configuración del reloj y la zona horaria del dispositivo, e impedir que los usuarios modifiquen la configuración automática del dispositivo. - **Funciones avanzadas de dispositivos dedicados:** deshabilitar el bloqueo de pantalla del dispositivo, deshabilitar la barra de estado del dispositivo, bloquear notificaciones y ajustes rápidos, forzar que la pantalla del dispositivo permanezca encendida mientras el dispositivo está enchufado, e impedir que se muestren las siguientes interfaces de usuario del sistema (Toasts, actividades telefónicas, alertas del sistema, errores del sistema y superposiciones del sistema), habilitar la recomendación del sistema para que las apps omitan su tutorial de usuario y otras sugerencias introductorias al iniciar por primera vez (omitir sugerencias de primer uso). ### Usabilidad del dispositivo - **Personalización de la inscripción gestionada:** Los administradores de TI pueden modificar la UX del flujo de inscripción gestionada predeterminada para incluir funciones específicas de la empresa. Opcionalmente, los administradores pueden mostrar la marca proporcionada por el EMM durante la inscripción. Los administradores de TI pueden personalizar el proceso de inscripción especificando los siguientes detalles específicos de la empresa: color de la empresa (ver `primaryColor`), logotipo de la empresa (ver `logo`), términos de servicio de la empresa y otros avisos legales (ver `termsAndConditions`). - **Mensajes en la pantalla de bloqueo:** Los administradores de TI pueden establecer un mensaje personalizado que siempre se muestra en la pantalla de bloqueo del dispositivo y no requiere el desbloqueo del dispositivo para ser visto. - **Gestión de transparencia de políticas:** Los administradores de TI pueden personalizar el texto de ayuda proporcionado a los usuarios cuando intentan modificar la configuración gestionada en su dispositivo o implementar un mensaje de soporte genérico proporcionado por el EMM. Tanto los mensajes de soporte cortos como los largos se pueden personalizar y se muestran en casos como intentar desinstalar una app gestionada para la que un administrador ya ha bloqueado la desinstalación. - **Política de actualización del sistema:** Los administradores de TI pueden configurar y aplicar actualizaciones del sistema por aire (OTA) para los dispositivos. - **Gestión del modo de tarea bloqueada (App en modo quiosco):** Los administradores de TI pueden bloquear una app o un conjunto de apps en la pantalla y asegurarse de que los usuarios no puedan salir de la app. - **Gestión de actividad preferida persistente:** Permite a los administradores establecer una app como el controlador de intención predeterminado para intenciones que coinciden con un filtro de intención determinado. Por ejemplo, esto permitiría a los administradores elegir qué app de navegador abre automáticamente todos los enlaces web, o qué app de lanzador se utiliza cuando el usuario pulsa el botón de inicio. - **Gestión de funciones de bloqueo de pantalla:** Los administradores de TI pueden controlar las funciones disponibles para los usuarios antes de desbloquear el bloqueo de pantalla del dispositivo y el bloqueo de pantalla del perfil de trabajo. - **Gestión avanzada de funciones de bloqueo de pantalla:** Los administradores de TI pueden controlar las funciones avanzadas de bloqueo de pantalla del dispositivo. 5.12.1. Los administradores de TI pueden deshabilitar las siguientes funciones de bloqueo de pantalla del dispositivo: cámara segura, todas las notificaciones, sin censura, agentes de confianza, desbloqueo por huella dactilar y todas las funciones de bloqueo de pantalla. - **Depuración remota:** La API de gestión de Android no es compatible actualmente con esta función. - **Recuperación de dirección MAC:** Applivery MDM puede obtener silenciosamente la dirección MAC de un dispositivo, para ser utilizada para identificar dispositivos en otras partes de la infraestructura empresarial (por ejemplo, al identificar dispositivos para el control de acceso a la red). - **Gestión avanzada del modo de tarea bloqueada:** Cuando se habilita un modo de tarea bloqueada en un dispositivo, los administradores de TI pueden usar el panel para realizar las siguientes tareas: botón de inicio, vista general, acciones globales, notificaciones, barra de información/estado del sistema y bloqueo de pantalla. - **Política avanzada de actualización del sistema:** Los administradores de TI pueden establecer un período de congelación específico para bloquear las actualizaciones del sistema en un dispositivo. - **Gestión de transparencia de políticas del perfil de trabajo:** Los administradores de TI pueden personalizar el mensaje que se muestra a los usuarios al eliminar el perfil de trabajo de un dispositivo. --- ## Primeros pasos Source: https://docs.applivery.com/es/device-management/android/get-started/ Description: Configura Android Enterprise con Applivery para una gestión segura de dispositivos. Incluye la configuración de cuentas Google Workspace o Gmail en 4 pasos. TL;DR: Configura Android Enterprise con Applivery estableciendo tu cuenta de Google e integrando Managed Google Play para la gestión de dispositivos. Answers: ¿Por qué es necesaria la configuración de Android Enterprise para Applivery? · ¿Qué tipos de cuenta de Google se pueden usar para la inscripción de Android Enterprise con Applivery? · ¿Cuáles son los requisitos previos para usar una cuenta de Google Workspace para Android Enterprise? · ¿Cómo habilito la integración EMM de terceros en Google Workspace? · ¿Cuáles son las principales limitaciones de usar una cuenta personal de Gmail para Android Enterprise? · ¿Dónde inicio el proceso de inscripción de Android Enterprise dentro de Applivery? · ¿Qué información requiere Google Play for Work durante la inscripción de Android Enterprise? Key topics: Configuración de la organización Android Enterprise, Tipos de cuenta de Google para EMM, Configuración de Google Workspace, Inscripción de Android Enterprise en Applivery, Integración de Managed Google Play, Applivery, Android Enterprise, Google Workspace, Gmail, Consola de administración de Google, Managed Google Play, MDM, EMM Para empezar a gestionar dispositivos Android con Applivery, el primer paso es configurar una organización de **Android Enterprise**. Esto vincula a tu empresa con la infraestructura de gestión de Android de Google, permitiendo a Applivery desplegar apps de forma segura, aplicar políticas y controlar dispositivos en toda tu flota. Esta **inscripción** es necesaria antes de poder utilizar cualquier función de gestión de dispositivos Android, y establece la conexión entre tu organización y los servicios de Android Enterprise Mobility Management (EMM) de Google. ### Elección del tipo de cuenta de Google adecuado Antes de iniciar la configuración, es importante decidir qué tipo de cuenta de Google utilizarás para **inscribir** tu organización. Esta elección afecta a cómo se configura tu entorno y qué funciones estarán disponibles para ti. #### Google Workspace (dominio gestionado) Si tu organización utiliza **Google Workspace** (anteriormente G Suite), te recomendamos encarecidamente que uses una cuenta gestionada bajo tu dominio corporativo (por ejemplo, `usuario@tuempresa.com`). Esta configuración ofrece el nivel más alto de integración, gestión centralizada y escalabilidad. Para proceder con esta opción, se deben cumplir algunos requisitos: - La cuenta que utilices debe ser un **Administrador** en Google Workspace — un **Super Admin** — con permiso para autorizar integraciones EMM. - Tu dominio ya debe estar **verificado** en Google Workspace. - Deberás **habilitar la integración EMM de terceros** desde la Consola de administración de Google. Habilitar esta integración permite a Applivery actuar en nombre de tu organización al gestionar dispositivos, aplicar políticas y desplegar apps a través de Managed Google Play. :::tip Vincular Applivery como managed Google domain es también lo que habilita el control de identidad a nivel de dominio. Una vez configurado, puedes obligar a que los dispositivos solo se aprovisionen con las cuentas de tu empresa — consulta [Restringir la inscripción a un dominio corporativo](https://docs.applivery.com/es/device-management/android/policies/restrict-enrollment-to-corporate-domain/). ::: #### Gmail (cuenta no gestionada) Alternativamente, puedes **inscribir** tu configuración de Android Enterprise utilizando una cuenta personal de **Gmail** (por ejemplo, `tuempresa@gmail.com`). Este enfoque es más rápido y sencillo, sin necesidad de configuración de dominio adicional, pero tiene limitaciones. Dado que no está conectado a un dominio corporativo, este método es más adecuado para equipos pequeños, entornos de prueba u organizaciones que no utilizan Google Workspace. Carece de controles avanzados como la publicación de apps basada en dominios o la gestión centralizada de usuarios, pero aún permite la gestión básica de dispositivos Android a través de Applivery. ### Configuración de Google Workspace para Android Enterprise Si has elegido utilizar una cuenta de **Google Workspace** (dominio gestionado) para tu configuración de Android Enterprise, sigue estos pasos para asegurarte de que tu dominio esté configurado correctamente y listo para la integración con Applivery. **Verificación de tu dominio en Google Workspace** Antes de poder vincular tu organización con Android Enterprise, asegúrate de que tu dominio esté verificado en Google Workspace. Para ello, inicia sesión en la [Consola de administración de Google](https://admin.google.com/) utilizando una cuenta de **Super Admin**. Desde el panel de la Consola de administración, navega a **Dominios > Gestionar dominios**. Si tu dominio aún no ha sido verificado, sigue las indicaciones proporcionadas por Google para verificarlo, ya sea añadiendo un registro DNS o subiendo un archivo HTML. Verificar tu dominio asegura que tu organización sea reconocida por Google y te permite aprovechar al máximo las funciones de gestión a nivel empresarial, como la distribución centralizada de apps y las políticas de dispositivos. ![](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/0e55aa0e-be26-4515-b370-2e15e1c8795f.png) **Habilitación de la integración EMM de terceros** Para permitir que Applivery gestione tus dispositivos, debes habilitar la **integración EMM de terceros** dentro de la Consola de administración de Google. Navega a **Dispositivos** y accede a **Móviles y puntos finales > Ajustes > Integraciones de terceros**, luego selecciona una Unidad organizativa (UO). Puedes configurar este ajuste a nivel superior para que se aplique a todas las unidades secundarias, o puedes personalizarlo para unidades secundarias individuales si es necesario. Verás una opción para **Habilitar la gestión de dispositivos móviles Android de terceros**. Actívala para permitir que Applivery se integre con Google Play for Work. ![enable third party integration](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/375cd62c-c657-402a-931f-7c843734a7a2.png) **Asignación de roles de administrador para Android Enterprise** La cuenta de Google utilizada para la configuración de Android Enterprise debe tener los permisos adecuados. Si no estás utilizando una cuenta de **Super Admin** para el proceso de **inscripción**, deberás asignar el rol necesario. Desde la Consola de administración, navega a **Roles de administrador** y asigna un rol con los privilegios de **Gestión de Dispositivos Móviles**, o da acceso completo de **Super Admin** si quieres que la configuración tenga control total. Se recomienda **Super Admin** para una configuración sin problemas, ya que asegura que no haya restricciones durante el proceso. ![admin privileges](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/6e448adf-4016-4326-927e-53224bb2c8a9.gif) ### Configuración de Android Enterprise Una vez completadas estas configuraciones, estás listo para proceder con el proceso de **inscripción** en Applivery. Esto es lo que sucede a continuación. **Configuración de tu cuenta** En el [**panel de Applivery**](https://dashboard.applivery.io), dirígete a la sección de **Configuración** y localiza la sección de **Configuración Android** en el menú de la izquierda. Luego, sigue los pasos que verás en pantalla. ![android enterprise](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/f8890981-780f-4f45-82bc-0bf20c16de20.png) En el punto #2, tu navegador te redirigirá al sitio web de **Google Play for Work**. Tienes que iniciar sesión utilizando una cuenta de Google. **Inscripción de tu Android Enterprise** ![log in android for work](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ad1b0667-8f25-4917-836c-456c8d40fb0d.png)![](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-347493eec71/7fbbd68e-6110-4726-8a01-25855ebde2a4.png) Inicia sesión con tu cuenta de Google y sigue los siguientes pasos, donde Google te pedirá la siguiente información: - Nombre de la empresa. - Información de contacto para la protección de datos: - Delegado de Protección de Datos (DPO): nombre, dirección de **email** y número de teléfono. - Representante de la UE: nombre, dirección de **email** y número de teléfono. - Aceptar los términos y condiciones de Managed Google Play. ![enterprise name](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/dd6cd1e8-a6e6-43db-94f5-f56af4fb5a39.png)![contact info](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/e6922a48-9201-4c32-8eac-0311f05c2272.png)![](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-347493eec71/4a8f4d99-53a7-4668-b3b0-be34ed534936.png)![](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-347493eec71/1f7b82ed-3fea-472a-9011-303371255d2f.png) **Finalizar y volver al panel de Applivery** Una vez finalizado, haz clic en el botón **Completar el registro**. Tu navegador te redirigirá automáticamente de vuelta al **panel de Applivery**, donde podrás empezar a configurar tus dispositivos y políticas. --- ## Migrar de Managed Google Play Accounts a Managed Google Domain Source: https://docs.applivery.com/es/device-management/android/migrate-to-managed-google-domain/ Description: Actualiza un binding de Android Enterprise existente de Managed Google Play Accounts enterprise a Managed Google Domain en Applivery — sin reinscribir tus dispositivos gestionados. TL;DR: Si tu Android Enterprise está vinculado como Managed Google Play Accounts enterprise, puedes actualizarlo a Managed Google Domain desde el Setup de Android de Applivery o desde el catálogo de Managed Google Play. El upgrade mantiene el mismo Enterprise ID y no reinscribe dispositivos, pero es de solo ida. Key topics: Modelos de identidad de Android Enterprise, Upgrade del enterprise, Binding de Managed Google Domain, Requisitos de Google Workspace, Android Enterprise, Managed Google Play, Managed Google Domain, Google Workspace, Applivery Android Enterprise admite dos modelos de identidad para el aprovisionamiento de dispositivos: **Managed Google Play Accounts Enterprise** y **Managed Google Domain**. En el primero, los usuarios se registran mediante _Managed Google Play Accounts_ — cuentas aprovisionadas directamente por el proveedor EMM y no vinculadas a un dominio corporativo existente. Las _managed Google accounts_ no están soportadas en este modelo, ya que estructuralmente no forman parte de él. En el segundo, la organización opera sobre un dominio de Google gestionado (por ejemplo, Google Workspace o Cloud Identity), lo que permite a los usuarios autenticarse con sus _cuentas de Google gestionadas_ corporativas y asociar esa identidad directamente a los dispositivos Android gestionados. En la práctica, esto determina el nivel de control de identidad disponible. Si necesitas restringir el aprovisionamiento a identidades corporativas de un dominio específico, el modelo adecuado es el Managed Google Domain. Bajo un Managed Google Play Accounts Enterprise, el control de identidad queda limitado al esquema de Managed Google Play Accounts, sin posibilidad de aplicar restricciones a nivel de dominio. Por eso, cuando necesites restringir el alta de cuentas en el dispositivo únicamente a las que pertenecen a tu dominio corporativo, Applivery debe haberse vinculado como **Managed Google Domain**. :::info Desde 2024, Google proporciona un Managed Google Domain por defecto a todas las organizaciones nuevas que se registran en Android Enterprise, tal y como indica la [documentación oficial de Android Enterprise](https://support.google.com/work/android/answer/7042221). El modelo Managed Google Play Accounts Enterprise queda como opción de fallback para casos concretos — por ejemplo, organizaciones que no pueden o no quieren vincular un dominio de Google gestionado. Esta migración aplica a organizaciones que ya operan bajo el modelo antiguo y quieren pasar al modelo de dominio gestionado. ::: ### Diferencias y beneficios

Managed Google Play Accounts Enterprise

Managed Google Domain

Tipo de cuenta de usuario

Managed Google Play Accounts (cuentas limitadas, creadas y gestionadas por el EMM)

Managed Google accounts (cuentas completas, vinculadas al dominio corporativo)

Responsable de la autenticación

El EMM (Applivery)

Google

Vinculación a un dominio corporativo

No

Sí

Restricción de alta por dominio

No disponible

Disponible (Authentication Type: GOOGLE_AUTHENTICATED + dominio gestionado)

Acceso a otros servicios de Google

Solo Managed Google Play

Suite completa de Google (Workspace, Cloud Identity, etc.)

Gestión centralizada de usuarios

No

Sí (Consola de administración de Google)

SSO / MFA a nivel de organización

No

Sí

Recomendación de Google

Solo como fallback

Modelo recomendado y por defecto desde 2024

Migrar a un Managed Google Domain te aporta: - **Aprovisionamiento restringido por dominio** — puedes exigir una cuenta corporativa (por ejemplo, forzar la autenticación con `@tuempresa.com` en el primer arranque del dispositivo). - **Administración con credenciales corporativas** — gobierno de identidad adecuado (roles, MFA, SSO) en lugar de depender de una cuenta de Gmail suelta. - **Gestión centralizada** de usuarios, apps y dispositivos junto con el resto de tus productos de Google (Workspace, ChromeOS, Chrome browser) desde la Consola de administración de Google. - **Menor riesgo** que depender de una cuenta de Gmail personal para el binding — compromiso, pérdida de acceso si la persona titular abandona la organización y ausencia de controles de seguridad corporativos. ### Antes de empezar Verifica lo siguiente antes de iniciar la migración: - Tu organización debe estar registrada actualmente como **Managed Google Play Accounts Enterprise** en Applivery. El upgrade solo admite enterprises con `enterpriseType: MANAGED_GOOGLE_PLAY_ACCOUNTS_ENTERPRISE`. Si el binding ya es un managed Google domain, la operación no aplica. - Debe existir (o crearse) un **dominio de Google gestionado** para tu organización — por ejemplo, mediante Google Workspace o Cloud Identity. - Tu plan de facturación de Applivery debe incluir esta funcionalidad. La API devuelve `5050 – Feature not allowed for your billing plan` si no es así. #### Configura el lado de Google Workspace Estos son los mismos requisitos que Applivery exige para dar de alta un Android Enterprise directamente sobre un dominio gestionado, y aplican igualmente antes de migrar una Enterprise existente. **Verifica tu dominio** El dominio corporativo debe estar **verificado** en Google Workspace. Compruébalo y gestiónalo desde la [Consola de administración de Google](https://admin.google.com/), con una cuenta de **Super Admin**, en **Dominios → Gestionar dominios**. Si no está verificado, Google te indicará cómo hacerlo (un registro DNS o la subida de un archivo HTML). ![verify your domain](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/c6b8a356-e987-4cd4-9a13-13e9d36bb8cc.png) **Habilita la integración EMM de terceros** Para que Applivery pueda gestionar los dispositivos bajo el dominio gestionado, habilita la integración EMM de terceros en **Dispositivos → Móviles y puntos finales → Ajustes → Integraciones de terceros**. Selecciona la Unidad Organizativa (UO) correspondiente — puedes aplicarla a nivel superior o por UO — y activa **Habilitar la gestión de dispositivos móviles Android de terceros**. ![third-party](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/142c86af-f4be-4cbb-aa91-6a6225231f60.png) **Confirma los permisos de administrador** La cuenta de Google usada en el proceso debe tener permisos suficientes — se recomienda **Super Admin**. Si usas una cuenta distinta, asígnale un rol con privilegios de **Gestión de Dispositivos Móviles** desde **Roles de administrador** en la Consola de administración. ![perms](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/fb96b54f-1e30-40b7-b9f1-66ed4c5e16cc.png) ### Migra tu Enterprise El upgrade mantiene el mismo Enterprise binding (el mismo Enterprise ID) y no requiere reinscribir los dispositivos que ya están gestionados. Puedes iniciarlo desde dos sitios en Applivery — ambos abren el asistente de Google para vincular tu cuenta al dominio de Google gestionado. #### Opción 1 — Desde la Configuración de Android **Abre la Configuración de Android** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a **Ajustes** y localiza la **Configuración** de **Android** en el menú lateral izquierdo. **Inicia el upgrade** Haz clic en **Iniciar actualización**. Se abre el asistente de Google para que vincules la cuenta a tu dominio de Google gestionado. ![android enterprise binding details](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/89502a08-a003-432c-8f26-43660817b4fd.png) #### Opción 2 — Desde el catálogo de Managed Google Play **Abre el catálogo de Google Play dentro de una política** Dirígete a cualquiera de tus **Políticas** de Android y selecciona **Apps** desde el menú lateral izquierdo. Haz clic en **\+ Añadir App** y selecciona la pestaña de **Google Play**. **Elige Upgrade for free** En el iFrame de Managed Google Play, haz clic en **Upgrade for free** para abrir el asistente de binding de Google. ![upgrade for free](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/4dcd6e2b-5358-4925-b724-943423e0fc51.png) #### Completa el upgrade en Google **Inicia sesión con tu cuenta de Super Admin** Abre la URL del paso anterior con la cuenta de **Super Admin** de Google Workspace correspondiente a tu dominio corporativo. **Sigue el asistente de Google** Sigue el asistente para vincular la Enterprise existente al dominio gestionado. Confirma la vinculación del dominio y acepta los términos que Google solicite durante el proceso. **Verifica el resultado** De vuelta en el panel de Applivery, dirígete a **Ajustes**, después localiza la sección Configuración de **Android** en el menú lateral izquierdo y confirma que la Enterprise queda reflejada como vinculada a un dominio gestionado. ### Errores conocidos de la API

Código

Mensaje

Causa

5050

Feature not allowed for your billing plan

El plan de facturación no incluye esta funcionalidad

6002

Body Validation Error

El body de la petición no cumple el esquema esperado

5147

Enterprise upgrade is only available for managed Google Play Accounts Enterprises (MANAGED_GOOGLE_PLAY_ACCOUNTS_ENTERPRISE)

La Enterprise ya está en modo Managed Google Domain

5095

Error From Emm Android Library

Error devuelto por la librería EMM de Android al procesar la solicitud

4002 / 4004

No auth token / Invalid Token

Fallo de autenticación en la petición

3001

Entity not found

La organización indicada no existe

Si te encuentras con otros códigos de error no documentados aquí, contacta con el soporte de Applivery indicando el ID de organización y el código exacto. ### Consideraciones adicionales :::warning Este proceso es de **solo ida**. Una vez que migras a un Managed Google Domain, no existe un endpoint de downgrade equivalente para volver a un Managed Google Play Accounts Enterprise. ::: - Evalúa el impacto en los dispositivos ya inscritos antes de ejecutar la migración en producción, y valídala primero en una Enterprise u organización de pruebas si te es posible. - Tras la migración, el campo **Required Account Email** de la política de [Configuración de la cuenta de trabajo](https://docs.applivery.com/es/device-management/android/policies/restrict-enrollment-to-corporate-domain/) sigue admitiendo solo una cuenta específica, no un wildcard de dominio. La restricción por dominio se obtiene por la naturaleza del binding (managed Google domain) combinada con **Authentication Type: GOOGLE\_AUTHENTICATED**, no por ese campo. --- ## OEM Configs Source: https://docs.applivery.com/es/device-management/android/oem-configs/ Description: Android OEM Configs en Applivery: gestiona ajustes de fabricante, políticas de seguridad y modo quiosco para dispositivos Android de forma centralizada. TL;DR: Los Android OEM Configs de Applivery centralizan la gestión de ajustes de dispositivos Android específicos del OEM, políticas de seguridad y configuraciones de modo quiosco. Answers: ¿Qué son los Android OEM Configs? · ¿Cómo gestionar dispositivos Android con OEM Configs? · ¿Qué es el modo quiosco en Android? · ¿Cómo aplicar políticas de seguridad en dispositivos Android? · ¿Cómo utiliza Applivery los Android OEM Configs? Key topics: Android OEM Configs, Gestión de dispositivos, Applivery, Modo quiosco, Políticas de seguridad, Android, OEM Los OEM Configs te permiten aplicar ajustes específicos del fabricante a dispositivos Android más allá de lo que cubren las políticas MDM estándar. Diferentes OEM exponen distintas opciones de configuración; Applivery te permite gestionarlas a través de una interfaz estructurada dentro de tus políticas. Los OEM Configs te permiten aplicar ajustes específicos de cada fabricante desde Applivery, con opciones de configuración para cada fabricante compatible. --- ## Configurar Bluebird BOS™ OEMConfig Source: https://docs.applivery.com/es/device-management/android/oem-configs/bluebird-oemconfig/ Description: Configura Bluebird BOS™ OEMConfig con Applivery para aplicar políticas y gestionar dispositivos Bluebird de forma remota desde el panel. TL;DR: Gestiona y configura dispositivos Bluebird de forma remota con BOS™ OEMConfig a través de Applivery, aprovechando Android Enterprise para la aplicación de políticas. Answers: ¿Qué es Bluebird BOS™ OEMConfig? · ¿Cómo añado BOS™ OEMConfig a una política en Applivery? · ¿Dónde configuro las propiedades gestionadas de BOS™ OEMConfig? · ¿Cómo instalo APKs con BOS™ OEMConfig? · ¿Cómo desinstalo aplicaciones con BOS™ OEMConfig? · ¿Cómo añado una red WiFi con BOS™ OEMConfig? · ¿Cómo desactivo las actualizaciones de apps con BOS™ OEMConfig? · ¿Qué tipos de seguridad WiFi admite BOS™ OEMConfig? Key topics: Bluebird BOS™ OEMConfig, Integración con Applivery, Configuración de Android Enterprise, Gestión remota de dispositivos, Aplicación de políticas de dispositivo, Bluebird, BOS™ OEMConfig, Applivery, Android Enterprise ![bluebird-logo](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/513cd1ec-0fc1-4495-a7c7-61a953ffd61c.png) **BOS™ OEMConfig** es la herramienta de configuración de nivel empresarial de Bluebird que permite a los administradores de IT gestionar y ajustar de forma remota el comportamiento del dispositivo a nivel de sistema. Mediante la integración con Applivery, BOS™ OEMConfig aprovecha el marco de configuraciones gestionadas de Android Enterprise para aplicar controles granulares sobre los componentes de hardware y software específicos de Bluebird. Los administradores pueden definir y aplicar políticas de dispositivo avanzadas — incluyendo parámetros de red, gestión de aplicaciones, restricciones de seguridad y comportamiento del modo quiosco — todo desde el panel de Applivery. Esta integración garantiza el cumplimiento total, el rendimiento consistente del dispositivo y un control simplificado en toda la flota de dispositivos Bluebird. ### Primeros pasos Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a cualquiera de tus políticas 1. Desde el menú lateral izquierdo, dirígete a **Apps** 2 y haz clic en el botón **\+ Añadir App** 3. ![](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/78ce8831-975c-4a2c-95bc-ac7105fa36f8.png) Busca la app **BOS™ OEMConfig** y selecciona la de **Bluebird Inc.** (nombre de paquete: `com.bluebird.android.oemconfig`). Establece el **Tipo de instalación** en **Instalación forzada** para que la app se instale automáticamente en cualquier dispositivo asociado a la política. Una vez que la app aparezca en la lista, haz clic sobre ella para expandir todas las **propiedades gestionadas** y configurarlas según tus requisitos. ![bos oemconfig](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/d50e9c1d-0eca-4a95-b830-d94074c283a1.png) :::warning Los ajustes específicos del OEM descritos en este documento son definidos y mantenidos por sus respectivos fabricantes, y pueden cambiar periódicamente. Como estas configuraciones se gestionan externamente, las opciones y valores mostrados en el panel de Applivery pueden diferir ligeramente de los que aparecen en esta documentación. ::: **Gestión de apps** | Ajuste | Descripción | | --- | --- | | Instalar APK | Introduce las URLs (separadas por comas) que permiten descargas directas de APK. El dispositivo descargará e instalará automáticamente las apps desde estos enlaces. | | Desinstalar aplicación | Especifica los nombres de paquete de las apps que se eliminarán del dispositivo. | | Establecer lanzador predeterminado | Especifica el nombre de paquete de la aplicación que se configurará como lanzador predeterminado. | | Fuentes desconocidas | Permite la instalación de apps desde fuentes desconocidas. No compatible con Android 8 o posterior. | | Verificar apps por USB | Activa esta opción para mostrar el ajuste **Verificar apps por USB** en el dispositivo. | | Inicializar estado de apps | Al activar esta opción se inicializa el estado de las apps habilitando todas las aplicaciones que estaban desactivadas anteriormente. | | Lista de apps desactivadas | Introduce una lista de nombres de paquete separados por comas para desactivar. Las apps desactivadas se ocultarán en el lanzador y no podrán usarse. | | Lista de apps activadas | Introduce una lista de nombres de paquete separados por comas para activar. Estas apps aparecerán en el lanzador y serán accesibles para los usuarios. | | Desactivar actualización de apps | Introduce una lista de nombres de paquete separados por comas para las que se desactivarán las actualizaciones automáticas. Las apps incluidas en esta lista permanecerán en su versión actual y no se actualizarán automáticamente. | **Configuración Wi-Fi** | Ajuste | Descripción | | --- | --- | | Añadir red | Especifica una lista de nuevos SSID Wi-Fi para añadir al dispositivo. | | Nombre de red | Introduce el SSID o nombre de la red Wi-Fi. | | Red oculta | Actívalo si la red no emite su SSID. No compatible con Android 8 o inferior. | | Conexión directa | Actívalo para intentar conectarse a la red Wi-Fi inmediatamente después de añadirla. | | Seguridad de red | Define el tipo de seguridad. Las opciones disponibles son **NONE**, **WEP**, **PSK**, **EAP** o **FT-PSK**. | | Contraseña | Introduce la contraseña necesaria para autenticarse en la red. | | Proxy | Configura un servidor proxy. Las opciones disponibles son **NONE**, **STATIC** y **PAC**. | | Ajustes de IP | Especifica la asignación de IP. Las opciones disponibles son **DHCP** o **STATIC_IP**. | | Host/URI | Introduce la dirección del host del proxy. | | Puerto | Introduce el número de puerto del proxy. | | ID de usuario | Introduce el ID de usuario para la autenticación EAP. | | EAP | Elige el protocolo de autenticación extensible para la red. Las opciones disponibles son **PEAP**, **TLS**, **TTLS**, **PWD**, **SIM**, **AKA**, **LEAP** y **FAST**. | | Fase 2 | Selecciona el método de autenticación de fase 2. Las opciones disponibles son **NONE**, **PAP**, **MSCHAP**, **MSCHAPV2** y **GTC**. | | Dirección IP estática | Introduce la dirección IP estática para la red. | | Puerta de enlace IP estática | Introduce la dirección IP de la puerta de enlace de la red. | | Lista DNS | Introduce las direcciones DNS1 y DNS2 separadas por comas. | | Privacidad (MAC aleatoria) | Actívalo para conectarse usando una dirección MAC aleatoria. No compatible con Android 9 o inferior. | | Eliminar SSID | Especifica los SSID Wi-Fi a eliminar del dispositivo. | | Seguridad del SSID a eliminar | Selecciona el tipo de seguridad de la red Wi-Fi que se va a eliminar. Las opciones disponibles son **NONE**, **WEP**, **PSK**, **EAP** y **FT-PSK**. | | Notificación de red | Activa esta opción para mostrar notificaciones cuando haya una red Wi-Fi pública disponible. | | Código de país WLAN | Elige el código de país para la red Wi-Fi. | | Banda de frecuencia | Elige la banda de frecuencia que el dispositivo debe usar para la red Wi-Fi. | | Activación automática de Wi-Fi | Activa esta opción para que el dispositivo encienda el Wi-Fi automáticamente al detectar una red guardada con buena señal. | | Icono de Wi-Fi visible | Muestra el icono de Wi-Fi aunque no haya conexión. No compatible con Android 8 o inferior. | | Modo de operación Wi-Fi | Establece el modo de operación Wi-Fi. Solo compatible con Android 7 (EF501/EF401). | | Ocultar ajustes de Wi-Fi | Elige si se ocultan los ajustes de Wi-Fi. Las opciones disponibles son **Desactivado (mostrar)** y **Activado (ocultar)**. | | Privacidad global de Wi-Fi | Establece la privacidad global de Wi-Fi. Las opciones disponibles son **Activado (usar MAC del dispositivo)** y **Desactivado (usar MAC aleatoria)**. | | Modo de llamada por Wi-Fi | Selecciona el modo de llamada por Wi-Fi. Las opciones disponibles son **UNKNOWN**, **Wi-Fi ONLY**, **CELLULAR PREFERRED** y **Wi-Fi PREFERRED**. | **Configuración de sonido** | Ajuste | Descripción | | --- | --- | | Volumen de alarma | Establece el volumen de alarma del dispositivo. Mínimo: 0, Máximo: 7. | | Volumen de contenido multimedia | Establece el volumen de reproducción multimedia. Mínimo: 0, Máximo: 15. | | Volumen de llamada | Establece el volumen del tono de llamada. Mínimo: 0, Máximo: 7. | | Volumen en llamada | Establece el volumen de voz durante las llamadas. Mínimo: 1, Máximo: 5. | | Sonido de notificación predeterminado | Elige si el sonido de notificación predeterminado está activado. No compatible con Android 7.0 Nougat y versiones posteriores. | | Tonos del teclado de marcado | Activa o desactiva los sonidos al marcar. | | Sonidos de bloqueo de pantalla | Activa o desactiva los sonidos al bloquear o desbloquear la pantalla. | | Sonidos táctiles | Activa o desactiva los sonidos al interactuar con la pantalla táctil. | | Vibración táctil | Activa o desactiva la respuesta vibratoria al tocar la pantalla. | **Configuración de pantalla** | Ajuste | Descripción | | --- | --- | | Nivel de brillo | Ajusta el brillo de la retroiluminación de la pantalla. Rango válido entre 0 y 255. | | Rotación automática de pantalla | Activa o desactiva la rotación automática de la pantalla. | | Salvapantallas | Elige si activar o desactivar el salvapantallas. | | Tiempo de espera de pantalla | Establece el tiempo de inactividad antes de que la pantalla se apague. Las opciones disponibles son **15 segundos**, **30 segundos**, **1 minuto**, **2 minutos**, **5 minutos**, **10 minutos** o **30 minutos**. | | Tema oscuro | Activa o desactiva el modo oscuro — Activado lo habilita y Desactivado lo desactiva. | | Modo escritorio | Configura los ajustes del modo escritorio, incluyendo **Forzar redimensionamiento de actividades**, **Habilitar ventanas libres** y **Forzar modo escritorio**. | | Actualizar tamaño de pantalla | Ajusta el escalado de la pantalla. Las opciones disponibles son **204**, **240**, **246**, **254** y **262**. | | Actualizar tamaño de fuente | Ajusta el tamaño del texto. Las opciones disponibles son **0.85**, **1.00**, **1.15**, **1.30**, **1.50**, **1.80** o **2.00**. | **Configuración de fecha y hora** | Ajuste | Descripción | | --- | --- | | Zona horaria | Especifica la zona horaria del dispositivo. | | Zona horaria automática | Activa esta opción para usar automáticamente la zona horaria proporcionada por la red. | | Fecha y hora automáticas | Actívalo para usar automáticamente la fecha y hora proporcionadas por la red. | | Usar formato de 24 horas | Activa esta opción para mostrar la hora en formato de 24 horas. | | Servidor NTP | Introduce la URL del servidor NTP para sincronizar la hora del dispositivo. | | **Establecer la fecha del dispositivo** | | | Año | Establece el año del sistema del dispositivo. | | Mes | Establece el mes del sistema del dispositivo. | | Día | Establece el día del dispositivo según la zona horaria especificada. | | **Establecer la hora del dispositivo** | | | Hora | Establece la hora del dispositivo (en horas) según la zona horaria especificada. | | Minuto | Establece la hora del dispositivo (en minutos) según la zona horaria especificada. | **Configuración del modo quiosco** | Ajuste | Descripción | | --- | --- | | Estado del modo quiosco | Selecciona si activar o desactivar el modo quiosco en el dispositivo. | | Nombre del cliente del quiosco | Introduce el nombre del cliente asociado al quiosco. **Este campo es obligatorio**. | | Bloqueos | Especifica la lista de funciones del sistema que se bloquearán. Las opciones disponibles son **Barra de estado**, **Apps recientes** y **ADB**. | | Clip | Configura la función del clip flotante, como activar la función de **flash** o **código de barras**. | | Contraseña | Establece una contraseña numérica para acceder a la página de administrador. La contraseña **debe tener al menos 4 dígitos**. | | Lista de nombres de paquete de apps a usar | Introduce los nombres de paquete de las aplicaciones accesibles en el dispositivo, separados por comas. | | Acceso rápido a ajustes | Configura qué accesos rápidos a ajustes detallados son accesibles en el modo quiosco, como **Wi-Fi** y **Bluetooth**. | | Widget de Búsqueda de Google en modo quiosco | Activa esta opción para mostrar el widget de Búsqueda de Google mientras el dispositivo está en modo quiosco. | **Configuración OTA** | Ajuste | Descripción | | --- | --- | | Desactivar actualización OTA | Actívalo para desactivar completamente las actualizaciones OTA. | | Iniciar actualización de OS por OTA | Establece si se inicia la actualización de OS por OTA. Si hay una versión superior disponible y se actualiza, el dispositivo se reiniciará y no recibirás información sobre el resultado de la actualización. | | Tipo de datos OTA | Actívalo para permitir la descarga de archivos OTA a través de una conexión de datos móviles. | | URL del servidor OTA | Introduce la URL del servidor OTA. Si se deja en blanco, el dispositivo intentará actualizar el OS usando la URL predeterminada. | | Ventana emergente de actualización de OS | Muestra un aviso emergente una vez que se recibe información de la actualización. | | Ajustes de hora del aviso emergente | Si la actualización se cancela, el aviso emergente volverá a aparecer a la hora especificada. Valor predeterminado: 08. | | Permiso de cancelación de aviso de OS (ilimitado) | Permite la cancelación ilimitada del aviso emergente de actualización de OS. | | Permiso de cancelación de aviso de OS (por fecha) | Establece fechas específicas para el comportamiento del aviso emergente de actualización de OS. Valor predeterminado: 1. | | Enviar información CSR | Introduce la URL del servidor para enviar información CSR. | | **OTA avanzada** | | | URL del servidor de producto | Introduce la URL del servidor de producto. Si se deja en blanco, el dispositivo intentará obtener la URL OTA usando la URL predeterminada. | | URL del servidor OTA avanzada | Introduce la URL del servidor OTA avanzada para información de garantía y acceso a la consola web. Si se deja en blanco, el dispositivo usará la URL predeterminada. | | URL de descarga del agente | Especifica la URL para que el agente OTA avanzado actualice el agente preinstalado. | | Grupo de terminal | Define el grupo al que pertenece un dispositivo, usado para actualizaciones basadas en grupos. | | ID de usuario | Introduce el ID de usuario de credencial para acceso a la consola web. | | Contraseña | Introduce la contraseña para el acceso a la consola web. | **Configuración de batería** | Ajuste | Descripción | | --- | --- | | Porcentaje de batería | Actívalo para mostrar el porcentaje de batería en la barra de estado. | | Notificación de salud de batería baja | Activa o desactiva las notificaciones de salud de batería baja en la app Battery Manager (versión 3.3.1 o posterior). | | Umbral de salud de batería baja (%) | Establece el porcentaje de salud de batería en el que se activa la notificación de salud baja. Los valores varían según el modelo, normalmente entre 60% y 80%. | | Notificación de ciclo de batería alto | Activa o desactiva las notificaciones de ciclo de batería alto en la app Battery Manager (versión 3.3.1 o posterior). | | Umbral de ciclo de batería alto | Establece el número de ciclos de batería en el que se activa la notificación de ciclo alto. Los valores varían según el modelo, normalmente entre 400 y 600 ciclos. | | Notificación de temperatura de batería alta | Activa o desactiva las notificaciones de temperatura de batería alta en la app Battery Manager (versión 3.3.1 o posterior). | | Umbral de temperatura de batería alta | Establece la temperatura (°C) en la que se activa la notificación de temperatura alta. Los valores varían según el modelo, normalmente entre 50,0 °C y 59,0 °C. | | Establecer modo ahorro de batería | Activa o desactiva el modo ahorro de batería. Activado habilita el modo, Desactivado lo deshabilita. | | Establecer modo de batería | Activa o desactiva el modo de batería. Activado habilita el modo, Desactivado lo deshabilita. | **Configuración de conexión** | Ajuste | Descripción | | --- | --- | | Bluetooth | Activa o desactiva la conectividad Bluetooth en el dispositivo. | | NFC | Activa o desactiva la funcionalidad NFC en el dispositivo. | **Configuración de red** | Ajuste | Descripción | | --- | --- | | Ethernet | Activa o desactiva la conectividad Ethernet en el dispositivo. | | Itinerancia de datos | Activa o desactiva la itinerancia de datos. No compatible con Android 8 o inferior. | | Ocultar contraseña APN | Elige **Desactivado para mostrar** o **Activado para ocultar** la contraseña APN. | | Activar tarjeta Nano | Activa o desactiva la tarjeta nano SIM. (Solo compatible con los modelos EF551, S50 y S70). | | No permitir compartir QR de Wi-Fi | Impide que los usuarios compartan credenciales de Wi-Fi mediante código QR. | | Configurar portal cautivo | Configura los ajustes del portal cautivo para la conexión de red del dispositivo. | | **Especificar la lista de APN a añadir** | | | Nombre del APN | Introduce un nombre para identificar el APN entre otras redes. | | Dominio del APN | Introduce el nombre de dominio del servidor APN. | | Proxy del APN | Introduce el nombre de dominio o la dirección IP del servidor proxy. | | Puerto del APN | Especifica el número de puerto del servidor proxy. | | Proxy MMS del APN | Introduce el nombre de dominio o la dirección IP del servidor proxy de mensajería multimedia. | | Puerto MMS del APN | Especifica el número de puerto del proxy MMS. | | Servidor APN | Introduce la URL del servidor APN. | | Usuario APN | Introduce el nombre de usuario para la autenticación. | | Contraseña APN | Introduce la contraseña asociada al nombre de usuario. | | MMSC del APN | Introduce la URL del centro de servicios de mensajería multimedia para el APN. | | MCC del APN | Introduce el código de país del móvil (MCC). | | MNC del APN | Introduce el código de red del móvil (MNC). | | Tipo de APN | Introduce una lista de tipos de APN separados por comas. Las opciones disponibles incluyen **DEFAULT**, **MMS**, **SUPL**, **DUN**, **HIPRI**, **FOTA**, **IMS**, **CBS**, **IA** y **EMERGENCY**. Usa ***** para permitir todos los tipos especificados. | | Tipo de autenticación | Elige el método de autenticación. Las opciones disponibles son **NONE**, **PAP**, **CHAP** o **PAP or CHAP**. | | Portador | Define una lista de portadores: **LTE**, **HSPAP**, **HSPA**, **HSUPA**, **HSDPA**, **UMTS**, **EDGE**, **GPRS**, **eHRPD**, **EVDO_B**, **EVDO_A**, **EVDO_0**, **1xRTT**, **IS95B** o **IS95A**. | | Protocolo APN | Selecciona el protocolo APN: **IPv4**, **IPv6** o **IPv4/IPv6**. | | Protocolo APN en itinerancia | Selecciona el protocolo APN para itinerancia: **IPv4**, **IPv6** o **IPv4/IPv6**. | | Tipo de MVNO del APN | Elige el tipo de operador de red virtual móvil: **SPN** (nombre del proveedor de servicios), **IMSI** (identidad internacional del abonado móvil), **GID** (identificador de grupo) o **ICCID** (identificador de tarjeta de circuito integrado). | | Datos MVNO del APN | Introduce los datos MVNO correspondientes. | | Preferencia APN | Actívalo para establecer el APN configurado como predeterminado. | | **Eliminar los APN especificados. Esta función es compatible con dispositivos con la versión 4.12.2 o posterior de la app BOS Provisioning.** | | | Eliminar múltiples APN (usando nombre de visualización del APN) | Introduce los nombres de visualización del APN separados por comas. | | Eliminar múltiples APN (usando nombre de dominio del APN) | Introduce los nombres de dominio del APN separados por comas. | | **DNS privado: de forma predeterminada, los dispositivos actualizan automáticamente a DNS sobre TLS si el servidor DNS de la red lo admite. Los usuarios que no quieran usar DNS sobre TLS pueden desactivarlo. Esta función no es compatible con Android 8 o inferior.** | | | Modo DNS privado | Selecciona el modo DNS privado. Las opciones disponibles son **Desactivado**, **Automático** o **Nombre de host del proveedor DNS privado**. | | Nombre de host del proveedor DNS | Introduce el nombre de host del proveedor DNS. | | **IP estática de Ethernet** | | | Dirección IP | Introduce la dirección IP estática. | | Longitud de prefijo de red | Introduce la longitud del prefijo. | | Puerta de enlace | Introduce la dirección de la puerta de enlace. | | DNS1 | Introduce el DNS principal, a menos que sea anulado por el DNS privado. | | DNS2 | Introduce el DNS secundario, a menos que sea anulado por el DNS privado. | | **Configuración de red Ethernet** | | | Estado de Ethernet | Introduce el estado. | | Tipo de conexión | Elige entre **DHCP** o **IP estática**. | | **Configuración de IP estática para red Ethernet** | | | Dirección IP | Introduce la dirección IP estática. | | Longitud de prefijo de red | Introduce la longitud del prefijo. | | Puerta de enlace | Introduce la dirección de la puerta de enlace. | | DNS1 | Introduce el DNS principal, a menos que sea anulado por el DNS privado. | | DNS2 | Introduce el DNS secundario, a menos que sea anulado por el DNS privado. | | **Opciones avanzadas de Ethernet** | | | Proxy | Elige entre **Ninguno**, **Manual** o **Configuración automática de proxy**. | | Nombre de host del proxy | Introduce el nombre de host. | | Puerto del proxy | Introduce el puerto del proxy (**para tipo de proxy: Manual**). | | Omitir proxy para | Introduce el puerto de omisión del proxy (**para tipo de proxy: Manual**). | | URL PAC | Introduce la URL PAC (**para tipo de proxy: Configuración automática**). | | **Establecer configuración de Ethernet** | | | Tipo de configuración de Ethernet | Elige entre **Configuración normal** o **Configuración empresarial**. | | Método EAP | Elige entre **PEAP**, **TTLS** o **TLS**. | | Autenticación de fase 2 | Elige entre **Ninguna**, **PAP**, **MSCHAP**, **MSCHAPV2** o **GTS**. | | Identidad | Introduce la identidad. | | Identidad anónima | Introduce la identidad anónima. | | Contraseña | Introduce la contraseña. | | Nombre del certificado CA | Introduce el nombre del certificado CA. | | Nombre del certificado de usuario | Introduce el nombre del certificado de usuario. | | **Establecer PLMN de red** | | | Instalar ID de red PLMN | Introduce el identificador de red de la Red Pública de Tierra Móvil (PLMN) que se va a instalar. | | Instalar prioridad de red PLMN | Establece el nivel de prioridad para la red PLMN especificada. | | Instalar modo de red PLMN | Especifica el modo de red para la configuración PLMN seleccionada. Las opciones disponibles son **GMS**, **WCDMA**, **LTE**, **NR** o **Modo cuádruple**. | **Configuración de entrada** | Ajuste | Descripción | | --- | --- | | IME predeterminado | Introduce el nombre de paquete de la app que se usará como editor de métodos de entrada predeterminado. | | Idioma | Especifica el idioma del sistema que se usará en el dispositivo. | | Corrector ortográfico | Activa esta opción para habilitar el corrector ortográfico. | | Velocidad del puntero | Ajusta la velocidad del puntero en el dispositivo. Puedes establecer cualquier valor entre **–7 y 7**. | | Desactivar servicio de autocompletar | Activa esta opción para desactivar el servicio de autocompletar del dispositivo. | **Configuración de notificaciones** | Ajuste | Descripción | | --- | --- | | Notificación en pantalla de bloqueo | Especifica si las notificaciones deben mostrarse cuando el dispositivo está en la pantalla de bloqueo. | **Configuración de ubicación** | Ajuste | Descripción | | --- | --- | | Modo de ubicación | Establece el modo de ubicación del dispositivo. Las opciones como DeviceOnly, BatterySaving y HighAccuracy ya no tienen significados distintos en Android 8 y versiones posteriores. En estas versiones, todas se interpretan simplemente como servicios de ubicación activados. | **Configuración de accesibilidad** | Ajuste | Descripción | | --- | --- | | Tipo de toque | Establece el tipo de toque del dispositivo. Los tipos de toque disponibles pueden variar según el modelo, así que verifica qué valores son compatibles con tu modelo específico. Las opciones disponibles son **Normal**, **Guante**, **Lápiz** y **Dedo**, junto con sus variantes correspondientes. | **Configuración de periféricos** | Ajuste | Descripción | | --- | --- | | Seleccionar formato de tecla | Define el formato de la tecla lateral. Las opciones disponibles son **SCAN/SCAN**, **SCAN/PTT**, **PTT/SCAN** y **PTT/PTT**. | | Modo DataWedge | Configura el modo DataWedge para código de barras. | | Clip flotante | Especifica si la función de clip flotante está activada. | | Configurar tecla PTT/Scan izquierda | Configura el comportamiento de la tecla PTT/Scan izquierda. Las opciones disponibles son **DISABLE**, **SCAN** y **PTT**. | | Configurar tecla PTT/Scan derecha | Configura el comportamiento de la tecla PTT/Scan derecha. Las opciones disponibles son **DISABLE**, **SCAN** y **PTT**. | | Usar tecla de volumen como tecla de escaneo | Especifica si la tecla de volumen debe funcionar como tecla de escaneo. | **Configuración de registros** | Ajuste | Descripción | | --- | --- | | Estado del registrador | Elige si iniciar o detener el registrador. | | Registro principal | Activa esta opción para incluir los registros principales del sistema. | | Registro del kernel | Activa esta opción para incluir los registros del kernel. | | Registro de radio | Activa esta opción para incluir los registros de radio. | | Registro de eventos | Activa esta opción para incluir los registros de eventos. | **Configuración de descarga de archivos** | Ajuste | Descripción | | --- | --- | | URL de origen del archivo a descargar | Especifica la URL de origen del archivo que se va a descargar. | | Ruta de destino del archivo descargado | Especifica la ruta de destino donde se guardará el archivo descargado. | **Configuración de restricciones** | Ajuste | Descripción | | --- | --- | | Bloquear tecla Inicio | Activa esta opción para bloquear la tecla Inicio. Cuando está activada, pulsar la tecla Inicio no tendrá ningún efecto. | | Bloquear tecla de apps recientes | Activa esta opción para bloquear la tecla de apps recientes, que normalmente muestra una vista en tarjeta de las apps usadas recientemente. | | Bloquear tecla de encendido | Activa esta opción para bloquear la tecla de encendido. Cuando está activada, pulsar la tecla de encendido no tendrá ningún efecto. | | Bloquear tecla Atrás | Activa esta opción para bloquear la tecla Atrás. Cuando está activada, pulsar la tecla Atrás no tendrá ningún efecto. | | Bloquear teclas de volumen | Activa esta opción para bloquear las teclas de volumen. Cuando está activada, pulsar las teclas de volumen no tendrá ningún efecto. | | Bloquear ajuste de modo vibración | Activa esta opción para impedir que el dispositivo entre en modo vibración. Cuando está bloqueado, el modo vibración no puede activarse con la combinación de volumen arriba + encendido. No compatible con Android 8 o inferior. | | Bloquear barra de estado | Especifica cómo se bloqueará la barra de estado. Las opciones disponibles son **Todo**, **Ninguno** y **Ajustes rápidos**. | | Desactivar modo de recuperación | Activa esta opción para desactivar el acceso al modo de recuperación. | | Desactivar modo Fastboot | Activa esta opción para desactivar el acceso al modo Fastboot. | | Bloquear añadir usuario/invitado | Activa esta opción para impedir que se añadan nuevos usuarios o invitados al dispositivo. | | Desactivar pantalla de bloqueo | Activa esta opción para desactivar la pantalla de bloqueo del dispositivo. | | No permitir transferencia de archivos por USB | Activa esta opción para impedir la transferencia de archivos por USB. | | No permitir Bluetooth | Activa esta opción para desactivar el Bluetooth. | | No permitir cambio de puntos de acceso Wi-Fi | Activa esta opción para impedir que el dispositivo cambie de punto de acceso Wi-Fi. | | No permitir memoria externa montada | Activa esta opción para impedir el acceso a la memoria externa montada. | | No permitir montaje USB OTG | Activa esta opción para impedir el montaje USB OTG. | | No permitir acceso a ajustes | Activa esta opción para bloquear el acceso a los ajustes del dispositivo. | | Desactivar micrófono y grabación de audio | Activa esta opción para bloquear toda la funcionalidad de micrófono y grabación de audio del dispositivo. | | Desactivar micrófono y grabación durante llamadas | Activa esta opción para desactivar el micrófono y la grabación de audio durante las llamadas cuando el micrófono/audio está bloqueado. | | Lista de paquetes excluidos de la restricción de micrófono/audio | Introduce una lista de nombres de paquete separados por comas para apps que quedan exentas de las restricciones de micrófono/audio. | | Desactivar cámara | Activa esta opción para bloquear la cámara del dispositivo. | | Lista de paquetes excluidos de la restricción de cámara | Introduce una lista de nombres de paquete separados por comas para apps que quedan exentas de las restricciones de cámara. | | Desactivar ajustes del gestor de batería | Activa esta opción para bloquear la app Battery Manager. | | No permitir sensor de proximidad durante llamadas | Activa esta opción para bloquear el sensor de proximidad durante las llamadas. No compatible con Android 8 e inferior. | | No permitir NFC | Activa esta opción para bloquear NFC. | | No permitir modo avión | Activa esta opción para bloquear el modo avión. | | No permitir añadir varios usuarios | Activa o desactiva la posibilidad de añadir varios usuarios. | | No permitir modo No molestar | Activa esta opción para bloquear el modo No molestar. | | No permitir rotación automática | Activa o desactiva la rotación automática de pantalla. | | No permitir ahorro de batería | Activa esta opción para bloquear el ahorro de batería. | | No permitir itinerancia de datos | Activa esta opción para bloquear la itinerancia de datos. | | No permitir datos móviles | Activa esta opción para bloquear los datos móviles. | **Configuración del sistema** | Ajuste | Descripción | | --- | --- | | Establecer nombre del dispositivo | Especifica el nombre del dispositivo. | | Ocultar hotseat | Oculta el hotseat en el lanzador. | | **Configurar una lista de certificados a instalar** | | | URL de descarga del archivo de certificado | Introduce la URL para descargar el archivo de certificado. | | Nombre del certificado | Introduce el nombre del certificado. | | Tipo MIME del certificado | Introduce el tipo MIME del certificado. Las opciones disponibles son **CA-CERT**, **PKCS12** o **Wi-Fi-CONFIG**. | | Contraseña del certificado | Introduce la contraseña del certificado. | | **Actualizar firmware SLED** | | | URL del archivo de firmware | Especifica la ruta de destino donde se guardará el archivo descargado. | | Tipo de SLED | Especifica el tipo de LED del escáner. Las opciones disponibles son **RFR900**, **RFR901** y **RFR971**. | | Versión del archivo de firmware | Introduce la versión del firmware. | | Hora de inicio de la actualización (hora) | Establece la hora de inicio de la actualización del firmware. | | Hora de inicio de la actualización (minuto) | Establece el minuto de inicio de la actualización del firmware. | **Configuración de código de barras** | Ajuste | Descripción | | --- | --- | | Paso de código de barras | Añade y configura una lista de perfiles de código de barras. | --- ## Desplegar y configurar Zebra OEMConfig Source: https://docs.applivery.com/es/device-management/android/oem-configs/deploy-and-configure-zebra-oemconfig/ Description: Despliega y configura Zebra OEMConfig con Applivery para gestionar dispositivos Android Zebra de forma remota, aplicar políticas y optimizar el rendimiento. TL;DR: Configura y gestiona dispositivos Android Zebra de forma remota con Zebra OEMConfig y Applivery para aplicar políticas y optimizar el rendimiento del dispositivo. Answers: ¿Qué es Zebra OEMConfig? · ¿Qué versión de Android se requiere para Zebra OEMConfig Powered by MX? · ¿Cómo instalo Zebra OEMConfig a través de Applivery? · ¿Dónde configuro los ajustes de Zebra OEMConfig en Applivery? · ¿Cuál es el nombre del paquete para Zebra OEMConfig Powered by MX? · ¿Qué es Legacy Zebra OEMConfig? · ¿Son compatibles los ajustes de Configuración de Device Central en dispositivos TC20 y TC25? · ¿Qué opciones de emparejamiento Bluetooth están disponibles en Configuración de Device Central? Key topics: Zebra OEMConfig, Integración con Applivery, Android Enterprise, Configuración de políticas de dispositivos, Gestión remota de dispositivos, Zebra Technologies, Applivery, TC20, TC25 ![Zebra_Logo](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/d2f94e8a-1cd9-46d0-8757-5404f160c92a.png) **Zebra OEMConfig** es la solución de configuración de nivel empresarial de Zebra que permite a los administradores de TI gestionar y personalizar de forma remota los dispositivos Android Zebra a nivel de sistema. Al aprovechar el marco de configuraciones gestionadas de Android Enterprise, Zebra OEMConfig permite un control preciso sobre el hardware, software y ajustes de dispositivos específicos de Zebra, todo ello sin necesidad de apps personalizadas ni agentes adicionales. Mediante la integración con Applivery, los administradores pueden definir, desplegar y aplicar sin problemas políticas de dispositivos avanzadas, como configuraciones de red, gestión de apps, controles de seguridad, comportamiento de la pantalla y restricciones de modo quiosco. Esta integración garantiza el pleno cumplimiento de los estándares organizativos, optimiza el rendimiento de los dispositivos y ofrece una gestión coherente y optimizada en toda la flota de dispositivos Zebra. Nota Para instalar la app **Zebra OEMConfig Powered by MX** a través de Applivery, los dispositivos Zebra deben ejecutar **Android 11 o superior**. Para los dispositivos que no cumplan este requisito, existe una versión alternativa, **Legacy Zebra OEMConfig**, para configurar propiedades gestionadas en versiones anteriores de Android. ### Primeros pasos Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a cualquiera de tus **Políticas** 1. Desde el menú lateral izquierdo, dirígete a **Apps** 2 y haz clic en el botón **+ Añadir App** 3. ![add app](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/99357efb-6f20-4548-a9c9-d0df179cd02e.png) Busca la app **Zebra OEMConfig Powered by MX** y selecciona la de **Zebra Technologies** (nombre del paquete: `com.zebra.oemconfig.release`). Establece el **Tipo de instalación** en **Forzar instalación** para asegurar que la app se instale automáticamente en cualquier dispositivo asociado a la política. Una vez que la app aparezca en la lista, haz clic en ella para expandir todas las **propiedades gestionadas** y configurarlas según tus requisitos. ![zebra oemconfig](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/e09a61c8-3551-44c8-85a8-46fcb7537e54.png) :::warning Los ajustes específicos del OEM descritos en este documento son definidos y mantenidos por sus respectivos proveedores OEM, y pueden cambiar periódicamente. Dado que estas configuraciones se gestionan externamente, las opciones y los valores mostrados en el panel de Applivery pueden diferir ocasionalmente ligeramente de los que se muestran en esta documentación. ::: **Configuración de Device Central** No compatible con TC20 y TC25.

Ajustes

Descripción

Control de emparejamiento Bluetooth

Define cómo el subsistema Device Central gestiona el emparejamiento Bluetooth. Elige una de las siguientes opciones: Emparejamiento único por clase de dispositivo (permite solo un emparejamiento activo a la vez para cada clase de dispositivo Bluetooth), Múltiples emparejamientos por clase de dispositivo (permite múltiples emparejamientos simultáneos para cada clase de dispositivo Bluetooth). Compatible a partir de MX 8.1.

Control de usuario del estado de Bluetooth

Selecciona si los usuarios tienen permiso para usar la interfaz de usuario de Device Central para activar o desactivar Bluetooth. Compatible a partir de MX 8.1.

Control de usuario de la actualización de firmware

Selecciona si los usuarios pueden usar el botón de actualización de firmware para realizar actualizaciones de firmware a través del subsistema Device Central. Compatible a partir de MX 8.1.

Smart Leash

Estado

Selecciona si Smart Leash está activado o desactivado. Compatible a partir de MX 10.2.

Acceso de usuario a la sección Smart Leash

Selecciona si el usuario del dispositivo puede acceder a la interfaz de usuario de Device Central para configurar los ajustes de Smart Leash. Compatible a partir de MX 10.2.

Estado de la retroalimentación de audio

Selecciona si la retroalimentación de audio de Smart Leash está activada o desactivada. Compatible a partir de MX 10.2.

Sonido de la retroalimentación de audio

Especifica un tono de llamada existente o la ruta a un archivo de audio para reproducir cuando la retroalimentación de audio de Smart Leash esté activada. Compatible a partir de MX 10.2.

Volumen de la retroalimentación de audio

Especifica el nivel de volumen (porcentaje) del sonido cuando la retroalimentación de audio de Smart Leash esté activada. Compatible a partir de MX 10.2.

Recuento de repeticiones de la retroalimentación de audio

Introduce el número de veces que el sonido debe repetirse cuando la retroalimentación de audio de Smart Leash esté activada. Compatible a partir de MX 10.2.

Estado de la retroalimentación háptica

Selecciona si la retroalimentación háptica de Smart Leash está activada o desactivada. Compatible a partir de MX 10.2.

Tiempo de la retroalimentación háptica

Especifica la duración de la vibración cuando la retroalimentación háptica de Smart Leash esté activada. Compatible a partir de MX 10.2.

**Configuración de archivos**

Ajustes

Descripción

Ruta y nombre del dispositivo

Especifica la ruta y el nombre del archivo dentro del sistema de archivos del dispositivo, o el nombre del paquete de la app de destino, del único archivo que se gestionará en el dispositivo. No compatible con dispositivos TC20 y TC25.

Opciones de descarga de configuración de archivos

Añade uno o más elementos de opción de descarga para configurar cómo se descargan los archivos al dispositivo. Selecciona el tipo de opción de descarga que se aplicará al descargar un solo archivo. Las opciones disponibles son En el servidor, En el servidor pero no en el dispositivo. No compatible con dispositivos TC20 y TC25. Compatible a partir de MX 5.0.

URI del servidor de descarga

Especifica la URI del servidor desde el que se puede descargar un solo archivo al sistema de archivos del dispositivo. No compatible con dispositivos TC20 y TC25. Compatible a partir de MX 11.3.

Firma de la app de descarga

Introduce la firma digital de la app de destino asociada a la descarga. Compatible a partir de MX 11.3.

Persistencia del archivo de descarga

Selecciona si el archivo descargado debe permanecer almacenado en el dispositivo después de un restablecimiento empresarial. Compatible a partir de MX 11.3.

Opciones de carga de configuración de archivos

Añade uno o más elementos de opción de carga para configurar cómo se cargan los archivos desde el dispositivo. Selecciona el tipo de opción de carga que se aplicará al gestionar un solo archivo en el sistema de archivos del dispositivo. Las opciones disponibles son No en el servidor, Ordenado por nombre. No compatible con dispositivos TC20 y TC25. Compatible a partir de MX 10.1.

Patrón de nombre de archivo de carga

Introduce un patrón de nombres que se utilizará para los archivos cargados desde el sistema de archivos del dispositivo al servidor.

URI del servidor de carga

Especifica la URI del servidor donde se cargarán los archivos del sistema de archivos del dispositivo.

Opciones de eliminación de configuración de archivos

Añade uno o más elementos de opción de eliminación para configurar cómo se eliminan los archivos del sistema de archivos del dispositivo. Selecciona el tipo de opción de eliminación que se aplicará al gestionar un solo archivo. Las opciones disponibles son Siempre, Después del reinicio. No compatible con dispositivos TC20 y TC25. Compatible a partir de MX 5.0.

**Asignaciones de teclado** No compatible con dispositivos TC20 y TC25.

Ajustes

Descripción

ID de clave

Selecciona el identificador de clave que corresponde de forma única a una tecla física del teclado de hardware del dispositivo para reasignarla.

Comportamientos de asignación de teclas

Añade uno o más elementos de comportamiento para definir el comportamiento deseado de reasignación de teclas.

**Gestión de licencias**

Ajustes

Descripción

Persistencia del restablecimiento empresarial

Selecciona si todas las licencias de Zebra deben permanecer almacenadas localmente en el dispositivo después de un restablecimiento empresarial. Compatible a partir de MX 11.2.

URL del proxy del servidor de licencias

Introduce la URL del servidor proxy utilizada para gestionar las solicitudes de licencias. (Opcional — requiere ZLicenseMgr v14.0.). Compatible a partir de MX 14.0.

Tipo de servidor en la nube de licencias de insignia

Selecciona el servidor de origen desde el que se obtendrá una licencia de capacidad de Zebra. Las opciones disponibles son Nube de producción, Nube de prueba. Compatible a partir de MX 14.0.

ID de insignia de licencias

Introduce el ID de insignia emitido por Zebra para el grupo de licencias desde el que se emitirán las licencias. Compatible a partir de MX 14.0.

Productos

Añade detalles de licencia para desplegar en el dispositivo. Compatible a partir de MX 14.0.

Licencia LLS

Abre esta sección para configurar la URL del servidor local y la información de la licencia. Requiere ZLicenseMgr v14.5. Compatible a partir de MX 14.0.

Licencias

Añade uno o más elementos de Configuración de licencia – Licencias – Licencia. Compatible a partir de MX 14.0.

Características

Añade uno o más elementos de Configuración de licencia – Características – Característica. Compatible a partir de MX 14.0.

**Configuración de PKG**

Ajustes

Descripción

Nombre de clase

Introduce el nombre de clase dentro del paquete de Android para el que se deben configurar uno o más comportamientos no predeterminados y específicos de la clase. Compatible a partir de MX 4.3.

Nombre del paquete

Introduce el nombre del paquete de la app de Android para la que se deben configurar uno o más comportamientos no predeterminados.

Certificado de firma del paquete

Introduce el certificado de firma del paquete utilizado para verificar que el paquete de Android identificado por el nombre del paquete es una instancia genuina y de confianza de ese paquete.

Permisos del paquete

Añade uno o más elementos de permiso para configurar los permisos del paquete especificado. Compatible a partir de MX 10.4.

Variaciones de clase del paquete

Añade uno o más elementos de variación de clase para configurar variaciones de comportamiento específicas de la clase.

Variaciones de características del paquete

Añade uno o más elementos de variación de características para configurar variaciones de comportamiento específicas de la característica.

Servicios permitidos del paquete

Añade uno o más elementos de servicio permitido para definir los servicios a los que el paquete tiene permiso para acceder. Compatible a partir de MX 8.3.

**Configuración de seguridad y privacidad**

Ajustes

Descripción

Configuración de cifrado: Configura las claves de cifrado y el nombre de la clave de cifrado de la tarjeta SD. No compatible con dispositivos TC20 y TC25.

Claves de cifrado de seguridad

Añade uno o más elementos de clave de cifrado para configurar las claves de cifrado. Compatible a partir de MX 4.3.

Nombre de clave

Introduce el nombre de clave de una clave de cifrado definida (con nombre).

Valor de clave

Introduce el valor de clave asociado al nombre de clave de cifrado especificado.

Nombre de clave de cifrado de tarjeta SD

Introduce el nombre de clave de la clave de cifrado utilizada para cifrar la tarjeta SD extraíble. Compatible a partir de MX 4.3.

Configuración de bloqueo de pantalla. No compatible con dispositivos TC20 y TC25.

Bloqueo instantáneo de pantalla con la tecla de encendido

Selecciona si el dispositivo debe bloquearse instantáneamente cuando se utiliza la tecla de encendido para apagar la pantalla. Compatible a partir de MX 4.3.

Fondo de pantalla de bloqueo

Selecciona la imagen de fondo de pantalla que se mostrará en la pantalla de bloqueo. Las opciones disponibles son Restaurar a predeterminado y Personalizado. Compatible a partir de MX 10.5.

Fondo de pantalla de bloqueo personalizado

Introduce la ruta y el nombre de archivo de una imagen personalizada (.jpg o .png) almacenada en el dispositivo para usarla como fondo de pantalla de bloqueo. Compatible a partir de MX 10.5.

Tipo de bloqueo de pantalla

Selecciona el tipo de bloqueo de pantalla utilizado para proteger el dispositivo del acceso no autorizado. Las opciones disponibles son Ninguno, Deslizar, PIN, Contraseña y Patrón. Compatible a partir de MX 6.0.

Notificaciones en la pantalla de bloqueo

Selecciona el tipo de contenido de notificación que se mostrará en la pantalla de bloqueo. Las opciones disponibles son Mostrar todo el contenido, Mostrar solo contenido no sensible y Ocultar notificaciones. Compatible a partir de MX 10.5.

Visibilidad de la pantalla de bloqueo RC

Selecciona si la pantalla de bloqueo de Android debe ser visible en la consola remota cuando el dispositivo está siendo controlado de forma remota. Compatible a partir de MX 13.3.

Tiempo de espera de bloqueo de pantalla

Selecciona la acción que debe realizar el dispositivo cuando la pantalla se apaga debido a un tiempo de espera. Las opciones disponibles son Inmediatamente después del tiempo de espera de la pantalla, 5 segundos después del tiempo de espera de la pantalla, 15 segundos después del tiempo de espera de la pantalla, 30 segundos después del tiempo de espera de la pantalla, 1 minuto después del tiempo de espera de la pantalla, 2 minutos después del tiempo de espera de la pantalla, 5 minutos después del tiempo de espera de la pantalla, 10 minutos después del tiempo de espera de la pantalla y 30 minutos después del tiempo de espera de la pantalla. Compatible a partir de MX 4.3.

Selección de usuario de inicio seguro

Selecciona si el usuario puede habilitar el inicio seguro al cambiar su PIN, contraseña o patrón. Compatible a partir de MX 10.0.

Bloqueo de pantalla secundario

Selecciona si se debe activar un bloqueo de pantalla secundario (por ejemplo, Identity Guardian) en el dispositivo. Compatible a partir de MX 14.0.

Reiniciar

Selecciona si el dispositivo debe reiniciarse inmediatamente después de aplicar la configuración del bloqueo de pantalla secundario, o suprimir el reinicio para aplicar el cambio más tarde. Compatible a partir de MX 14.0.

Reloj de doble línea en la pantalla de bloqueo

Selecciona si el reloj de la pantalla de bloqueo debe mostrarse en una sola línea o en dos líneas con una fuente más grande (cuando el espacio lo permita). Compatible a partir de MX 14.1.

Notificación de configuración de tarjeta SD

Selecciona si se debe mostrar una notificación al usuario cuando se inserta una tarjeta SD en el dispositivo. Compatible a partir de MX 11.5.

| Ajustes | Descripción | | --- | --- | | \*\*Configuración de análisis\*\* | | | Estado de análisis | Selecciona si el cliente de análisis puede recopilar datos del dispositivo y enviarlos a Zebra. Compatible a partir de MX 4.3. | | Control de usuario del estado de análisis | Selecciona si el usuario puede controlar la capacidad del cliente de análisis para recopilar y transmitir datos del dispositivo a Zebra. Compatible a partir de MX 7.2. | | \*\*Configuración del reloj\*\* | | | Modo de hora | Selecciona si el modo de hora es \*\*Automático\*\* (hora establecida utilizando información obtenida de un servidor de hora) o \*\*Basado en reglas\*\* (hora establecida utilizando reglas y parámetros especificados). Compatible a partir de MX 4.2. | | Dirección del servidor NTP automático | Selecciona el umbral de deriva permitido en el que el dispositivo intentará automáticamente readquirir y restablecer la hora y la fecha cuando el modo de hora esté configurado en Automático. Compatible a partir de MX 4.2. | | Intervalo de deriva NTP automático | Selecciona el umbral de deriva permitido en el que el dispositivo intentará automáticamente readquirir y restablecer la hora y la fecha cuando el modo de hora esté configurado en Automático. Compatible a partir de MX 11.7. | | Intervalo de sincronización NTP automático | Selecciona el intervalo en el que el dispositivo intentará automáticamente sincronizar la hora y la fecha cuando el modo de hora esté configurado en Automático. Compatible a partir de MX 4.2. | | Modo de zona horaria | Selecciona si la zona horaria se establece manualmente (definida explícitamente) o automáticamente (basada en la información obtenida de la red del operador). Compatible a partir de MX 6.0. | | Zona horaria manual | Introduce la zona horaria que se aplicará cuando el modo de zona horaria esté configurado en Manual. | | Formato de hora | Selecciona el formato de visualización para la hora del sistema del dispositivo. Compatible a partir de MX 6.0. | | \*\*Configuración de borrado de datos. No compatible con dispositivos TC20 y TC25.\*\* | | | Tipo de opciones de borrado de datos | Añade uno o más elementos de opción de borrado de datos para definir cómo se deben borrar los datos del dispositivo. Selecciona un único método de borrado para determinar cómo se borrarán los datos del dispositivo. Las opciones disponibles son \*\*Almacenamiento principal\*\*, \*\*Almacenamiento persistente\*\* y \*\*Almacenamiento portátil\*\*. | | Omitir SUW en el restablecimiento empresarial | Selecciona si el Asistente de configuración de Google (SUW) debe omitirse al realizar un restablecimiento empresarial como parte de una operación de borrado de datos. | | \*\*Configuración de GMS. No compatible con dispositivos TC20 y TC25.\*\* | | | Conjunto de características GMS | Selecciona el conjunto de características GMS que se habilitará en el dispositivo. Las opciones disponibles son \*\*Todo\*\*, \*\*Restringido\*\* y \*\*Con perfil\*\*. | | Perfil GMS | Selecciona el perfil GMS que define el subconjunto de características GMS que se utilizarán. Las opciones disponibles son \*\*Navegador Chrome\*\*, \*\*Google Maps\*\*, \*\*Firebase Cloud Messaging\*\* y \*\*Combinación de Chrome, Maps y FCM\*\*. Compatible a partir de MX 8.3. | | \*\*Configuración de Fota\*\* | | | Modo de actualización | Selecciona cómo se aplican las actualizaciones de LifeGuard. Las opciones disponibles son \*\*Totalmente automático\*\*, \*\*Controlado por EMM\*\* y \*\*Actualizaciones basadas en archivos\*\*. No compatible con dispositivos TC20 y TC25. Compatible a partir de MX 11.1. | | Control de interfaz de usuario | Selecciona si el usuario puede modificar los ajustes de actualización de LifeGuard a través de la interfaz de usuario. No compatible con dispositivos TC20 y TC25. Compatible a partir de MX 9.1. | | Actualización por datos móviles | Selecciona si se permiten las actualizaciones automáticas de LifeGuard a través de redes móviles de pago. No compatible con dispositivos TC20 y TC25. Compatible a partir de MX 11.1. | | Opciones OTA | Introduce parámetros opcionales que controlan el comportamiento de actualización OTA. No compatible con dispositivos TC20 y TC25. Compatible para uso futuro. | | Fuente de actualización basada en archivos | Selecciona la fuente del archivo de actualización utilizado para las actualizaciones de SO basadas en archivos. No compatible con dispositivos TC20 y TC25. Compatible a partir de MX 8.1. | | Opciones de actualización basada en archivos | Añade uno o más elementos de opción de actualización para controlar el comportamiento de actualización basada en archivos. No compatible con dispositivos TC20 y TC25. Compatible a partir de MX 8.1. | | Suprimir reinicio | Selecciona si se debe evitar el reinicio automático después de una actualización A/B. No compatible con dispositivos TC20 y TC25. Compatible a partir de MX 8.1. | | Ruta y nombre local del archivo de actualización | Introduce la ruta y el nombre de archivo de un paquete de actualización local utilizado en las actualizaciones basadas en archivos. No compatible con dispositivos TC20 y TC25. Compatible a partir de MX 4.1. | | \*\*Configuración de streaming Fota\*\* | | | URL de origen | Introduce la URL donde se aloja el archivo de actualización. | | Tipo de autorización | Selecciona el método de autenticación requerido por el servidor remoto. Las opciones disponibles son \*\*Sin autorización\*\*, \*\*Token de autenticación de Zebra\*\*, \*\*Autenticación básica\*\* y \*\*Encabezado de autorización personalizado\*\*. | | Token de autenticación de Zebra | Introduce el token para la autenticación de Zebra Support Central. | | Nombre de usuario | Introduce el nombre de usuario autorizado para acceder al paquete de actualización. | | Contraseña | Introduce la contraseña para el nombre de usuario especificado. | | Encabezado de autenticación personalizado | Proporciona un valor de encabezado de autorización personalizado, si es necesario. | | \*\*Configuración de energía. No compatible con dispositivos TC20 y TC25.\*\* | | | \*\*Configuración de control automático\*\* | | | Estado | Selecciona si el control automático de energía está habilitado. | | Modo de encendido | Selecciona cuándo y cómo el dispositivo se encenderá automáticamente. | | Modo de apagado | Selecciona cuándo y cómo el dispositivo se apagará automáticamente. | | Tiempo de espera de apagado | Introduce el tiempo de espera antes de que el dispositivo se apague automáticamente. | | \*\*Configuración de batería\*\* | | | Umbral --- ## Samsung Knox E-FOTA Source: https://docs.applivery.com/es/device-management/android/oem-configs/samsung-knox-efota/ Description: Configura Samsung Knox E-FOTA con Applivery para gestionar de forma centralizada las actualizaciones del OS en dispositivos Samsung con instrucciones paso a paso. TL;DR: Gestiona de forma centralizada las actualizaciones del OS en dispositivos Samsung usando Knox E-FOTA y Applivery configurando una política de Android dedicada con el Knox Service Plugin. Answers: ¿Cómo configurar Knox E-FOTA con Applivery? · ¿Cuáles son los pasos para configurar Knox E-FOTA? · ¿Cómo crear una política de Applivery para Knox E-FOTA? · ¿Qué es el Knox Service Plugin y cómo usarlo? · ¿Cómo inscribir dispositivos en Knox E-FOTA usando Applivery? · ¿Cómo gestionar las actualizaciones del OS con Knox E-FOTA? · ¿Cómo evitar actualizaciones OTA fuera de Knox E-FOTA? · ¿Cuál es el nombre de paquete del Knox Service Plugin? Key topics: Configuración de Knox E-FOTA, Creación de políticas en Applivery, Configuración del Knox Service Plugin, Inscripción de dispositivos en E-FOTA, Samsung, Knox E-FOTA, Applivery, Android, Knox Service Plugin, OEMConfig Samsung Knox E-FOTA permite a los administradores de TI empresariales controlar de forma centralizada las versiones del sistema operativo y las actualizaciones de seguridad en dispositivos Samsung, sin requerir ninguna intervención del usuario. Esta capacidad permite a las organizaciones validar las actualizaciones del OS por adelantado, garantizar la compatibilidad con las aplicaciones internas y desplegar parches de seguridad en un calendario controlado, mejorando significativamente la estabilidad del dispositivo y la postura de seguridad de toda la flota. ### Configuración Para empezar, accede al [portal Samsung Knox Admin](https://samsungknox.com) e inicia sesión con una cuenta de administrador que tenga habilitados al menos los roles **Common Admin** y **E-FOTA Admin**. :::info Esta función requiere una licencia válida de **Knox Suite – Plan Enterprise** en el portal Samsung Knox E-FOTA. Se puede emitir una licencia de prueba gratuita para realizar pruebas usando el botón **ACCIONES** en el portal. ::: ![samsung knox](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/9b2d4df2-d57f-45a3-baf7-ee4f3b0b5de8.png) #### Preparar Applivery para Knox E-FOTA Para inscribir dispositivos Samsung compatibles en Knox E-FOTA a través de Applivery, debes crear una política de Android dedicada que incluya la aplicación **Samsung Knox Service Plugin** (**OEMConfig**). **Crear una nueva política** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), [crea una nueva política](https://docs.applivery.com/es/device-management/general-settings/create-policies/) desde la sección **Políticas** 1. Esta política debe usarse exclusivamente para la configuración de Knox E-FOTA. Dentro de la política, dirígete a la sección **Apps** 2 y haz clic en el botón **\+ Añadir App** 3. ![add app](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/8977cec7-2eb9-4d52-93ae-577c8d0312fb.png) **Añadir el Knox Service Plugin** Busca la app **Knox Service Plugin** (nombre de paquete: `com.samsung.android.knox.kpu`). Establece el **Tipo de instalación** en **Instalación forzada** para garantizar que la app se instale automáticamente en cualquier dispositivo asociado a la política. **Configurar el Knox Service Plugin** Una vez que la app aparezca en la lista, haz clic en ella para expandir todas las propiedades gestionadas y **asigna un nombre al perfil de configuración** 4. ![knox service plugin](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/580d3f7f-9075-4570-b98b-9ce003eabc06.png) :::info Por defecto, la app Knox Service Plugin está oculta para los usuarios cuando se aplica la configuración gestionada. Para realizar pruebas o validaciones, la visibilidad puede habilitarse activando la opción **Debug** 5 dentro de la configuración gestionada. ::: #### Habilitar los controles de firmware y E-FOTA **Habilitar los controles de política del dispositivo** Continúa desplazándote hasta la sección **Políticas** y **habilita los controles de política del dispositivo** 6. ![enable device policy controls](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/da04c7ce-bb29-4c25-83c0-7ad7273e8b06.png) **Habilitar los controles de firmware e instalación e inicio del cliente E-FOTA** A continuación, en la sección **Actualización Fota**, activa tanto **Habilitar controles de firmware** 7 como **Habilitar instalación e inicio del cliente E-FOTA** 8. **Configurar las actualizaciones OTA (opcional)** Opcionalmente, puedes controlar si los dispositivos pueden recibir actualizaciones OTA estándar fuera de Knox E-FOTA configurando el ajuste **Permitir actualización de firmware OTA** 9. ![do fota update](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/04e58702-3d4c-4fec-a1c9-fae4f2310e10.png) **Asignar la política** Una vez completado, asigna esta política a los dispositivos Samsung correspondientes usando tu método de asignación preferido. :::info Asegúrate de que esta política de Knox E-FOTA tenga **una prioridad más alta** que tu política de Android habitual para evitar conflictos de configuración. ::: ### Registro de dispositivos y gestión de campañas Tras aplicar la política, la app OEMConfig Knox Service Plugin se instala junto con su configuración gestionada. Esto activa la instalación automática del **cliente Knox E-FOTA** y los dispositivos se registran silenciosamente en el **portal Samsung Knox E-FOTA**. ![samsung knox all devices](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/108bba6a-b713-4d61-8900-023012274a2c.png) A partir de ese momento, los administradores de E-FOTA pueden **crear y gestionar campañas de actualización por modelo de dispositivo**, **aplicar versiones específicas del OS o del firmware** y **establecer restricciones de actualización** según los requisitos de la organización. Para más información sobre las capacidades de Knox E-FOTA, consulta la [documentación oficial de Samsung](https://docs.samsungknox.com/admin/knox-efota/). Para instrucciones detalladas sobre cómo crear y gestionar campañas, consulta la documentación de Samsung [Create a campaign](https://docs.samsungknox.com/admin/knox-efota/features/create-a-campaign/create-a-campaign/). --- ## Actualizar Zebra con Legacy OEMConfig Source: https://docs.applivery.com/es/device-management/android/oem-configs/update-zebra-legacy-oemconfig/ Description: Actualiza el firmware en dispositivos Zebra (Android 11 o anterior) utilizando Legacy Zebra OEMConfig a través de Applivery MDM. TL;DR: Actualiza fácilmente dispositivos Zebra antiguos usando Legacy Zebra OEMConfig y Applivery con esta guía paso a paso para configurar actualizaciones de firmware. Answers: ¿Qué es Legacy Zebra OEMConfig? · ¿Cómo añado Legacy Zebra OEMConfig a mi política? · ¿Qué es la 'Ruta de destino y nombre de archivo de descarga' en el Paso de archivos? · ¿Qué tipo de servicio de alojamiento se requiere para el archivo de actualización? · ¿Qué es el campo 'Archivo de actualización del SO' en el Paso FOTA? · ¿Qué hace 'Suprimir reinicio de actualización del SO'? · ¿Cómo sabré cuándo comienza la actualización del dispositivo Zebra? · ¿La actualización a Android 13 o superior provocará un restablecimiento de fábrica? Key topics: Legacy Zebra OEMConfig, Actualizaciones Firmware Over-The-Air (FOTA), Gestión de dispositivos Android, Integración con Applivery, Zebra, Android, Applivery, Amazon S3 Gestionar y actualizar **dispositivos Zebra con Android 11 o anterior** presenta desafíos específicos para los administradores de movilidad y TI. El **Legacy Zebra OEMConfig**, integrado con Applivery, permite **actualizaciones de firmware**, **gestión de la configuración** y **control de dispositivos** centralizados y fiables. :::warning Ten en cuenta que esta versión de la app Legacy Zebra OEMConfig requiere Android 11 o inferior. Si tus dispositivos ejecutan una versión superior de Android, utiliza la última app [Zebra OEMConfig](https://docs.applivery.com/es/device-management/android/oem-configs/update-zebra-oemconfig/) en su lugar. ::: ### Primeros pasos Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a cualquiera de tus **Políticas** 1. Desde el menú lateral izquierdo, dirígete a **Apps** 2 y haz clic en el botón **\+ Añadir App** 3. ![add app](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/f5d1573d-02cc-4da9-bd64-65951a5c94b3.png) Añade la app **Legacy Zebra OEMConfig** (`com.zebra.oemconfig.common`) a tu política a través del **Managed Google Play iFrame**. Una vez que la app ha sido añadida, abre sus propiedades gestionadas y haz clic en **\+ Añadir elemento** bajo la sección **Pasos**. **Paso de archivos** Localiza la sección **Paso de archivos** y configura los campos de la siguiente manera: - **Ruta de destino y nombre de archivo de descarga**: Especifica la ruta y el nombre del archivo de actualización (por ejemplo, `/data/tmp/public/Android14AT_FULL_UPDATE_14-28-03.00-UG-U133-STD-ATH-04.zip`). - **URI de origen del archivo de descarga**: Introduce la URL del archivo de actualización alojado. Asegúrate de que sea un servicio de alojamiento privado que admita **descargas directas** (por ejemplo, para Amazon S3: `https://your-bucket-name.s3.amazonaws.com/Android14AT_FULL_UPDATE_14-28-03.00-UG-U133-STD-ATH-04.zip`). ![files step](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/0bda5c98-0eaa-41d7-8b08-ff972be5acfe.png) Una vez configurada, la app Legacy Zebra OEMConfig descargará automáticamente el paquete ZIP de actualización a la ruta especificada. **Paso FOTA** A continuación, localiza la sección **Paso FOTA** y configura los campos de la siguiente manera: - **Servicio OTA LifeGuard**: Activado. - **Archivo de actualización del SO**: Especifica la misma ruta y nombre de archivo que arriba. - **Suprimir reinicio de actualización del SO**: Decide si deseas evitar el reinicio automático después de la actualización. ![fota step](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/21204c8f-fd86-4c7c-af83-21f6f016ae8c.png) :::info Dependiendo del modelo de dispositivo, la actualización de Android 10 o anterior a Android 13 o superior puede activar un restablecimiento de fábrica automático. Obtén más información en la [documentación oficial de Zebra](https://techdocs.zebra.com/lifeguard/a13/#migrationprocess). ::: Una vez que estos parámetros estén configurados y el paquete ZIP se haya descargado completamente en la ruta especificada en la sección **Paso de archivos**, el dispositivo Zebra iniciará automáticamente el proceso de actualización de forma **silenciosa**. Puedes verificar esto a través de una **notificación silenciosa** que aparece en el panel de notificaciones del dispositivo. Cuando la actualización se complete, si **Suprimir reinicio de actualización del SO** está configurado como **True**, el usuario debe **reiniciar manualmente** el dispositivo para finalizar la instalación. Siguiendo los pasos descritos, desde la configuración de las propiedades gestionadas hasta la definición de los parámetros de actualización y las opciones de reinicio, garantizas un proceso de actualización **fluido**, **fiable** y **sin errores**. --- ## Actualizar Zebra con Zebra OEMConfig Source: https://docs.applivery.com/es/device-management/android/oem-configs/update-zebra-oemconfig/ Description: Actualiza dispositivos Zebra de forma remota con Zebra OEMConfig en Applivery MDM. Actualizaciones de firmware automatizadas para toda la flota. TL;DR: Actualiza dispositivos Zebra de forma remota con Zebra OEMConfig y Applivery MDM para despliegues de firmware seguros y automatizados. Answers: ¿Cómo actualizo dispositivos Zebra de forma remota? · ¿Qué versión de Android se requiere para la app Zebra OEMConfig? · ¿Cómo añado la app Zebra OEMConfig a mi política? · ¿Dónde especifico la ruta del archivo de actualización en Zebra OEMConfig? · ¿Qué opción de descarga debo usar para el archivo de actualización en Zebra OEMConfig? · ¿Qué modo de actualización debo seleccionar en la sección Configuración FOTA? · ¿Cómo evito el reinicio automático después de una actualización de dispositivo Zebra? · ¿Cómo sabré cuándo se ha completado la actualización del dispositivo Zebra? Key topics: Configuración de Zebra OEMConfig, Configuración de archivos, Configuración FOTA, Actualizaciones remotas de dispositivos, Applivery MDM, Zebra, Zebra OEMConfig, Applivery, Android, Managed Google Play iFrame, Amazon S3 Con esta integración, los administradores pueden desplegar y gestionar de forma remota actualizaciones de sistema y firmware de manera **segura**, **automatizada** y **controlada**, minimizando el tiempo de inactividad y asegurando la coherencia de los dispositivos en toda la flota. :::warning Ten en cuenta que esta versión de la app Zebra OEMConfig requiere **Android 11 o superior**. Si tus dispositivos ejecutan una versión anterior de Android, utiliza la app [**Legacy Zebra OEMConfig**](https://docs.applivery.com/es/device-management/android/oem-configs/update-zebra-legacy-oemconfig/) en su lugar. ::: ### Primeros pasos Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a cualquiera de tus políticas 1. Desde el menú lateral izquierdo, dirígete a **Apps** 2 y haz clic en el botón **\+ Añadir App** 3. ![add app](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/7d1537d3-432f-410b-8331-dc7a98f18f2b.png) Añade la app **Zebra OEMConfig Powered by MX** (`com.zebra.oemconfig.release`) a tu política a través del **Managed Google Play iFrame**. Una vez añadida la app, abre sus propiedades gestionadas y haz clic en **\+ Añadir elemento** en la sección **Files Config**. **Configuración de archivos** Configura los campos de la siguiente manera: - **Ruta y nombre del dispositivo**: Especifica la ruta y el nombre del archivo de actualización (p. ej., `/data/tmp/public/Android14AT_FULL_UPDATE_14-28-03.00-UG-U133-STD-ATH-04.zip`). - **Opciones de descarga de configuración de archivos**: - **Tipo de opción de descarga**: En servidor. - **URI del servidor de descarga**: Introduce la URL del archivo de actualización alojado. Asegúrate de que sea un servicio de alojamiento privado que admita **descargas directas** (p. ej., para Amazon S3: `https://your-bucket-name.s3.amazonaws.com/Android14AT_FULL_UPDATE_14-28-03.00-UG-U133-STD-ATH-04.zip`). ![files config](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/7ef17b6f-3892-44d1-9d73-d3ff66981414.png) Una vez configurada, la app Zebra OEMConfig descargará automáticamente el paquete ZIP de actualización a la ruta especificada. **Configuración FOTA** A continuación, localiza la sección **Configuración FOTA** y configura los campos de la siguiente manera: - **Modo de actualización**: Actualizaciones basadas en archivos. - **Fuente de actualización basada en archivos**: Archivo de actualización local. - **Opciones de actualización FOTA**: - **Tipo de opción de actualización basada en archivos**: Discrepancia de versión. - **Versión de discrepancia**: Introduce la versión del sistema que el dispositivo reportará después de la actualización. - **Ruta y nombre local del archivo de actualización**: Especifica la misma ruta y nombre de archivo que arriba. - **Actualizar por datos móviles**: Elige si se permiten las actualizaciones por datos móviles. - **Suprimir reinicio**: Decide si quieres evitar el reinicio automático después de la actualización. ![fota config](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/74a48198-e6d9-4f5b-9115-ab77f5a88a7a.png) Una vez configurados estos parámetros y descargado completamente el paquete ZIP en la ruta especificada en la sección **Configuración de archivos**, el dispositivo Zebra iniciará automáticamente el proceso de actualización de forma **silenciosa**. Puedes verificar esto a través de una **notificación silenciosa** que aparece en el panel de notificaciones del dispositivo. Cuando la actualización se complete, si **Suprimir reinicio** está configurado en **True**, el usuario debe **reiniciar manualmente** el dispositivo para finalizar la instalación. Siguiendo los pasos descritos —desde la configuración de propiedades gestionadas hasta la definición de parámetros de actualización y opciones de reinicio—, aseguras un proceso de actualización **fluido**, **fiable** y **sin errores**. --- ## Configurar zona horaria en Zebra Source: https://docs.applivery.com/es/device-management/android/oem-configs/zebra-time-zone-configuration/ Description: Configura la zona horaria y el servidor NTP en dispositivos Zebra con las apps Zebra OEMConfig y Legacy Zebra OEMConfig de Applivery. TL;DR: Configura la zona horaria y el servidor NTP en dispositivos Zebra con las apps Zebra OEMConfig (Android 11+) y Legacy Zebra OEMConfig (anteriores) para una sincronización precisa. Answers: ¿Cómo se configura la zona horaria en dispositivos Zebra? · ¿Qué app OEMConfig de Zebra usar para Android 11 o anterior? · ¿Qué app OEMConfig de Zebra usar para Android 11 o superior? · ¿Cuál es la dirección del servidor NTP para dispositivos Zebra? · ¿Con qué frecuencia deben sincronizarse los dispositivos Zebra con el servidor NTP? · ¿Cómo se establece la zona horaria manualmente en Zebra OEMConfig? · ¿Dónde se añaden las apps Zebra OEMConfig? · ¿Qué formatos de hora están disponibles en Zebra OEMConfig? Key topics: Zebra OEMConfig, Legacy Zebra OEMConfig, Configuración de zona horaria, Configuración de servidor NTP, Gestión de dispositivos Android, Zebra, Android, NTP, Managed Google Play iFrame A veces, pequeños detalles, como la hora correcta en un dispositivo, pueden marcar una gran diferencia en las operaciones diarias de una empresa. Mantener todos los dispositivos sincronizados ayuda a prevenir confusiones y asegura que las apps funcionen sin problemas. Puedes cambiar la zona horaria y configurar el servidor NTP en dispositivos Zebra con las apps Zebra OEMConfig y Legacy Zebra OEMConfig, que te permiten aplicar configuraciones avanzadas de forma centralizada en tus dispositivos. Este proceso asegura que todos los dispositivos mantengan la hora correcta según su ubicación o la política de sincronización de tu empresa, evitando desajustes en registros, comunicaciones o apps críticas. Es importante saber cuándo y en qué dispositivos usar cada app. Dependiendo de la versión del sistema operativo Android, necesitarás usar la versión Legacy o la actual de Zebra OEMConfig. Los pasos para configurar la zona horaria variarán ligeramente según la app que utilices. ### Legacy Zebra OEMConfig (Android 11 o anterior) Para dispositivos con Android 11 o anterior, utiliza la app Legacy Zebra OEMConfig para configurar la zona horaria. Añade la app a tu política a través del Managed Google Play iFrame. Si necesitas ayuda con este paso, puedes encontrar más información [aquí](https://docs.applivery.com/es/device-management/android/oem-configs/update-zebra-legacy-oemconfig/). Una vez que la app haya sido añadida, abre sus propiedades gestionadas y haz clic en **+ Añadir elemento** bajo la sección **Pasos** 1. ![steps](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/c5b9ffc1-6ac8-485a-95c8-9ed775048d2e.png) Ahora se mostrarán las opciones de configuración. Con tantas configuraciones, desplazarse por ellas puede llevar mucho tiempo. Para encontrar la sección que necesitas de forma más eficiente, utiliza la función de búsqueda para localizar **Clock step**. ![clock step](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/2a73ebbd-e73c-4e67-be80-d7ef80c43f0a.png) Configura los campos de la siguiente manera: - **Modo de hora**: Automático. - **Fecha manual**: Deja como está. - **Hora manual**: Deja como está. - **Fecha UTC manual**: Deja como está. - **Hora UTC manual**: Deja como está. - **Dirección del servidor NTP automático**: `ntp.pool.org`. - **Intervalo de sincronización NTP automático**: Define la frecuencia con la que la app se conecta al servidor NTP para actualizar la hora. Selecciona el intervalo que mejor se adapte a tus necesidades. - **Modo de zona horaria**: Manual. - **Zona**: Introduce la zona horaria adecuada (por ejemplo, `America/New_York`). - **Formato de hora**: Elige cómo se mostrará la hora — **12h** o **24h**. Una vez guardados los cambios, todos los dispositivos vinculados a esta política tendrán instalada la app Legacy Zebra OEMConfig. Basándose en la configuración definida en sus propiedades gestionadas, la app se conectará automáticamente al servidor NTP y aplicará la fecha y hora correctas según la zona horaria especificada. ### Zebra OEMConfig con tecnología MX (Android 11 o superior) Para dispositivos con Android 11 o superior, utiliza la versión actual de la app Zebra OEMConfig para configurar la zona horaria. Añade la app a tu política a través del Managed Google Play iFrame. Si necesitas ayuda con este paso, puedes encontrar más información [aquí](https://docs.applivery.com/es/device-management/android/oem-configs/update-zebra-oemconfig/). Una vez que la app haya sido añadida, utiliza la función de búsqueda para localizar **Clock Config**. Configura los campos de la siguiente manera: - **Modo de hora**: Automático. - **Dirección del servidor NTP automático**: `ntp.pool.org`. - **Intervalo de deriva NTP automático**: Deja como está. - **Intervalo de sincronización NTP automático**: Define la frecuencia con la que la app se conecta al servidor NTP para actualizar la hora. Selecciona el intervalo que mejor se adapte a tus necesidades. - **Modo de zona horaria**: Manual. - **Zona horaria manual**: Introduce la zona horaria adecuada (por ejemplo, `America/New_York`). - **Formato de hora**: Elige cómo se mostrará la hora — **12h** o **24h**. ![clock config](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/937661c8-83fb-4845-a193-8825578c6772.png) Una vez guardados los cambios, todos los dispositivos vinculados a esta política tendrán instalada la app Zebra OEMConfig. Basándose en la configuración definida en sus propiedades gestionadas, la app aplicará la fecha y hora de la zona horaria especificada. Como puedes ver, configurar correctamente la zona horaria y el servidor NTP en dispositivos Zebra es sencillo, y asegura que todos los dispositivos permanezcan sincronizados, evitando errores de registro, problemas de comunicación y fallos en apps críticas. Con las apps Zebra OEMConfig y Legacy Zebra OEMConfig, este proceso se puede gestionar de forma centralizada y adaptar a la versión de Android de cada dispositivo, ayudándote a mantener un entorno consistente y fiable que se alinee con las necesidades operativas de tu organización. --- ## Políticas Source: https://docs.applivery.com/es/device-management/android/policies/ Description: Las políticas de Android en Applivery aplican requisitos de seguridad, controlan ajustes del dispositivo y gestionan el cumplimiento normativo. TL;DR: Las políticas de Android en Applivery permiten a los administradores aplicar estándares de seguridad y restricciones en los dispositivos a escala. Answers: ¿Qué son las políticas de dispositivos Android en Applivery? · ¿Qué puedo controlar con las políticas de dispositivos Android de Applivery? · ¿Puedo crear políticas de dispositivos Android personalizadas en Applivery? · ¿Qué tipo de estándares de seguridad puedo aplicar? · ¿Cómo protegen los datos de la organización las políticas de dispositivos Android? · ¿Cuál es el propósito de las políticas de dispositivos Android? Key topics: políticas de dispositivos Android, políticas de seguridad, restricciones de dispositivos, gestión de cumplimiento, aplicación de políticas, Android, Applivery Las políticas de Android en Applivery te permiten aplicar estándares de seguridad y requisitos de cumplimiento en todos tus dispositivos administrados. Puedes controlar la configuración de dispositivos, restringir funciones, exigir complejidad de contraseña, configurar el modo quiosco, gestionar el comportamiento de las apps y mucho más. Las configuraciones de políticas de Android están organizadas por categoría, para que puedas crear la configuración adecuada para cada grupo de dispositivos en tu organización. --- ## Agente Source: https://docs.applivery.com/es/device-management/android/policies/agent/ Description: El agente MDM Android de Applivery — características, configuración, geolocalización y cómo mejora la gestión de dispositivos y la seguridad en Android. TL;DR: El agente MDM Android de Applivery ofrece gestión de dispositivos en segundo plano y un portal Self-Service para acceder a recursos corporativos, mejorando la gestión y seguridad. Answers: ¿Qué es el agente MDM Android de Applivery? · ¿Cómo configuro el agente MDM Android de Applivery? · ¿Qué funciones ofrece el agente MDM Android de Applivery? · ¿Cómo rastrea la geolocalización el agente MDM Android de Applivery? · ¿Cómo informa el agente MDM Android de Applivery sobre el uso de apps? · ¿Qué tan seguro es el agente MDM Android de Applivery? · ¿Cómo habilito el agente MDM Android de Applivery a nivel de política? · ¿Cómo inicio el agente MDM Android de Applivery programáticamente? · ¿Cómo envío una notificación push a un dispositivo Android con Applivery? Key topics: Características del agente MDM Android, Configuración del agente, Portal Self-Service, Seguridad de los datos, Seguimiento de geolocalización, Applivery, Android, Kotlin, Google Play Store, Google Maps, SHA-256, SSL TLS 1.3, notificaciones push, Service Account ![agent overview](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/a5ca7622-6fdf-4a2c-8e1d-da165c3d7d18.png) El agente MDM Android de Applivery es una aplicación Android desplegada en dispositivos gestionados e inscritos en el panel de Applivery. Sirve para dos propósitos complementarios: 1. **Gestión en segundo plano**: Recopila e informa la telemetría del dispositivo (geolocalización, uso de apps, tráfico de red, señal de red) al panel de Applivery, de acuerdo con las políticas configuradas por el administrador de TI de la organización. 2. **Portal Self-Service**: Proporciona al usuario del dispositivo una interfaz integrada para buscar e instalar aplicaciones corporativas, acceder a los marcadores de la organización y verificar el estado de los servicios de gestión que se ejecutan en su dispositivo. El agente está escrito en [Kotlin](https://kotlinlang.org/) y se **despliega a nivel de política**. Se ejecuta silenciosamente en segundo plano, al tiempo que ofrece a los usuarios finales una forma cómoda de acceder a los recursos que su organización ha puesto a su disposición. ### Versión 2.0.0 — Novedades La versión 2.0.0 es una actualización importante que introduce el **portal Self-Service**, una experiencia de usuario completamente nueva, junto con mejoras en la gestión en segundo plano. #### Novedades para los usuarios finales - **Catálogo de aplicaciones**: Busca, instala, actualiza y desinstala aplicaciones corporativas directamente desde el dispositivo, sin necesidad de acceder al panel de Applivery. - **Páginas de detalles de la app**: Consulta la información completa de la aplicación, incluyendo descripciones, capturas de pantalla, clasificaciones por edad, historial de versiones y compatibilidad con el dispositivo antes de instalarla. - **Marcadores**: Acceso rápido a URLs y recursos web compartidos por la organización, organizados por categoría. - **Panel de estado**: Comprueba de un vistazo si todos los servicios de gestión se están ejecutando correctamente en el dispositivo. - **Interfaz rediseñada**: Toda la interfaz de usuario ha sido modernizada con un diseño más limpio y rápido. #### Novedades para los administradores - **Control a nivel de función**: Habilita o deshabilita secciones individuales de Self-Service (aplicaciones, marcadores, estado, archivos, notificaciones) por dispositivo o grupo de dispositivos a través de la configuración gestionada. - **Vista predeterminada**: Configura qué sección se abre primero cuando el usuario inicia la app. - **Seguimiento de instalación en tiempo real**: El agente ahora detecta cuando un usuario instala una aplicación de Google Play Store y refleja el estado en tiempo real. ### Características #### Seguimiento de geolocalización ![agent location](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/be9fe4ef-1910-4d48-bec0-5e76cd2a36b7.png) Informa la ubicación geográfica del dispositivo (latitud, longitud), incluyendo la dirección completa cuando está disponible. La lista completa de ubicaciones informadas es accesible desde la sección **Ubicaciones** al seleccionar un dispositivo. Haz clic en cualquier entrada para ver una vista previa del mapa, o haz clic en **Abrir** para verla en Google Maps. :::warning El informe de geolocalización está disponible para dispositivos **totalmente administrados** y dispositivos **COPE** (Company-Owned, Personally Enabled). Los dispositivos con un **perfil de trabajo** no tienen acceso a esta función. ::: #### Informes de uso de apps ![app usage](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/022a34a1-2fda-4b39-b84d-076f4d35e3d5.png) Informa el tiempo de uso de la app consultando los datos de actividad en primer plano de las API de Android. Los análisis de uso se muestran semanalmente, agregados por nombre de paquete, con el nombre y la categoría de la app mostrados cuando están disponibles. Las 5 aplicaciones principales se resaltan en diferentes colores; el tiempo de uso restante se agrega en gris. Para acceder a los análisis de uso, navega a la sección **Uso** al seleccionar un dispositivo, luego usa el selector de semana encima de los gráficos para navegar por los períodos. :::warning En dispositivos con **perfil de trabajo** y **COPE**, solo se informan las apps de trabajo; las apps personales no son visibles. En dispositivos **totalmente administrados**, todas las apps son visibles. ::: #### Informes de tráfico de red ![network reporting](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/920de8d0-5a5b-4d24-ac21-15c2495960b9.png) Informa el tráfico de red entrante y saliente por app en MB, consultado desde las API de uso de red de Android. Los análisis se muestran semanalmente, agregados por nombre de paquete, con el nombre y la categoría de la app cuando están disponibles. Las 5 apps principales están codificadas por colores; el resto se agrega en gris. Para acceder a los análisis de red, navega a la sección **Uso** al seleccionar un dispositivo. Usa el selector de semana para navegar por los períodos y los filtros azules para aislar el tráfico Wi-Fi o móvil, o para distinguir entre datos recibidos y transmitidos. #### Informes de señal de red Informa la intensidad de la señal de red y la información del operador. Estos datos son recopilados por el agente de informes de red y se pueden ver desde la página de detalles del dispositivo en el panel de Applivery. #### Funciones por plan

Función

Plan Starter

Plan Advanced

Seguimiento de geolocalización

Sincronización: cada 1h · Retención: 1 semana

Sincronización: cada 15 min · Retención: 1 mes

Tráfico de red

Sincronización: cada 24h · Retención: 1 semana

Sincronización: cada 12h · Retención: 1 mes

Uso de apps

Sincronización: cada 24h · Retención: 1 semana

Sincronización: cada 12h · Retención: 1 mes

:::warning El agente se adhiere a las frecuencias de sincronización anteriores, pero el sistema puede priorizar otros procesos dependiendo del estado de la conexión de red, las optimizaciones de batería o el modo Doze. ::: :::info Android incluye un sistema de optimización de batería que restringe la ejecución en segundo plano. Algunos fabricantes de dispositivos personalizan Android y pueden eliminar este permiso o su pantalla de configuración. En esos casos, no hay necesidad de preocuparse: el agente seguirá funcionando correctamente, ya que la restricción no se aplica y la app puede ejecutarse en segundo plano sin problemas. ::: ### Seguridad de los datos Applivery se toma en serio la seguridad de los datos, especialmente para los datos sensibles de los dispositivos. El agente MDM Android utiliza cifrado de primera clase: - Todos los informes de seguimiento se cifran en tiempo de ejecución usando **SHA-256**. - Los datos en tránsito están protegidos usando **SSL TLS 1.3**. - Los datos en reposo en los servidores de Applivery se cifran usando **SHA-256**. ### Habilitación del agente a nivel de política El agente MDM Android se habilita a nivel de política. Para configurarlo: **Navega a políticas** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a cualquiera de tus políticas 1. Desde el menú lateral izquierdo, dirígete a **Agente** 2 y **habilítalo** 3. ![agent](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/9dcaa950-ac96-4058-8611-2186634a0cb3.png) **Elige el modo de instalación** - **Requerido para la configuración**: La app se instala durante el proceso de inscripción, antes de que el sistema se inicie. Recomendado para dispositivos nuevos. - **Instalación forzada** (predeterminado): La app se instala automáticamente en los dispositivos y el usuario no puede eliminarla. Haz clic en **Guardar cambios** para desplegar. :::warning Una vez guardado, el agente se desplegará en todos los dispositivos asociados con esa política. Sin embargo, **no comenzará a informar hasta que se haya abierto al menos una vez** y se hayan aceptado los permisos requeridos. ::: #### Cómo iniciar el agente programáticamente El agente Android de Applivery debe abrirse al menos una vez para solicitar los permisos necesarios y comenzar a informar. Para iniciarlo programáticamente desde un flujo de trabajo de inscripción u otra app, invócalo usando un Intent de Android con la siguiente acción: ``` com.applivery.mdm_agent.action.LAUNCH ``` Para asegurar que el agente esté disponible en tiempo de ejecución, es posible que primero necesites consultar información del sistema sobre él, como llamar a: ```kotlin val intent = Intent("com.applivery.mdm_agent.action.LAUNCH") if (packageManager.queryIntentActivities(intent, 0).isNotEmpty()) { startActivity(intent) } ``` Ten en cuenta que a partir de Android 11, se aplican filtros de visibilidad de paquetes. Para asegurar que el agente sea detectable por `queryIntentActivities`, añade lo siguiente al manifiesto de la app que realiza la llamada (reemplaza `com.example.app` con el nombre del paquete de tu app): ```xml ... ``` ### Primer inicio y configuración Cuando el agente se inicia por primera vez (o después de actualizar a la v2.0.0), pasa por un proceso de configuración inicial. #### Pantalla de carga Aparece una pantalla de bienvenida con el mensaje _"Comprobando la configuración de tu dispositivo... por favor, espera"_. Durante este tiempo, el agente se conecta al panel de Applivery para recuperar la configuración gestionada del dispositivo. #### Solicitudes de permisos Dependiendo de las funciones de gestión que el administrador haya habilitado, la app puede solicitar uno o más de los siguientes permisos. Cada permiso se explica al usuario antes de ser solicitado.

Permiso

Cuándo se solicita

Por qué

Ubicación

El seguimiento de ubicación o el informe de señal de red están habilitados

Informa la ubicación del dispositivo a la consola de gestión.

Ubicación en segundo plano

El seguimiento de ubicación está habilitado

Permite el informe de ubicación cuando la app no está en primer plano.

Estado del teléfono

El informe de señal de red está habilitado

Lee la intensidad de la señal de red y la información del operador.

Estadísticas de uso

El informe de uso de apps o de datos está habilitado

Recopila qué apps se usan y cuántos datos consumen.

Notificaciones

Siempre (Android 13+)

Muestra notificaciones de progreso durante las instalaciones de apps.

Exención de optimización de batería

Siempre

Permite que los servicios en segundo plano se ejecuten de forma fiable sin ser detenidos por el sistema.

Internet

Siempre (automático, sin aviso al usuario)

Se comunica con los servidores de Applivery.

Si el usuario deniega un permiso, la app continúa al portal Self-Service. Las funciones que requerían el permiso denegado aparecerán con un estado de error en la sección **Estado**. :::warning Si el agente no puede encontrar una configuración gestionada válida (por ejemplo, el dispositivo aún no está inscrito o todavía se está sincronizando), muestra un mensaje explicando que el dispositivo no está siendo gestionado por Applivery, junto con un botón **Reintentar ahora**. ::: ### Portal Self-Service ![self service](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/f78fc0d5-1a6e-494c-a2fc-69c671a4e1cc.png) Después de la configuración, el usuario llega al portal Self-Service, la interfaz principal del agente orientada al usuario. #### Diseño El portal tiene tres elementos principales: - **Barra superior**: Muestra el nombre de la sección actual. A la izquierda, un icono de menú abre el cajón de navegación. Dentro de las pantallas de detalles (como una página de detalles de una app), el icono de menú se reemplaza por una flecha hacia atrás. - **Área de contenido**: Muestra la sección activa (aplicaciones, marcadores, estado, etc.). - **Cajón de navegación**: Un panel lateral que se desliza desde la izquierda. Enumera todas las secciones habilitadas y permite cambiar entre ellas. #### Qué secciones son visibles Las secciones que se muestran en el cajón de navegación dependen de lo que el administrador haya habilitado a través de la configuración gestionada. Solo las secciones activas aparecen en el menú. Si no se configuran funciones, el portal por defecto muestra la sección **Estado** para que el usuario siempre tenga visibilidad sobre el estado de gestión del dispositivo. ![status section](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/34db9185-3de7-4627-b518-81e768398679.png) ### Aplicaciones La sección Aplicaciones es la función principal del portal Self-Service. Permite a los usuarios buscar, instalar, actualizar y desinstalar aplicaciones corporativas asignadas a sus dispositivos. La sección se organiza en tres pestañas. ![home screen](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/419d730f-4ca6-4833-a061-2f2b7cc2f469.png) #### Pestaña Inicio La pestaña Inicio es la vista de aterrizaje de la sección Aplicaciones, que proporciona una visión general rápida: - **Vista previa de aplicaciones**: Muestra hasta cuatro de las apps del usuario, priorizando las ya instaladas. Cada app muestra su icono, nombre, categoría y un botón de acción (Abrir, Instalar o Actualizar). Toca **Ver todo** para navegar a la pestaña Mis apps. - **Accesos directos a funciones**: Una cuadrícula de tarjetas que enlazan a otras secciones habilitadas de Self-Service (marcadores, estado, etc.) para un acceso rápido sin abrir el cajón de navegación. - **Tirar para actualizar**: Tira hacia abajo en la pantalla para actualizar la lista de aplicaciones desde el servidor. #### Pestaña Mis apps Muestra una lista completa de todas las aplicaciones gestionadas actualmente instaladas en el dispositivo, además de las que se están instalando. Cada app muestra: - Icono, nombre y categoría. - Un botón de acción: **Abrir** (instalada y actualizada), **Actualizar** (nueva versión disponible) o un indicador de progreso animado (actualmente instalando). Si no hay apps gestionadas instaladas, la pantalla muestra: _"No hay aplicaciones instaladas."_ #### Pestaña Actualizaciones Muestra solo las aplicaciones que tienen una versión más reciente disponible. El encabezado muestra un recuento: _"Actualizaciones pendientes (N)"_. Cada app muestra un botón **Actualizar** para iniciar el proceso de actualización. Si todas las apps están actualizadas, la pantalla muestra: _"No hay actualizaciones disponibles."_ #### Página de detalles de la app Al tocar cualquier aplicación se abre su página de detalles completa, que incluye: - **Encabezado**: Icono grande de la app, nombre de la aplicación y nombre del editor. - **Advertencia de compatibilidad**: Si la app requiere una versión de Android más reciente que la que ejecuta el dispositivo, aparece una advertencia _"No compatible con este dispositivo"_ y el botón Instalar se deshabilita. - **Botones de acción**: Varían según el estado actual de la app:

Estado de la app

Acciones disponibles

No instalada

Instalar

No instalada (incompatible)

Instalar (deshabilitado)

Instalada

Desinstalar y Abrir

Actualización disponible

Desinstalar y Actualizar

Instalación en curso

Indicador de carga animado (sin botones)

- **Capturas de pantalla**: Un carrusel de desplazamiento horizontal. Al tocar una captura de pantalla, se abre en un visor de pantalla completa con navegación por deslizamiento. - **Acerca de esta app**: Descripción de la aplicación, inicialmente truncada a tres líneas. Toca para expandir o abrir una vista de lectura dedicada a pantalla completa. - **Información**: Metadatos que incluyen Autor, Categoría, Compatibilidad, Clasificación por edad (PEGI: 3+, 7+, 12+, 16+ o 18+) y número de Versión. :::info Al volver a una página de detalles vista anteriormente, la información se carga instantáneamente desde una caché local mientras la app busca actualizaciones en segundo plano. ::: #### Búsqueda La sección Aplicaciones incluye una función de búsqueda, accesible a través del icono de búsqueda en la barra superior. Proporciona una lista filtrada de apps en tiempo real a medida que el usuario escribe, coincidiendo con el nombre de la aplicación (sin distinción entre mayúsculas y minúsculas). Cada resultado tiene un botón de acción para acciones rápidas de instalación/apertura/actualización sin visitar la página de detalles. #### Cómo funciona la instalación de apps Hay dos tipos de aplicaciones, cada una instalada de forma diferente: **Aplicaciones corporativas (Custom Apps)**. Alojadas directamente en Applivery. Cuando el usuario toca **Instalar**: 1. El icono de la app cambia a un indicador de carga animado. 2. Aparece una notificación en la barra de notificaciones que muestra el progreso de la instalación. 3. El archivo de la aplicación se descarga de los servidores de Applivery. 4. Se ejecuta el instalador de paquetes del sistema. 5. Una vez completado, el botón cambia a **Abrir**. Todo el proceso se ejecuta en segundo plano; el usuario puede seguir navegando mientras se realiza la instalación. **Aplicaciones de Google Play Store**. Cuando el usuario toca **Instalar**: 1. El dispositivo abre la página de la app en Google Play Store. 2. El usuario completa la instalación a través de Play Store. 3. Al regresar al agente de Applivery, la app detecta automáticamente el estado de la instalación y se actualiza en tiempo real, sin necesidad de una actualización manual. **Desinstalación de aplicaciones**: Toca el botón **Desinstalar** en la página de detalles de una app. Aparece un aviso de confirmación del sistema antes de que se elimine la app. ### Marcadores La sección Marcadores muestra URLs y enlaces web que la organización ha compartido con el usuario, como enlaces a herramientas internas, documentación o portales de la empresa. #### Organización Los marcadores se agrupan en dos categorías: - **Personalizados**: Enlaces configurados específicamente por el administrador de la organización. - **Applivery**: Enlaces proporcionados por el panel de Applivery. Los botones de filtro en la parte superior de la pantalla permiten ver una categoría a la vez. Al tocar el mismo filtro de nuevo, se elimina y se muestran todos los marcadores. Cada marcador muestra un icono (si está configurado), nombre, descripción y un botón **Abrir** que abre la URL en el navegador predeterminado del dispositivo. ### Estado La sección Estado proporciona al usuario visibilidad sobre los agentes de gestión (servicios en segundo plano) que se ejecutan en su dispositivo. Cada agente es responsable de recopilar e informar un tipo específico de información del dispositivo al panel de Applivery. #### Agentes

Agente

Qué hace

Seguimiento de ubicación

Informa la ubicación geográfica del dispositivo.

Detalles de uso de apps

Informa sobre qué apps se usan y durante cuánto tiempo.

Uso de datos móviles

Informa el consumo de datos móviles.

Informe de red

Informa la intensidad de la señal de red y la información del operador.

Descarga de activos

Descarga certificados y archivos asignados al dispositivo.

#### Indicadores de estado Cada agente se muestra como una tarjeta con su icono, nombre, última hora de ejecución exitosa y un estado codificado por colores:

Indicador

Color

Significado

Habilitado

Verde

Ejecutándose normalmente e informando según lo programado

Deshabilitado

Gris

Desactivado por el administrador para este dispositivo

Error

Naranja

Ocurrió un problema (por ejemplo, se denegó un permiso requerido)

Si un agente se está ejecutando actualmente, su subtítulo muestra _"Ejecutándose"_ en lugar de una marca de tiempo. La información de estado se actualiza en tiempo real. ### Notificaciones push Puedes enviar una notificación push a un dispositivo gestionado para comunicarte directamente con su usuario — por ejemplo, para compartir un aviso, un recordatorio o una indicación para realizar una acción. La notificación se entrega a través del agente de Applivery y aparece como una notificación estándar de Android en el dispositivo, mostrando el icono del agente, el título y el mensaje. **Navegar al dispositivo** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), selecciona el **dispositivo** que quieres notificar y haz clic en el botón **Acción**. **Seleccionar Enviar notificación push** En el menú desplegable, selecciona **Enviar notificación push**. Introduce un **Título** y un **Mensaje**, y envíala. ![push notifications](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/d975c280-83ea-4451-b61d-399fd1a48544.png) #### Enviar notificaciones a través de la API También puedes enviar notificaciones push de forma programática — por ejemplo, para lanzar mensajes desde tus propios flujos de trabajo — usando el endpoint **Send push notification** de Applivery: ``` POST https://api.applivery.io/v1/organizations/ORG_ID/mdm/push-notifications/send ``` Autentícate con un token de una [cuenta de servicio](https://docs.applivery.com/es/platform/api/service-accounts/) en la cabecera `Authorization`, y proporciona el `identifier` del dispositivo de destino, el `os` (`android`), la `app` de destino (`mdmAgent`), el `type` (`notification` para una alerta visible o `silent` para un mensaje solo de datos) y el `title` y `body` de la `notification`. Consulta la [referencia de la API](https://docs.applivery.com/en/api/uem/push-notifications/post-send/) para ver el esquema completo. ### Navegación y menú #### Cajón de navegación Abre el cajón de navegación tocando el icono de menú (☰) en la esquina superior izquierda. El cajón contiene: - Un botón de cierre (✕). - El logo de Applivery. - Todas las secciones habilitadas con sus iconos: Aplicaciones, Archivos, Marcadores, Estado, Notificaciones. Al tocar cualquier sección, se cambia a esa vista y se cierra el cajón. #### Navegación hacia atrás Cuando se está dentro de una pantalla de detalles (detalles de la app, búsqueda), el icono de menú se reemplaza por una flecha hacia atrás. Cada sección principal mantiene su propio historial de navegación; al volver a una sección, se reanuda donde el usuario la dejó. #### Vista predeterminada El administrador puede configurar qué sección se abre por defecto cuando se inicia la app. Si no se establece ninguna predeterminada, se muestra la primera sección habilitada. #### Modo depuración Al tocar rápidamente el logo de Applivery en el cajón de navegación varias veces, se abre una pantalla de depuración oculta destinada al soporte de TI, que muestra detalles técnicos sobre la configuración del dispositivo y el estado del agente. ### Configuración de administrador Los administradores controlan el comportamiento del portal Self-Service a través de la política de configuración gestionada en el panel de Applivery, que se envía automáticamente a los dispositivos. ![android self service configuration](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/01e90244-c9f9-4fed-971f-3d4447742ab4.png) #### Conmutadores de funciones Cada sección del portal Self-Service se puede habilitar o deshabilitar de forma independiente:

Clave de función

Sección

APPLICATIONS

Catálogo de aplicaciones con instalación/actualización/desinstalación.

BOOKMARKS

Marcadores y enlaces web de la organización.

STATUS

Panel de monitorización del estado del agente.

FILES

Gestión de archivos.

NOTIFICATIONS

Centro de notificaciones push.

Para cada función, el administrador puede configurar: - **active**: Si la función aparece en el menú de navegación (`true` o `false`). - **defaultView**: Si esta función es la primera pantalla que se muestra cuando se abre la app (`true` o `false`). Solo una función debe establecerse como vista predeterminada a la vez. #### Catálogo de aplicaciones Las aplicaciones que se muestran en el portal Self-Service se gestionan a través de las funciones de gestión de apps del panel de Applivery. El agente sincroniza automáticamente la lista de aplicaciones asignadas. Los administradores controlan: - Qué aplicaciones son visibles para qué dispositivos o grupos. - Si una app es una **app corporativa** (alojada en Applivery) o una **app de Play Store**. - Si el tipo de instalación es **Disponible** (iniciada por el usuario) o **Instalación forzada** (obligatoria). - Metadatos de la app: nombre, descripción, icono, capturas de pantalla, categoría, clasificación por edad, versión. #### Marcadores Los marcadores se configuran a través de la gestión de recursos del panel de Applivery. Admiten marcadores personalizados (creados por el administrador) y marcadores del panel de Applivery. Cada marcador tiene un título, descripción, URL y un icono opcional. #### Gestión de recursos El agente se encarga de descargar e instalar certificados y archivos asignados al dispositivo. Los certificados (como los certificados inscritos en SCEP) se instalan automáticamente en el almacén de claves del dispositivo. Otros tipos de archivos se descargan y almacenan en el dispositivo. ### Compatibilidad del dispositivo El agente MDM Android de Applivery v2.0.0 es compatible con: - **Android 7.0 (Nougat / API 24)** y versiones superiores. - Teléfonos y tabletas. - Dispositivos totalmente administrados y dispositivos con perfil de trabajo. El portal Self-Service está diseñado para orientaciones tanto vertical como horizontal, con diseños optimizados para diferentes tamaños de pantalla. :::warning La versión 2.0.0 es una actualización unidireccional. Una vez que un dispositivo se actualiza a la v2.0.0, no se puede degradar a la v1.x sin perder los datos locales de aplicaciones y certificados. ::: --- ## Configurar ajustes de APN Source: https://docs.applivery.com/es/device-management/android/policies/apn-settings/ Description: Despliega uno o varios APN en dispositivos Android gestionados con apnPolicy desde una política de Applivery, sin configurarlos a mano en cada dispositivo. TL;DR: Un APN se despliega con el objeto apnPolicy de la política Android: activas overrideApns y declaras uno o varios apnSettings. Requiere Android 10 o superior en totalmente administrados y Android 13 o superior, solo con tipo ENTERPRISE, en perfiles de trabajo. Answers: ¿Cómo configuro un APN en dispositivos Android desde Applivery? · ¿Qué es apnPolicy en la Android Management API? · ¿Qué hace overrideApns? · ¿Qué versión de Android necesito para desplegar un APN por política? · ¿Puedo configurar un APN en un perfil de trabajo? · ¿Qué campos son obligatorios en un APN? · ¿Por qué mi APN no se aplica o el dispositivo reporta API_LEVEL o MANAGEMENT_MODE? Key topics: apnPolicy y overrideApns, Configuración del APN en la política, Referencia de campos de ApnSetting, Comprobación en el dispositivo, Solución de problemas, Applivery, Android, Android Management API, APN El APN (Access Point Name) es el punto de acceso que usa el dispositivo para conectarse a la red de datos de su operador. Cuando una flota usa SIM corporativas con un APN privado (por ejemplo, para acceder a la red interna de la empresa a través del operador), configurarlo a mano en cada dispositivo no escala. Con `apnPolicy` lo declaras una vez en la política y llega a todos los dispositivos asignados, sin intervención del usuario. Applivery envía la configuración de la política Android a los dispositivos a través de la Android Management API (AMAPI), así que los campos y los requisitos de `apnPolicy` son los que define Google en su [referencia de políticas](https://developers.google.com/android/management/reference/rest/v1/enterprises.policies). ### Requisitos previos

Requisito

Detalle

Dispositivo con SIM o eSIM activa

El APN solo tiene efecto sobre la conexión de datos móviles del operador.

Dispositivo Android inscrito en Applivery

Con una política Android Enterprise asignada.

Totalmente administrado

Android 10 o superior. Se admiten varios tipos de APN.

Perfil de trabajo

Android 13 o superior, y solo APN con tipo ENTERPRISE.

Datos del APN facilitados por el operador

Nombre del APN, usuario y contraseña si aplica, tipo de autenticación, MCC+MNC, proxy, etc.

:::info Si el dispositivo no cumple la versión mínima, no falla nada visible: el ajuste se descarta y el dispositivo reporta un motivo de no conformidad (`API_LEVEL` o `MANAGEMENT_MODE`). ::: ### Cómo funciona `apnPolicy` tiene dos campos: - `overrideApns`: activa o desactiva el uso de los APN definidos por política. Valores: `OVERRIDE_APNS_UNSPECIFIED`, `OVERRIDE_APNS_DISABLED` y `OVERRIDE_APNS_ENABLED`. Con `OVERRIDE_APNS_ENABLED`, los APN de la política pueden prevalecer sobre los demás APN del dispositivo. El comportamiento se corresponde con `DevicePolicyManager.setOverrideApnsEnabled` de Android. - `apnSettings`: la lista de APN. Cada elemento es un objeto `ApnSetting`. :::warning No puede haber conflictos entre los APN de la lista. Dos entradas entran en conflicto cuando coinciden en todos estos campos: `numericOperatorId`, `apn`, `proxyAddress`, `proxyPort`, `mmsProxyAddress`, `mmsProxyPort`, `mmsc`, `mvnoType`, `protocol` y `roamingProtocol`. Si hay conflicto, la política se rechaza. ::: ### Configurar un APN **Abre la política** En el [**panel de Applivery**](https://dashboard.applivery.io/), ve a **Políticas** 1 y abre la política Android que quieres modificar, o [**crea una nueva**](https://docs.applivery.com/es/device-management/general-settings/create-policies/). En el menú lateral izquierdo, haz clic en la sección **Red** 2 y localiza la configuración de **Política de APN** 3. Establece `overrideApns` en `OVERRIDE_APNS_ENABLED`. ![apn](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/e2b1075d-fb4d-4f8b-a930-b07418015175.png) **Añade los APN** Añade un elemento en `apnSettings` por cada APN y completa, como mínimo, los campos obligatorios: `apn`, `displayName` y `apnTypes`. **Guarda y asigna** Haz clic en **Guardar** y asigna la política a los dispositivos o grupos correspondientes. ### Referencia de campos #### Obligatorios

Campo

Descripción

apn

Nombre del APN. La política se rechaza si está vacío.

displayName

Nombre descriptivo del APN. La política se rechaza si está vacío.

apnTypes

Lista de tipos de uso del APN. Se rechaza si está vacía, si contiene APN_TYPE_UNSPECIFIED o si hay duplicados.

Valores de `apnTypes`: `ENTERPRISE`, `BIP`, `CBS`, `DEFAULT`, `DUN`, `EMERGENCY`, `FOTA`, `HIPRI`, `IA`, `IMS`, `MCX`, `MMS`, `RCS`, `SUPL`, `VSIM` y `XCAP`. :::info En dispositivos totalmente administrados puedes combinar varios tipos. En perfiles de trabajo, `ENTERPRISE` es el único tipo permitido. Los tipos que el dispositivo o el modo de gestión no admiten se ignoran; si ninguno es válido, la entrada completa se ignora y se reporta `INVALID_VALUE`. ::: #### Opcionales

Campo

Descripción

authType

Tipo de autenticación: NONE, PAP, CHAP o PAP_OR_CHAP.

username / password

Credenciales del APN, si el operador las exige.

numericOperatorId

Identificador numérico del operador: MCC (código de país) + MNC (código de red).

mvnoType

Tipo de coincidencia MVNO: GID, ICCID, IMSI o SPN.

carrierId

ID de operador. 0 significa no establecido; no se admiten negativos.

protocol / roamingProtocol

Protocolo de conexión, normal y en roaming: IP, IPV4V6, IPV6, NON_IP, PPP o UNSTRUCTURED.

networkTypes

Tecnologías de radio que puede usar el APN: EDGE, GPRS, GSM, HSDPA, HSPA, HSPAP, HSUPA, IWLAN, LTE, NR, TD_SCDMA y UMTS. No admite duplicados.

proxyAddress / proxyPort

Proxy del APN. Puerto 0 significa no establecido.

mmsc / mmsProxyAddress / mmsProxyPort

Parámetros de mensajería multimedia (MMS). La dirección del proxy MMS es una IP o un nombre de host, no una URL.

mtuV4 / mtuV6

Tamaño MTU en bytes para IPv4 e IPv6. Requiere Android 13 o superior.

alwaysOnSetting

NOT_ALWAYS_ON o ALWAYS_ON. Indica si se activan los recursos de plano de usuario en cada transición de CM-IDLE a CM-CONNECTED (3GPP TS 23.501, sección 5.6.13).

### Comprobar que se ha aplicado 1. En el dispositivo, abre **Ajustes → Redes móviles → Nombres de punto de acceso** (la ruta varía según el fabricante) y comprueba que aparece el APN con el `displayName` definido. 2. Verifica que el dispositivo tiene conexión de datos móviles con la Wi-Fi desactivada. 3. Si el APN no aparece, revisa los motivos de no conformidad del dispositivo. ### Solución de problemas

Síntoma

Causa probable

Qué hacer

El dispositivo reporta API_LEVEL

Android inferior a 10 (cualquier modo), o uso de mtuV4/mtuV6 con Android inferior a 13.

Actualiza el dispositivo o elimina los campos que requieren Android 13.

El dispositivo reporta MANAGEMENT_MODE

Perfil de trabajo con Android inferior a 13, o con un apnTypes distinto de ENTERPRISE.

Usa solo ENTERPRISE en perfiles de trabajo y Android 13 o superior.

Se reporta INVALID_VALUE

Ninguno de los tipos de apnTypes es compatible con el dispositivo o el modo de gestión.

Revisa los tipos declarados.

La política se rechaza al guardar

Falta apn, displayName o apnTypes; hay duplicados en apnTypes o networkTypes; o hay APN en conflicto.

Corrige los campos y revisa que no haya dos APN con los mismos valores clave.

El APN se aplica pero no hay datos

Datos del operador incorrectos (APN, autenticación, protocolo).

Confirma los parámetros con el operador y prueba con protocol y roamingProtocol en IPV4V6.

--- ## Check Point Harmony VPN Source: https://docs.applivery.com/es/device-management/android/policies/checkpoint-harmony-vpn/ Description: Integra Check Point Harmony Mobile VPN con Applivery para proteger el tráfico de red y desplegar la VPN con Zero-Touch en dispositivos móviles. TL;DR: Integra Check Point Harmony Mobile VPN con Applivery para proteger dispositivos móviles y tráfico de red con despliegue Zero-Touch. Answers: ¿Qué logra la integración de Check Point Harmony Mobile VPN con Applivery? · ¿Dónde se encuentran los ajustes de protección de red en el Check Point Portal? · ¿Cuál es el propósito del certificado de política en esta integración? · ¿Cómo se sube el certificado de política a Applivery? · ¿Qué es el despliegue Zero-Touch para Check Point Harmony Mobile VPN? · ¿Dónde se habilita 'Usar ONP de próxima generación' en Check Point? · ¿Cuál es el primer paso para integrar Check Point Harmony Mobile VPN con Applivery? Key topics: Seguridad móvil, Integración VPN, Gestión de dispositivos, Check Point Harmony Mobile VPN, Applivery, Check Point Portal Integrar **Check Point Harmony Mobile VPN** dentro de tu Workspace de Applivery refuerza la protección de dispositivos al asegurar que todo el tráfico de red se enrute de forma segura a través de la infraestructura de confianza de Check Point. La función VPN añade una capa de seguridad crítica a las capacidades de prevención de amenazas de Harmony Mobile, ayudando a proteger a los usuarios de conexiones maliciosas o inseguras incluso cuando están fuera de las redes corporativas. Al combinar el **Zero-Touch deployment de Harmony Mobile** con la configuración VPN automatizada, las organizaciones pueden ofrecer una protección consistente y siempre activa para los dispositivos móviles sin requerir ninguna configuración manual por parte de los usuarios finales. ### Pasos de implementación **Generar el certificado de política en Check Point** Para empezar, accede al [Check Point Portal](https://portal.checkpoint.com/) y abre la sección **Política** 1. Expande la **política global** 2 (o la política de Workspace relevante para tu entorno) y navega a los ajustes de **protección de red** 3. ![policy checkpoint](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/d49bf157-f6d5-45c6-9dee-5cf64eaf4454.png) Dentro de esta sección, localiza el panel de **Ajustes HTTPS** 4 y genera un nuevo **certificado de política de red** 5. Asegúrate de guardar este certificado de forma segura, ya que será necesario más adelante al configurar la política en Applivery. Antes de salir de esta página, también se recomienda habilitar la opción **Usar ONP de próxima generación** 6 para asegurar que se apliquen las características de protección más actualizadas. ![https-settings](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/d1fc092c-01d9-4a95-872f-eabc45e98859.png) **Configurar la política en Applivery** :::info Si aún no has integrado Check Point Harmony Mobile en tu Workspace, o no has añadido la app a tu política, puedes aprender cómo siguiendo este [enlace](https://docs.applivery.com/es/device-management/integrations/security/checkpoint-harmony-mobile-integration/). ::: Una vez en el [**panel de Applivery**](https://dashboard.applivery.io), dirígete a **Recursos** 7. Desde el menú de la izquierda, selecciona **Certificados** 8 y utiliza el botón **\+ Cargar Certificado** 9 para subir el certificado que descargaste previamente del portal de Check Point. ![upload certificate](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/69b78e79-4ddf-442a-b6cd-4e8f5ac988dc.png) A continuación, abre la política donde deseas desplegar el certificado. En el menú de la izquierda, dirígete a **Recursos** 10, selecciona **\+ Añadir Recurso** 11 y elige el certificado que subiste previamente. Finalmente, **guarda** la política y **despliega** los cambios. ![add certificate](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/b23c02c4-3829-4b38-aed9-565ce3b07e81.png) --- ## Configurar redes Wi-Fi Source: https://docs.applivery.com/es/device-management/android/policies/configure-wifi-networks/ Description: Envía configuraciones Wi-Fi predefinidas a dispositivos Android gestionados desde políticas de Applivery — compatible con WPA-PSK, WPA-EAP y SSID ocultos. TL;DR: Usa las políticas Android de Applivery para enviar configuraciones Wi-Fi automáticamente a los dispositivos gestionados — define el SSID, el tipo de seguridad y opciones avanzadas como Auto Connect, aleatorización de MAC y proxy. Answers: ¿Cómo envío una configuración Wi-Fi a dispositivos Android gestionados? · ¿Qué es openNetworkConfiguration en Android Enterprise? · ¿Cómo configuro WPA-EAP en dispositivos Android gestionados? · ¿Para qué sirve el campo GUID en la configuración de red Wi-Fi? · ¿Cómo funciona Auto Connect en dispositivos Android gestionados? · ¿Qué es el modo de aleatorización de dirección MAC en Android MDM? · ¿Puedo configurar SSID ocultos en dispositivos Android gestionados? · ¿Qué es una lista de BSSID permitidos en una política Wi-Fi de Android? Key topics: Configuración de política Wi-Fi, openNetworkConfiguration, Gestión de red con Android Enterprise, Applivery MDM, Android, Applivery, Android Management API, Wi-Fi Applivery te permite definir configuraciones de redes Wi-Fi directamente en una política Android para que los dispositivos gestionados reciban automáticamente los ajustes de conectividad necesarios, sin ninguna configuración manual en cada dispositivo. La configuración se basa en `openNetworkConfiguration`, el formato estándar que utiliza la Android Management API para declarar redes Wi-Fi en dispositivos gestionados. Este enfoque es especialmente útil en despliegues COBO/COPE, dispositivos en modo kiosk y rollouts a gran escala donde el objetivo es minimizar la intervención del usuario: los dispositivos se conectan automáticamente a las redes corporativas aprobadas desde el primer arranque. ### Requisitos previos Antes de empezar, asegúrate de tener: - Un dispositivo Android inscrito en Applivery con una política Android Enterprise asignada. - El SSID de la red y su tipo de seguridad — por ejemplo, abierta, WPA-PSK o WPA-EAP. - Para redes 802.1X/EAP: los parámetros de autenticación y los certificados necesarios, incluidos certificados CA y, si aplica, un certificado de cliente. :::warning Si tienes previsto bloquear los cambios manuales de Wi-Fi en el dispositivo, asegúrate de que al menos una red válida y probada ya esté declarada en la política — de lo contrario, el dispositivo podría perder el acceso Wi-Fi por completo. ::: ### Configurar una red Wi-Fi **Abre la política** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a cualquiera de tus **Políticas** o [crea una nueva](https://docs.applivery.com/es/device-management/general-settings/create-policies/). En el menú lateral izquierdo, selecciona **WiFi** y haz clic en **\+ Añadir red Wi-Fi**. ![add wifi network](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/df1eea51-794f-4b1c-8170-9cc18ac48426.png) **Configura la red** Rellena los detalles de la red según el tipo de red corporativa que necesites desplegar. Consulta la [referencia de campos](#referencia-de-campos) más abajo para una descripción de cada opción. ![wifi network config](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/86fdfd55-df43-4e18-86b0-309831db7cbb.png) **Guarda y aplica** Haz clic en **Guardar** para aplicar los cambios y asígnala a los dispositivos o grupos correspondientes. Applivery enviará la configuración Wi-Fi automáticamente a todos los dispositivos asignados. ### Referencia de campos #### General - **GUID** — Identificador interno único de la entrada de red dentro de la política. Permite a Applivery y a Android distinguir esta entrada Wi-Fi de otras, incluso cuando varias entradas comparten el mismo SSID en distintas políticas o versiones. - **Nombre** — Etiqueta descriptiva visible únicamente en el panel de Applivery. No tiene por qué coincidir con el SSID; es solo para fines administrativos (por ejemplo, "Wi-Fi planta 3 oficina"). - **SSID** — El nombre real de la red Wi-Fi que el dispositivo verá y a la que se conectará. Se corresponde con el campo `SSID` de `openNetworkConfiguration` y debe coincidir exactamente con lo configurado en el punto de acceso, incluyendo las mayúsculas. - **Seguridad** — El tipo de seguridad de la red Wi-Fi. Applivery admite los valores definidos por la Android Management API: `None` (abierta), `WEP-PSK`, `WPA-PSK` y `WPA-EAP`. Al seleccionar un valor se habilitan los campos correspondientes — por ejemplo, el campo de contraseña para WPA-PSK, o los parámetros EAP y los selectores de certificado para WPA-EAP. #### Certificado de un proveedor de certificados Para autenticar una red WPA-EAP con un certificado solicitado por SCEP: 1. Pon **Seguridad** en **WPA-EAP**. 2. En la configuración EAP, pon **Outer** en **EAP-TLS**. 3. Pon **Certificate Type** en **Certificate Provider**. 4. Elige el proveedor de certificados y después el perfil. Los proveedores y sus perfiles se configuran en [Proveedores de certificados](https://docs.applivery.com/es/device-management/general-settings/certificate-providers/). #### Configuración avanzada - **Conexión automática** — Cuando está activado, el dispositivo se conecta automáticamente a esta red cuando está en rango, sin intervención del usuario, siempre que las credenciales sean correctas. - **Modo de aleatorización de direcciones MAC** — Controla si el dispositivo usa su dirección MAC real o una aleatoria para esta red. Se corresponde con `MACAddressRandomizationMode` en la Android Management API (Android 13+). Relevante en entornos con control de acceso basado en MAC o gestión de inventario de red. - **SSID oculto** — Marca la red como oculta, lo que significa que el punto de acceso no emite el nombre del SSID. Cuando está activado, el dispositivo sigue buscando y conectándose a la red usando el SSID configurado, aunque no aparezca en la lista de redes visibles. - **BSSID Lista permitida** — Lista opcional de BSSIDs (direcciones MAC de puntos de acceso específicos) a los que el dispositivo puede asociarse para este SSID. Restringe la conectividad a radios concretos — útil cuando el mismo SSID existe en varias ubicaciones y solo quieres que los dispositivos se conecten a un subconjunto definido. - **Configuración de proxy** — Configuración de proxy que se aplica cuando el dispositivo está conectado a esta red. Admite sin proxy, configuración manual (host, puerto y exclusiones) o configuración automática mediante PAC URL, siguiendo el campo `ProxySettings` de la Android Management API. ### Buenas prácticas - Activa **Conexión automática** para las redes que deben estar disponibles desde el primer arranque. - Valida la configuración en un **grupo piloto** antes de desplegarla a toda la flota de dispositivos. - Si tienes previsto bloquear los cambios manuales de Wi-Fi, confirma que la política contiene una red funcional y probada antes de habilitar esa restricción. - En entornos con control de acceso basado en MAC, valora si conviene fijar el **modo de aleatorización de dirección MAC** en función del comportamiento esperado de tu infraestructura de red. Una vez aplicada la política, el dispositivo mostrará la red como guardada o se conectará automáticamente, según el valor de `Conexión automática`. Si la red no se aplica como se espera, revisa el tipo de seguridad, la contraseña, la visibilidad del SSID, los certificados y los parámetros EAP configurados en la política. --- ## Políticas de uso personal en COPE Source: https://docs.applivery.com/es/device-management/android/policies/cope-personal-usage/ Description: Configura las Políticas de uso personal en Applivery MDM para dispositivos COPE y equilibra la seguridad corporativa con la privacidad del empleado. TL;DR: Configura las políticas de uso personal en Applivery MDM para equilibrar la seguridad corporativa y la privacidad del empleado en dispositivos COPE. Answers: ¿Cómo configurar políticas de uso personal en dispositivos COPE? · ¿Cuáles son los beneficios de usar dispositivos COPE? · ¿Cómo gestiona Applivery MDM el uso personal? · ¿Cómo desactivar la cámara en el perfil personal en Android? · ¿Cómo controlar la instalación de apps en el perfil personal? · ¿Cuál es la diferencia entre el modo lista negra y lista blanca en Google Play? · ¿Cómo gestionar la duración del perfil de trabajo en dispositivos COPE? · ¿Cómo desactivar las capturas de pantalla en el perfil personal? Key topics: Gestión de dispositivos COPE, Configuración de políticas de uso personal, Funciones de Applivery MDM, Android MDM, Equilibrio entre seguridad y privacidad, Applivery, COPE, Android, Google Play, Bluetooth :::warning Las políticas de uso personal requieren la inscripción COPE (perfil de trabajo en un dispositivo de empresa) y **no están disponibles en dispositivos AOSP**. En AOSP, el Applivery DPC se ejecuta como propietario del dispositivo en todo el dispositivo — no existe un perfil personal ni un perfil de trabajo que configurar por separado. ::: La gestión moderna de dispositivos móviles requiere un equilibrio entre la seguridad corporativa estricta y la privacidad y flexibilidad del usuario. Los dispositivos COPE (Corporate-Owned, Personally Enabled) están diseñados precisamente para esto: la empresa posee y gestiona el dispositivo, mientras que los empleados conservan un espacio personal separado y privado. Las políticas de uso personal en Applivery MDM proporcionan un control detallado sobre lo que los usuarios pueden hacer en el perfil personal de un dispositivo COPE — sin comprometer el cumplimiento, la seguridad ni la protección de los datos corporativos. Estas políticas permiten a las organizaciones definir con claridad qué funciones, aplicaciones y permisos pertenecen al área personal del usuario, habilitando un entorno seguro y productivo que también respeta la privacidad del empleado. Con estos controles, los equipos de TI pueden adaptar cada dispositivo COPE tanto a las necesidades corporativas como personales, maximizando la seguridad y la productividad mientras se mantiene la libertad personal que los entornos de trabajo modernos requieren. ### Cómo acceder a las políticas de uso personal Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a cualquiera de tus políticas 1. En el menú lateral izquierdo, dirígete a **Cumplimiento** y desplázate hacia abajo hasta **Políticas de uso personal** 2. ![políticas de uso personal](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/0d8c9f3f-c923-4574-8378-e3ea9087b404.png) ### Opciones de configuración #### Tipos de cuenta con gestión desactivada Define qué tipos de cuenta no deben estar gestionados por MDM. Se utiliza habitualmente para aplicar la gestión solo a las cuentas corporativas, dejando las cuentas personales completamente fuera del control de TI. Para añadir un tipo de cuenta, haz clic en **\+ Añadir elemento** e introduce el identificador de la cuenta. #### Uso compartido de Bluetooth (Permitido / No permitido) Controla si los usuarios pueden compartir contenido a través de Bluetooth desde el perfil personal. Útil para permitir o restringir el intercambio de archivos en el área privada del dispositivo. #### Cámara desactivada Desactiva la cámara en el perfil personal. Recomendado para entornos donde tomar fotos o vídeos en el modo personal podría suponer un riesgo de seguridad o confidencialidad. #### Máximo de días con el trabajo desactivado Controla cuánto tiempo puede permanecer desactivado el perfil de trabajo en un dispositivo COPE. **¿Cómo funciona?** - El valor debe ser de al menos 3 días. - Ejemplo: si se establece en 5, el usuario puede desactivar el perfil de trabajo hasta 5 días consecutivos. - Si se supera ese límite, el sistema puede bloquear el acceso, restringir el uso o forzar la reactivación según la política de la empresa. - Un valor de 0 desactiva completamente esta función. - Los valores por debajo del mínimo producen un error y no se aplican. **¿Cuándo es útil?** - Para garantizar que el dispositivo no esté demasiado tiempo sin controles corporativos. - Para evitar que los usuarios mantengan el perfil de trabajo desactivado indefinidamente. - Para mantener el acceso a las aplicaciones corporativas, actualizaciones y requisitos de seguridad. - Esencial para organizaciones que manejan datos sensibles o regulados. #### Aplicaciones personales Controla qué aplicaciones pueden instalarse dentro del perfil personal. Cada entrada incluye: - **Tipo de instalación**: Si la aplicación está permitida o bloqueada. - **Nombre del paquete**: El identificador de la aplicación. Esto permite a TI autorizar aplicaciones seguras y aprobadas mientras restringe las no deseadas o no conformes. #### Modo de Play Store personal Define el nivel de acceso que el usuario tiene a Google Play en el espacio personal: - **Modo lista negra**: Todas las aplicaciones de Google Play están permitidas, excepto las marcadas explícitamente como **BLOQUEADAS** en Aplicaciones personales. Útil cuando se quiere amplia libertad pero se siguen bloqueando ciertas categorías (p. ej., apps de riesgo, apps de mensajería no verificadas, etc.). - **Modo lista blanca**: Solo se pueden instalar las aplicaciones marcadas explícitamente como **DISPONIBLES** en Aplicaciones personales. Todo lo demás se bloquea automáticamente. Esta es la configuración más restrictiva e ideal para entornos muy controlados. #### Política de espacio privado (Permitido / No permitido) Determina si el usuario puede crear un espacio privado e independiente en el dispositivo. Útil para separar completamente el contenido personal de los datos corporativos. Puedes obtener más información sobre los Espacios privados en dispositivos Android siguiendo [este enlace.](https://docs.applivery.com/es/device-management/android/policies/private-space/) #### Captura de pantalla desactivada Impide que el usuario tome capturas de pantalla en el perfil personal. Útil cuando las organizaciones quieren evitar la difusión o el guardado de información sensible. ### Por qué importan las políticas de uso personal Estos controles de política permiten a TI definir exactamente qué está permitido o restringido dentro del área personal de un dispositivo COPE. Esto crea el equilibrio ideal entre: - **Seguridad corporativa** — protección de aplicaciones, datos y cumplimiento normativo. - **Privacidad del empleado** — libertad para los usuarios en sus perfiles personales. - **Eficiencia operativa** — dispositivos productivos y alineados con los estándares de la empresa. Applivery permite un control granular sobre cuentas, instalación de apps, uso de cámara y capturas de pantalla, uso compartido de archivos y el tiempo máximo que el perfil de trabajo puede permanecer desactivado — garantizando que los dispositivos sean seguros y, a la vez, fáciles de usar. Implementar políticas de uso personal en entornos COPE conduce a: - Dispositivos más seguros y mejor gestionados. - Reglas claras para los empleados. - Una adopción del modelo COPE más sencilla en toda la organización. - Mayor claridad y control para los equipos de TI. - Un ecosistema móvil equilibrado, seguro y respetuoso con el usuario. --- ## Desactivar transferencia de datos USB Source: https://docs.applivery.com/es/device-management/android/policies/disable-usb-data-transfer/ Description: Applivery MDM permite desactivar la transferencia de datos USB en dispositivos Android para prevenir accesos no autorizados y reforzar la seguridad. Implementa políticas de protección de datos. TL;DR: Desactiva la transferencia de datos USB en dispositivos Android con Applivery MDM para prevenir fugas de datos y accesos no autorizados. Answers: ¿Por qué las organizaciones deberían desactivar los puertos USB en dispositivos Android? · ¿Cómo puedo desactivar la transferencia de datos USB en dispositivos Android con Applivery? · ¿Dónde se encuentra la configuración para desactivar la transferencia de datos USB en Applivery? · ¿Qué beneficios de seguridad ofrece la desactivación de la transferencia de datos USB para los dispositivos Android corporativos? · ¿Es compatible la desactivación de la transferencia de datos USB en dispositivos AOSP con Applivery? · ¿Qué riesgos específicos ayuda a mitigar la desactivación de los puertos USB? Key topics: Seguridad de dispositivos Android, Gestión de dispositivos móviles, Prevención de fuga de datos, Applivery, Android, USB Desactivar los puertos USB en dispositivos Android es una práctica de seguridad cada vez más común en entornos corporativos, especialmente en industrias donde la protección de datos y el control de acceso físico son críticos. Con soluciones MDM como Applivery, las organizaciones pueden restringir la funcionalidad del puerto USB para prevenir transferencias de archivos no autorizadas, el uso de dispositivos de almacenamiento externos o la carga desde fuentes no confiables. Esta capacidad mejora la postura de seguridad de la organización y ayuda a proteger contra fugas de datos e infecciones de malware introducidas a través de conexiones físicas. ### Desactivar la transferencia de datos USB **Navega a políticas** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), navega a **Políticas** 1. **Selecciona la política de Android** Selecciona la política de Android donde deseas realizar esta configuración. **Ve a la configuración de red** En el menú de la izquierda, haz clic en la sección **Red**. **Deshabilita la transferencia de datos USB** En la configuración de **Gestión de conectividad del dispositivo** 3, elige **Deshabilitar transferencia de datos USB** bajo **Acceso a datos USB** 4. ![disallow usb data transfer](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/4f762a43-e019-4cf5-8ad5-6a235b824d7d.png) Desactivar los puertos USB en dispositivos Android añade una capa importante de protección contra amenazas externas y uso no autorizado. Aplicada de forma remota y centralizada, esta medida asegura que los dispositivos corporativos se utilicen estrictamente en línea con las políticas de seguridad de la organización. Cuando se implementa de manera efectiva, no solo minimiza los riesgos operativos, sino que también refuerza el cumplimiento de los estándares regulatorios, particularmente en entornos donde la seguridad de la información es primordial. ### Compatibilidad con dispositivos AOSP La desactivación de la transferencia de datos USB es totalmente compatible con AOSP — los mismos pasos, sin necesidad de servicios de Google. Especialmente útil para implementaciones robustas e industriales donde la seguridad del puerto físico es una prioridad. --- ## Distribuir certificados Source: https://docs.applivery.com/es/device-management/android/policies/distribute-certificates/ Description: Emite certificados de forma remota en dispositivos Android con Applivery para acceder con seguridad a los recursos corporativos. TL;DR: Emite certificados de forma remota en dispositivos Android con políticas de Applivery para un acceso seguro a los recursos corporativos. Key topics: gestión de dispositivos, seguridad, certificados, android, Applivery, G Suite Los certificados tienen un papel fundamental en la identificación y autenticación de dispositivos móviles, permitiendo el acceso seguro a los recursos corporativos como G Suite y puntos de acceso Wi-Fi empresariales. Algunas organizaciones exigen que los dispositivos estén en las instalaciones y detrás de un cortafuegos para distribuir los certificados de dispositivo. Sin embargo, dado que algunos usuarios ya no pueden acceder a las ubicaciones y redes corporativas, es necesario disponer de una forma de emitir estos certificados de forma remota. Con esta función, las organizaciones pueden garantizar que sus usuarios permanezcan conectados y productivos, incluso cuando trabajan de forma remota. :::warning Esta funcionalidad requiere que el [**agente MDM de Applivery**](https://docs.applivery.com/es/device-management/android/policies/agent/) esté habilitado en la política del dispositivo. ::: ### Añadir un certificado a una política **Ir a Políticas** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a **Políticas** 1. **Seleccionar la política Android** Selecciona la política Android a la que quieres añadir un certificado. **Añadir recurso** En el menú lateral izquierdo, haz clic en la sección **Recursos** 2 y luego en el botón **\+ Añadir Recurso** 3. **Subir el certificado** Se mostrará una vista modal que te permite seleccionar el tipo de archivo que quieres añadir a la política. Selecciona un certificado existente de la sección Recursos o usa **Cargar nuevo recurso**. Los certificados deben subirse en formato `.p12`, `.pem`, `.der`, `.crt` o `.cer`. :::warning Los certificados `.p12` protegidos con contraseña no están soportados. Asegúrate de que el archivo `.p12` que subas no tenga contraseña. ::: **Guardar cambios** Una vez completadas las configuraciones necesarias en tu política, haz clic en **Guardar cambios**. ![add certificate](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/577de775-40f7-474e-990d-2bce17525f75.png) --- ## Política de encriptación Source: https://docs.applivery.com/es/device-management/android/policies/encryption-policy/ Description: Configura la encriptación de dispositivos Android en Applivery — comprende los valores de encryptionPolicy, cómo afectan al arranque del dispositivo y qué configuración elegir para tu despliegue. TL;DR: `encryptionPolicy` controla la encriptación y el comportamiento de arranque en dispositivos Android gestionados. `ENABLED_WITHOUT_PASSWORD` es el valor recomendado para la mayoría de los despliegues porque aplica la encriptación manteniendo el dispositivo gestionable de forma remota. Answers: ¿Qué es encryptionPolicy en el MDM de Android? · ¿Cuál es la diferencia entre ENABLED_WITH_PASSWORD y ENABLED_WITHOUT_PASSWORD? · ¿Qué valor de encryptionPolicy debo usar? · ¿Por qué falla el comando Restablecer contraseña con ENABLED_WITH_PASSWORD? · ¿Qué es el estado Before First Unlock (BFU)? · ¿ENABLED_WITHOUT_PASSWORD es menos seguro? · ¿Dónde configuro encryptionPolicy en Applivery? · ¿Qué ocurre si encryptionPolicy es ENCRYPTION_POLICY_UNSPECIFIED? Key topics: Política de encriptación Android, Encriptación basado en archivos (FBE), Before First Unlock (BFU), Android Device Policy, Configuración del MDM de Applivery, Android, Applivery, Android Management API, encriptación basado en archivos Todos los dispositivos Android inscritos en Applivery MDM tienen su almacenamiento de encriptación por defecto gracias a la [encriptación basada en archivos (FBE)](https://source.android.com/docs/security/features/encryption/file-based) de Android. La configuración `encryptionPolicy` te permite definir exactamente cómo esa encriptación interactúa con el proceso de arranque del dispositivo — lo que tiene un impacto directo en la gestionabilidad remota. ### Cómo funciona la encriptación de Android Android utiliza la **encriptación basada en archivos (FBE)**, que cifra los archivos de forma individual y divide el almacenamiento en dos áreas:

Tipo de almacenamiento

Cuándo está accesible

Qué contiene

Encriptación del Dispositivo (DE)

Inmediatamente tras el arranque, antes de la autenticación del usuario

Procesos del sistema, apps con soporte para Direct Boot, Android Device Policy

Encriptación con Credenciales (CE)

Solo después de que el usuario desbloquee con PIN, contraseña o biometría

Datos del usuario, la mayoría de las apps, archivos personales

Esta separación es lo que hace posible el **Direct Boot**: el dispositivo puede arrancar, conectarse a Wi-Fi y ejecutar servicios esenciales (incluida la comunicación con el MDM) antes de que el usuario haya introducido su PIN. ### Valores de encryptionPolicy El campo `encryptionPolicy` en tu política de Android, controla si la encriptación es obligatoria y cómo gestiona el dispositivo el proceso de arranque. #### ENCRYPTION\_POLICY\_UNSPECIFIED La Android Management API ignora este valor — no se establece ningún requisito de encriptación explícito. El comportamiento de la encriptación depende completamente de los valores predeterminados del propio dispositivo. **Este valor no se recomienda** para despliegues empresariales gestionados. #### ENABLED\_WITHOUT\_PASSWORD (Recomendado) La encriptación es obligatoria, pero el dispositivo **no requiere el PIN al arrancar**. Android deriva la clave de encriptación del hardware del dispositivo al iniciarse, lo que hace que el almacenamiento DE esté disponible de inmediato. El almacenamiento CE (y los datos del usuario) permanece encriptado hasta que el usuario se autentica. Este es el comportamiento estándar de los dispositivos Android modernos y el valor recomendado para los despliegues empresariales porque: - Android Device Policy se inicia con normalidad tras cada reinicio. - Los comandos remotos (incluido Restablecer contraseña) llegan al dispositivo de inmediato. - El encriptación sigue siendo obligatoria — los datos están totalmente protegidos contra ataques fuera del dispositivo. #### ENABLED\_WITH\_PASSWORD La encriptación es obligatoria **y** el dispositivo exige el PIN o la contraseña del usuario al arrancar, antes de descifrar el almacenamiento encriptado. Esto corresponde a la función **Inicio seguro** en los dispositivos Android. :::warning Cuando `ENABLED_WITH_PASSWORD` está activo y un dispositivo se reinicia, entra en estado **Before First Unlock (BFU)** hasta que el usuario introduce su PIN. En estado BFU, Android Device Policy no puede iniciarse — el dispositivo aparece conectado en Applivery pero es completamente inaccesible para los comandos remotos. Consulta [Comandos remotos — Solución de problemas para Restablecer contraseña](https://docs.applivery.com/es/device-management/android/commands/remote-commands/#solución-de-problemas-el-comando-restablecer-contraseña-falla-al-instante) para más información sobre cómo resolver esta situación. ::: Usa este valor solo si tu política de seguridad exige explícitamente la autenticación antes del arranque — por ejemplo, en entornos regulados donde no se permite el arranque desatendido del dispositivo. ### Dónde configurarlo Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a cualquiera de tus **Políticas** 1. En el menú lateral izquierdo, dirígete a **Restricciones** 2, selecciona la sección **Sistema** y localiza el ajuste **Política de encriptación** 3. ![encryption policy](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/d3b94cb2-95d1-43da-8d4d-38d2cfcd45eb.png) ### Cómo elegir el valor correcto

Escenario

Valor recomendado

Despliegue empresarial estándar

ENABLED_WITHOUT_PASSWORD

Dispositivos en modo quiosco o desatendidos

ENABLED_WITHOUT_PASSWORD

Entorno regulado que exige PIN antes del arranque

ENABLED_WITH_PASSWORD (asegura que el acceso físico siempre esté disponible)

Dispositivo bloqueado en BFU y no accesible

Recupéralo físicamente y considera cambiar a ENABLED_WITHOUT_PASSWORD

### Consideraciones de seguridad Una preocupación habitual es si `ENABLED_WITHOUT_PASSWORD` es menos seguro que `ENABLED_WITH_PASSWORD`. La respuesta depende del modelo de amenaza: - **Contra ataques fuera del dispositivo** (extraer el chip de almacenamiento y leerlo externamente): ambos valores ofrecen una protección equivalente mediante el FBE de Android. La clave DE se deriva de una clave ligada al hardware que no puede extraerse sin el dispositivo. - **Contra un atacante con acceso físico a un dispositivo en funcionamiento**: `ENABLED_WITH_PASSWORD` añade una capa adicional impidiendo que el dispositivo arranque de forma desatendida, pero esto debe sopesarse frente al riesgo operativo de que los dispositivos queden permanentemente inaccesibles si el usuario olvida su PIN. Para la mayoría de los despliegues empresariales, `ENABLED_WITHOUT_PASSWORD` ofrece el equilibrio adecuado entre seguridad y control operativo. --- ## Reglas de cumplimiento Source: https://docs.applivery.com/es/device-management/android/policies/enforcement-rules/ Description: Automatiza el cumplimiento en Android con las reglas de cumplimiento de políticas. Aprende a configurar reglas para bloquear el acceso, hacer un borrado remoto y aplicar políticas. TL;DR: Automatiza el cumplimiento en dispositivos Android configurando las reglas de cumplimiento de políticas en Applivery para bloquear el acceso o borrar dispositivos ante un incumplimiento. Answers: ¿Cómo configurar reglas de cumplimiento de políticas en Android? · Automatización del cumplimiento de dispositivos Android · Borrado remoto de un dispositivo Android con Applivery · Bloquear el acceso a un dispositivo Android cuando no cumple las normas · Reglas de cumplimiento de políticas de Applivery · Gestión de políticas de Android Enterprise · ¿Qué son las reglas de cumplimiento de políticas? · Configuración de cumplimiento en Android Key topics: Gestión de dispositivos Android, Aplicación de políticas, Automatización del cumplimiento, Configuración de Applivery, Applivery, Android, Google, Factory Reset Protection (FRP) En la gestión de dispositivos Android empresariales, no solo es esencial definir políticas de seguridad y uso, sino también garantizar que se apliquen de manera efectiva. Las **reglas de cumplimiento de políticas** están diseñadas para detectar y responder automáticamente a las infracciones de políticas, ayudando a las organizaciones a mantener el cumplimiento y proteger su flota de dispositivos. El objetivo principal de esta configuración es proporcionar a los administradores un mecanismo flexible para **automatizar las acciones correctivas** cuando un dispositivo deja de cumplir las normativas. Dependiendo del tipo o la gravedad de la infracción, el sistema puede ejecutar respuestas predefinidas — como bloquear el acceso al dispositivo, realizar un borrado remoto o notificar al usuario — para mitigar riesgos de inmediato y restaurar el cumplimiento. Implementando las reglas de cumplimiento de políticas, las organizaciones pueden garantizar una **protección continua**, un **control en tiempo real** y una **eficiencia operativa** en todos los dispositivos Android gestionados, minimizando las brechas de seguridad y reduciendo la necesidad de intervención manual. ### Configurar las reglas de cumplimiento de políticas **Navegar a Políticas** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), navega a **Políticas** 1. **Seleccionar la política de Android** Selecciona la política de Android donde quieres realizar esta configuración. **Ir a la sección Cumplimiento** A continuacióndirígete a la sección **Cumplimiento** en el menú lateral izquierdo. **Añadir una nueva regla de cumplimiento de políticas** Localiza la configuración de **Reglas de cumplimiento de políticas** 3 y haz clic en el botón **\+ Añadir elemento**. ![reglas de cumplimiento de políticas](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/674d51a7-5e0b-4675-97fc-f17629d06b81.png) #### Acción de bloqueo Define una acción automática que restringe el acceso a las aplicaciones y datos de un dispositivo gestionado o perfil de trabajo cuando no cumple con la política seleccionada. :::tip También se recomienda configurar la **Acción de borrado** para completar el ciclo completo de aplicación del cumplimiento. ::: - **Bloquear después de días**: Especifica el número de días que un dispositivo o perfil puede permanecer fuera de cumplimiento antes de que se aplique el bloqueo. Un valor de **0** aplica el bloqueo inmediatamente. Si se configura con un retraso, el acceso se restringirá una vez transcurrido ese periodo. - **Alcance del bloqueo**: Determina el alcance del bloqueo, normalmente si se aplica a todo el dispositivo o solo al perfil de trabajo. Por ejemplo, al seleccionar **PERFIL DE TRABAJO** se limita el bloqueo a las aplicaciones y datos corporativos, sin afectar al contenido personal. #### Nombre de la configuración Especifica el nombre de la política de nivel superior que se va a aplicar (por ejemplo: `passwordPolicies`). Ayuda a identificar qué política rige la regla y simplifica el seguimiento y la gestión. #### Acción de borrado Define una acción automática que realiza un restablecimiento de fábrica o elimina el perfil de trabajo si no se restaura el cumplimiento en el plazo especificado. :::tip Se recomienda configurar esta acción junto con la **Acción de bloqueo**. ::: - **Preservar FRP**: Indica si la **Protección de restablecimiento de fábrica (FRP)** de Google debe permanecer activada después de un borrado. Aplicable solo a **dispositivos totalmente gestionados**, no a perfiles de trabajo. Consulta [Factory Reset Protection (FRP)](https://docs.applivery.com/es/device-management/android/policies/factory-reset-protection/) para saber cómo funciona y cómo configurarla. - **Borrar después de días**: Define el número de días de incumplimiento antes de que se borre el dispositivo o perfil. Este valor debe ser **mayor** que el establecido para **Bloquear después de días**, lo que garantiza que primero se produzca el bloqueo y, si no se restablece el cumplimiento, después el borrado. Estas opciones de configuración dan a los administradores un control preciso sobre cómo responden los dispositivos a las infracciones de políticas. Al definir acciones específicas, umbrales de tiempo y alcances de aplicación, cada regla puede alinearse perfectamente con las necesidades operativas y de seguridad de la organización. En conjunto, esta configuración transforma la gestión del cumplimiento en un proceso predecible y transparente — donde los administradores saben exactamente qué ocurrirá, cuándo y por qué. Este enfoque estructurado simplifica la supervisión, mejora la coherencia entre dispositivos y ayuda a mantener un entorno estable y orientado a políticas para todos los dispositivos Android gestionados. --- ## Factory Reset Protection (FRP) Source: https://docs.applivery.com/es/device-management/android/policies/factory-reset-protection/ Description: Controla qué cuentas pueden reactivar un dispositivo Android tras un restablecimiento de fábrica, para proteger equipos corporativos frente a robo o pérdida — se configura mediante el campo frpAdminEmails en la política. TL;DR: FRP evita que un dispositivo Android robado o perdido pueda reactivarse tras un restablecimiento de fábrica sin la cuenta de un administrador autorizado. En dispositivos gestionados vía AMAPI no se activa automáticamente — debes configurar el campo frpAdminEmails en la sección Seguridad de la política. Key topics: Factory Reset Protection, frpAdminEmails, preserveFrp, Borrados por incumplimiento, Android Management API, Applivery, Cuentas de Google Factory Reset Protection (FRP) evita que un dispositivo Android robado o perdido pueda reactivarse tras un restablecimiento de fábrica sin la cuenta de un administrador autorizado. En dispositivos gestionados mediante la Android Management API (AMAPI) — como los que administra Applivery — esta protección **no se activa automáticamente**: debes configurar explícitamente el campo **Correos electrónicos del administrador Frp** en la política. ### ¿Qué es Factory Reset Protection? Factory Reset Protection es una función de seguridad de Android que bloquea el uso de un dispositivo después de un restablecimiento de fábrica hasta que alguien inicia sesión con una cuenta de Google autorizada. Su objetivo es desincentivar el robo: un dispositivo con FRP activa que se restablece "a la fuerza" (por ejemplo, desde el menú de recuperación) queda inutilizable para quien no conozca las credenciales de la cuenta vinculada. En el ecosistema de consumo, FRP se activa automáticamente en cuanto hay una cuenta de Google en el dispositivo. **En dispositivos gestionados mediante AMAPI, este comportamiento es distinto y debe configurarse explícitamente.** ### Cómo se comporta FRP en dispositivos gestionados por AMAPI Este es el matiz más importante y el que con más frecuencia genera confusión operativa. :::warning En dispositivos gestionados vía AMAPI, FRP **solo se activa si la política define los** **Correos electrónicos del administrador Frp**. Si este campo no está presente o está vacío, el dispositivo no ofrece protección de restablecimiento de fábrica, incluso si hay una cuenta de Google presente. ::: Además, el propio comportamiento de Android distingue **cómo** se inició el restablecimiento: - **Restablecimiento desde los Ajustes del dispositivo** (el usuario ya tiene sesión iniciada como propietario): en muchos dispositivos totalmente gestionados, un restablecimiento iniciado desde Ajustes por el usuario con sesión iniciada no desencadena FRP del mismo modo que un reset "forzado". Aun así, la protección depende de que los **Correos electrónicos del administrador Frp** estén correctamente configurados. - **Restablecimiento por otras vías** (menú de recuperación, comando de borrado remoto, robo con extracción física): si la política tiene **Correos electrónicos del administrador Frp** configurados, el dispositivo exigirá el email y la contraseña de una de esas cuentas para completar el aprovisionamiento. ### El campo **Correos electrónicos del administrador Frp** **Correos electrónicos del administrador Frp** es un campo que se expone a través de las políticas de Android — el mismo mecanismo mediante el cual otras configuraciones de AMAPI no cubiertas por un control nativo del panel de Applivery (como **Escotilla de Escape de Red Activada** o **Anulaciones de seguridad avanzadas**) se aplican directamente.

Campo

Tipo

Descripción

Correos electrónicos del administrador Frp

array de strings

Direcciones de email de las cuentas de Google autorizadas para desbloquear el dispositivo tras un restablecimiento de fábrica. Si está vacío o ausente, el dispositivo no aplica FRP.

Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a cualquiera de tus **Políticas**. En el menú lateral izquierdo, dirígete a **Seguridad**, localiza la configuración **Correos electrónicos del administrador Frp** y haz clic en **\+ Añadir elemento** para añadir cada cuenta autorizada. :::tip Incluye **al menos dos** cuentas en el campo **Correos electrónicos del administrador Frp** — por ejemplo, una cuenta de equipo y la de un responsable directo. Así evitas que un dispositivo quede permanentemente bloqueado si una única cuenta administrativa deja de estar disponible. ::: #### ¿Debo activar FRP en todos mis dispositivos? Depende del equilibrio entre seguridad y operativa de tu organización:

Escenario

Recomendación

Dispositivos corporativos de alto valor, con riesgo de robo (repartidores, ventas de campo, dispositivos que salen de las instalaciones)

Activar FRP con los Correos electrónicos del administrador Frp apuntando a una cuenta de equipo gestionada por TI

Dispositivos que se reasignan con frecuencia entre empleados o se devuelven a menudo a TI para reaprovisionar

Evaluar si FRP introduce fricción operativa; si el proceso de baja de empleados no está bien engrasado, un dispositivo puede quedar bloqueado a nombre de alguien que ya no está en la organización

Dispositivos dedicados / kiosco sin cuenta de usuario personal

Generalmente no aporta valor adicional, ya que no suele haber una cuenta de Google de un usuario final que proteger

### Conservar Frp: FRP y las reglas de cumplimiento (borrado automático) Cuando un dispositivo se restablece automáticamente por incumplimiento de política (a través de Reglas de aplicación de la política), el campo Conservar Frp dentro de la Acción de borrado determina si los datos de FRP se conservan durante ese borrado. Lo configuras en la sección **Conformidad** de tu política, en el apartado **Policy Enforcement Rules**.

Campo

Ubicación

Tipo

Comportamiento

preserveFrp

Reglas de aplicación de la política > Acción de borrado > Conservar Frp

boolean

Si es true, los datos de FRP se conservan tras el borrado por incumplimiento. Si se omite, el comportamiento por defecto no preserva los datos de FRP.

:::warning **Conservar Frp** solo tiene efecto si el dispositivo ya tenía **Correos electrónicos del administrador Frp** configurados. No activa FRP por sí solo. ::: Para la configuración completa del borrado por incumplimiento, consulta [Reglas de cumplimiento](https://docs.applivery.com/es/device-management/android/policies/enforcement-rules/). ### Limitaciones conocidas - **No aplica a perfiles de trabajo (Work Profile / COPE).** **Correos electrónicos del administrador Frp** opera a nivel de dispositivo completo (modo "totalmente gestionado"). - **Requiere que el dispositivo tenga cuentas de Google de FRP registradas antes del reset.** Si el dispositivo nunca tuvo una cuenta asociada en la política, no habrá credenciales que solicitar. ### Solución de problemas #### Un dispositivo quedó bloqueado por FRP y no se puede reaprovisionar **Comprueba las cuentas autorizadas** Confirma qué cuentas estaban en **Correos electrónicos del administrador Frp** en la política que tenía asignada el dispositivo antes del reset. **Inicia sesión con una cuenta autorizada** Pide a un titular de una de esas cuentas que introduzca sus credenciales en la pantalla de bloqueo de FRP durante la configuración del dispositivo. **Si ninguna cuenta autorizada está disponible** Si ninguna cuenta de **Correos electrónicos del administrador Frp** está disponible (por ejemplo, un empleado que se llevó consigo el acceso), deberás gestionar la recuperación del dispositivo directamente con Google o el fabricante. Applivery no dispone de un mecanismo remoto para omitir FRP una vez activada. #### Necesito que un lote de dispositivos nuevos no quede nunca protegido por FRP Asegúrate de que la política de aprovisionamiento **no incluya los** **Correos electrónicos del administrador Frp**, o de que el array esté explícitamente vacío. --- ## Ocultar el nombre de la organización Source: https://docs.applivery.com/es/device-management/android/policies/hide-organization-name/ Description: Evita que el nombre de la organización de Managed Google Play aparezca en la pantalla de bloqueo y en los Ajustes de tus dispositivos Android gestionados. TL;DR: No puedes renombrar el nombre de la organización que se muestra en los dispositivos, pero sí ocultarlo desde la política. Se aplica en la siguiente sincronización. Key topics: Enterprise display name, Ajuste de visibilidad en la política, Vinculación con Managed Google Play, Applivery, Android, Android Enterprise, Managed Google Play, Google Dispositivos que no mostraban nada empiezan de pronto a enseñar el nombre de tu organización en la pantalla de bloqueo y en los Ajustes, sin que nadie haya tocado una política. Es cosa de Google: el valor por defecto del ajuste `enterpriseDisplayNameVisibility` es ahora **visible**, así que cualquier workspace que nunca lo configurara hereda el nuevo comportamiento. ### De dónde sale el nombre Es el **enterprise display name** de tu organización de Managed Google Play, fijado al vincular la cuenta de Android Enterprise con Applivery. :::warning **No puede renombrarse.** La única forma de cambiar el texto sería desvincular la cuenta de Android Enterprise y volver a vincularla, lo que obliga a reinscribir todos los dispositivos de la flota. En la práctica eso no es un renombrado, es una migración. ::: ### Ocultarlo Lo que sí puedes hacer es que deje de mostrarse. La política expone el ajuste de visibilidad del nombre de empresa, que se corresponde con el `enterpriseDisplayNameVisibility` de Android:

Valor

Efecto

ENTERPRISE_DISPLAY_NAME_VISIBLE

El nombre de la organización se muestra en el dispositivo. Es el valor por defecto actual de Google.

ENTERPRISE_DISPLAY_NAME_HIDDEN

El nombre de la organización no se muestra.

![enterprise display name visibility](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/2066f70a-2cbb-46c6-8399-0e7ec6631620.png) Ponlo en oculto en la política y se aplica en la siguiente sincronización del dispositivo. No hay reseteo, ni reinscripción, ni interacción del usuario. --- ## Modo quiosco Source: https://docs.applivery.com/es/device-management/android/policies/kiosk-mode/ Description: Configura el modo quiosco de Android en Applivery — opciones de Aplicación única, Launcher básico y Launcher avanzado para dispositivos Android dedicados. TL;DR: Configura el modo quiosco de Android en Applivery usando Aplicación única, Launcher básico o Launcher avanzado. El Launcher avanzado ofrece dos modos — Launcher para una experiencia de launcher gestionado y Kiosk para un bloqueo multiaplicación completo — con control granular sobre la navegación, la pantalla y el acceso al sistema. Answers: ¿Qué es el modo quiosco de Android? · ¿Cómo configurar el quiosco de Aplicación única en Applivery? · ¿Cómo configurar el quiosco multiaplicación con Applivery? · ¿Cuál es la diferencia entre el modo Launcher y el modo Kiosk en el Launcher avanzado? · ¿Cuáles son las opciones de bloqueo en el modo quiosco de Aplicación única? · ¿Cómo preparar una app para el modo quiosco de Aplicación única? · ¿Cómo activar el Launcher básico en Applivery? · ¿Puedo controlar el acceso a la configuración del dispositivo en el Launcher avanzado? Key topics: Modo quiosco de Android, Modos de quiosco de Applivery, Configuración de Aplicación única, Configuración multiaplicación, Personalización del Launcher avanzado, Android, Applivery, Device Policy Controller (DPC) El modo quiosco es una de las funciones más utilizadas para desplegar dispositivos Android dedicados. Permite a los administradores de TI bloquear un dispositivo en una sola aplicación o en un conjunto seleccionado de apps, impidiendo que los usuarios accedan a nada fuera de lo que la organización ha definido — sin pantalla de inicio, sin cajón de aplicaciones ni navegación del sistema, a menos que esté explícitamente permitido. Applivery ofrece tres modos de quiosco distintos para Android, cada uno diseñado para diferentes casos de uso y niveles de personalización. :::warning El modo quiosco solo está disponible en dispositivos **Totalmente gestionados**. Consulta las [opciones de gestión de Android](https://docs.applivery.com/es/device-management/android/enrollment/manual-enrollment/#opciones-de-gestión) para más información sobre los tipos de inscripción. ::: ### Modos de quiosco disponibles

Modo

Apps permitidas

Descripción

Aplicación única

Una app

Bloquea el dispositivo completamente en una sola aplicación. El modo más restrictivo.

Launcher básico

Múltiples apps

Quiosco multiaplicación usando el Device Policy Controller nativo de Android.

Launcher avanzado

Múltiples apps

El launcher personalizado de Applivery con dos modos operativos: Launcher (launcher gestionado sin restricciones de quiosco) y Kiosk (bloqueo multiaplicación completo con opciones de configuración ampliadas).

### Versiones mínimas de Android El agente de Applivery admite Android 7.0 (API 24) y superiores, pero algunos ajustes de quiosco necesitan una versión más reciente.

Funcionalidad

Versión mínima de Android

Ajustes de personalización del quiosco: Navegación del sistema, Barra de estado, Configuración del dispositivo, Acciones del botón de encendido y Advertencias de error del sistema

Android 9

Launcher avanzado

Android 8

:::warning **Por debajo de la versión mínima, el ajuste se descarta en silencio.** El dispositivo reporta `nonComplianceReason: API_LEVEL` en sus comprobaciones de conformidad, pero no falla nada ni se reinicia nada: la configuración simplemente no surte efecto. Comprueba la versión de Android antes de dar por mala la política. ::: ### Modo quiosco de Aplicación única El modo quiosco de Aplicación única bloquea el dispositivo en una aplicación específica. Los usuarios no pueden salir de la app, acceder a la pantalla de inicio ni llegar a ninguna otra parte del dispositivo a menos que el administrador lo permita explícitamente. Es el modo ideal para terminales de punto de venta, quioscos de autoservicio, señalización digital, dispositivos de recopilación de datos y cualquier otro despliegue de propósito único. **Cómo configurar el modo quiosco de Aplicación única** El modo quiosco de Aplicación única se configura a nivel de política en Applivery. Ve a cualquiera de tus políticas 1 o [crea una nueva](https://docs.applivery.com/es/device-management/general-settings/create-policies/). En el menú lateral izquierdo, haz clic en **Quiosco** y selecciona la opción **Aplicación única** 2. Elige la app en la que bloquear el dispositivo en el menú desplegable 3. Si no aparece ninguna app dirígete a la sección **Apps** de la política y añade al menos una app con Instalación forzada primero. ![aplicación única](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/cdcd765f-662b-4ddd-be51-beb63b8aea4b.png) Configura las opciones de comportamiento de bloqueo (descritas a continuación). **Opciones de bloqueo de Aplicación única**

Opción

Descripción

Configuración del dispositivo

Si la app de Configuración es accesible en el modo quiosco.

Acciones del botón de encendido

Controla el comportamiento al mantener pulsado el botón de encendido.

Barra de estado

Especifica si la información del sistema y las notificaciones están desactivadas en el modo quiosco.

Advertencias de error del sistema

Si los diálogos de error del sistema para apps bloqueadas o que no responden están bloqueados. Cuando se bloquean, el sistema fuerza el cierre de la app como si el usuario hubiera seleccionado "Cerrar app".

Navegación del sistema

Especifica qué funciones de navegación están habilitadas (p. ej., botón de inicio, botón de recientes).

Escape de red

Si está activado y no se puede establecer una conexión de red al arrancar, se solicita al usuario que se conecte temporalmente a una red para actualizar la política del dispositivo. La conexión temporal se olvida una vez que se actualiza la política.

:::warning **Recomendamos encarecidamente activar el escape de red** en todos los modos de quiosco. Sin él, un dispositivo que no consiga conectarse a la red al arrancar — por ejemplo, porque la última red conocida ya no está disponible — puede quedar bloqueado e incapaz de recibir actualizaciones de políticas, especialmente cuando arranca directamente en una app bloqueada. ::: **Preparar tu app para el modo quiosco de Aplicación única** :::warning Declarar `android.intent.category.HOME` en el filtro de intents de la actividad principal de tu app puede impedir que ciertas configuraciones del quiosco — como las restricciones de navegación del sistema o el control de la barra de estado — se apliquen correctamente en algunos dispositivos. Prueba en detalle en tu hardware de destino antes de desplegar. ::: ### Launcher básico (modo quiosco multiaplicación) El Launcher básico permite a los administradores definir una lista de aplicaciones permitidas que se muestran en una interfaz de pantalla de inicio bloqueada. Está basado en el Device Policy Controller (DPC) nativo de Android y proporciona una base sólida para despliegues de quioscos multiaplicación sin necesidad de licencias adicionales. **Cómo configurar el Launcher básico** Dentro de la política dirígete a la sección **Apps**. Haz clic en **\+ Añadir App** y añade cada aplicación que quieras poner disponible en el launcher del quiosco. Reglas clave para la visibilidad de apps en el Launcher básico: - Solo las apps configuradas como **Instalación forzada** aparecerán en la interfaz del launcher. - Todas las [apps del sistema](https://docs.applivery.com/es/device-management/android/app-management/system-apps/) están **ocultas por defecto** — si necesitas que una app del sistema sea visible (p. ej., Teléfono, Cámara, Chrome), debes añadirla explícitamente. **Activar el Launcher básico** En el menú lateral izquierdo, haz clic en **Quiosco** y selecciona la opción **Launcher básico** 4. Configura las opciones de comportamiento de bloqueo (las mismas opciones que el modo de Aplicación única — consulta la tabla anterior). ![launcher básico](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/91436c94-1b10-4d35-9ba9-b6ba4a61b470.png) ### Launcher avanzado (modo quiosco multiaplicación) El Launcher avanzado es el launcher personalizado de Applivery para políticas Android en dispositivos Totalmente gestionados. A diferencia del Launcher básico, introduce dos modos operativos distintos — **Launcher** y **Kiosk** — que sirven a diferentes escenarios de despliegue con distintos niveles de restricción. Para activarlo, dirígete a la sección **Quiosco** y cambia a la pestaña **Launcher avanzado** 5. ![advanced launcher](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/60dc68a2-2205-4bf7-9474-5857231a49a7.png) #### Modos operativos **Launcher** reemplaza el launcher predeterminado de Android con el launcher gestionado de Applivery, pero no activa un modo quiosco restringido. El dispositivo sigue funcionando como un terminal Android normal en términos de experiencia general — pero a través de la capa del launcher de Applivery, que permite configuraciones avanzadas basadas en política que el launcher nativo de Android no admite (por ejemplo, aplicar un fondo de pantalla corporativo). Este modo es la opción adecuada cuando quieres una experiencia de launcher gestionado y controles adicionales sin bloquear el dispositivo en un conjunto definido de apps. **Kiosk** activa un quiosco multiaplicación completo: una pantalla bloqueada con una o más aplicaciones disponibles para el usuario, sin una experiencia de launcher abierta. Es el modo adecuado para dispositivos dedicados donde el dispositivo debe permanecer restringido a un conjunto específico de apps. Además de las capacidades del modo Launcher, el modo Kiosk añade control centralizado sobre la navegación de la pantalla, el comportamiento del botón de encendido, la barra de estado, los errores del sistema y la recuperación de red — los controles típicos de una configuración de quiosco tradicional. #### Configuración general Estos ajustes se aplican a **ambos modos, Launcher y Kiosk**. ##### Modo del launcher Selecciona el modo operativo — **Launcher** o **Kiosk** — desde el selector del **Modo del launcher**  6. Es el ajuste más importante en la configuración del Launcher avanzado: determina si el dispositivo ejecuta un launcher gestionado sin restricciones de quiosco, o entra en un escenario de quiosco completo. ![app operation mode](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/6bc624e4-07a8-43fa-8e40-d2b47f3b72c5.png) ##### Personalización Personaliza la apariencia visual del launcher gestionado: - **Fondo de pantalla**: URL de la imagen de fondo. Debe apuntar a un host accesible desde la web donde esté almacenada la imagen. - **Tamaño de iconos**: Pequeño, Mediano o Grande. - **Disposición de apps**: Organiza la distribución de las apps en la pantalla. - **Carpetas**: Agrupa las apps en carpetas para una disposición más limpia. Ambos campos admiten [variables dinámicas](https://docs.applivery.com/es/device-management/general-settings/dynamic-variables/) — por ejemplo, para mostrar el número de serie del dispositivo o la dirección de correo electrónico del usuario asignado. **App de inicio:** Al tocar una app específica en la configuración del Launcher avanzado, puedes marcarla como la **app de inicio**. Esto hace que la app se inicie automáticamente la primera vez que se instala en el dispositivo — especialmente útil para aplicaciones que requieren una configuración inicial o un flujo de incorporación antes que cualquier otra cosa. ##### Configuración de pantalla - **Mantener la pantalla siempre encendida**: Mantiene la pantalla permanentemente activa, evitando que se apague. ##### Control de acceso a la Configuración El Launcher avanzado ofrece un control granular sobre cómo — o si — los usuarios pueden acceder a la Configuración del dispositivo: - **Restringir el acceso completamente**: Impedir que se abra la app de Configuración. - **Configurar la vista de destino**: Elegir qué pantalla de Configuración se abre cuando el usuario toca Configuración, en lugar de mostrar el menú completo. - **Proteger con contraseña la Configuración**: Requerir una contraseña para acceder a la app de Configuración, asegurando que solo los usuarios autorizados (como técnicos o responsables de tienda) puedan realizar cambios a nivel de sistema en el dispositivo. #### Opciones ##### Ajustes exclusivos del modo Kiosk :::warning **Estos ajustes solo se aplican si el dispositivo está realmente en modo quiosco.** Se corresponden con el bloque `kioskCustomization` de Android, que el sistema solo respeta mientras el modo lock task está activo: es decir, con una app cuyo tipo de instalación sea **Quiosco**, o con el Launcher avanzado en modo **Kiosk**. Fijar un launcher como app HOME predeterminada del dispositivo **no** es lo mismo. Un launcher fijado mediante `persistentPreferredActivities` pasa a ser la pantalla de inicio, pero nunca activa el modo lock task, así que el bloque entero se descarta sin ningún error. ::: Los siguientes ajustes solo están disponibles cuando se selecciona el modo **Kiosk**.

Ajuste

Descripción

Configuración del dispositivo

Si la app de Configuración es accesible (permitida) o está bloqueada para el usuario.

Acciones del botón de encendido

Controla el comportamiento al mantener pulsado el botón de encendido. Disponible mantiene el menú de encendido accesible; Bloqueado impide que el usuario apague o reinicie el dispositivo con los botones de encendido.

Barra de estado

Si la barra de estado, las notificaciones y la información del sistema son visibles. Opciones: todo habilitado, todo deshabilitado o solo información del sistema.

Advertencias de error del sistema

Cuando está silenciado, los diálogos de error del sistema (bloqueos o mensajes de "la app no responde") se suprimen y la app se cierra forzosamente de forma automática, evitando ventanas emergentes que rompen la experiencia del quiosco.

Navegación del sistema

Si los botones de Inicio y Recientes son accesibles. Navegación habilitada permite al usuario navegar libremente; Navegación deshabilitada elimina el acceso por completo; Solo botón de inicio restringe solo al botón de Inicio.

##### Barra de estado y acceso a la Configuración En Android, la barra de estado y el panel desplegable son el mismo mecanismo. Desactivar la barra bloquea también las notificaciones, los ajustes rápidos y el resto de superposiciones que permiten escapar del modo de pantalla completa, que es justo el motivo por el que existe como control de quiosco. La consecuencia práctica: no hay forma de mostrar la barra de estado y ocultar únicamente el acceso a la Configuración. Los tres valores de abajo son toda la granularidad disponible.

Valor

Comportamiento

NOTIFICATIONS_AND_SYSTEM_INFO_ENABLED

Barra visible y panel desplegable disponible.

SYSTEM_INFO_ONLY

Información del sistema sin notificaciones.

NOTIFICATIONS_AND_SYSTEM_INFO_DISABLED

Todo desactivado. Es el valor por defecto en modo quiosco.

Como el valor por defecto es desactivado, un dispositivo donde el panel sea accesible es un dispositivo donde alguien lo habilitó expresamente. ##### Ajustes comunes — Launcher y Kiosk **Escape de red**: Si el dispositivo no puede establecer una conexión de red al arrancar, se ofrece al usuario un acceso temporal de recuperación de red para actualizar la política. Una vez aplicada la política, la red temporal se olvida y el proceso de arranque continúa con normalidad. :::warning Recomendamos encarecidamente activar el escape de red en todas las políticas del Launcher avanzado. Sin él, un dispositivo que no consiga conectarse al arrancar puede quedar bloqueado e incapaz de recibir actualizaciones de políticas. Ten en cuenta que esta opción puede ser anulada por restricciones de Wi-Fi como **Wifi Config Disabled** o **Configure Wifi = DISALLOW\_CONFIGURING\_WIFI**. ::: #### Configuración avanzada de pantalla Además del ajuste de pantalla general anterior, el Launcher avanzado expone controles más detallados sobre el brillo, el tiempo de espera y el comportamiento de la alimentación. Estos ajustes permiten afinar el comportamiento operativo del dispositivo en ambos modos.

Ajuste

Descripción

Brillo de pantalla

Modo de brillo: Elección del usuario, Automático o Fijo.

Tiempo de espera de la pantalla

Si el tiempo de espera lo determina el usuario (Elección del usuario) o lo impone la política.

Tiempo máximo hasta bloqueo

Periodo máximo de inactividad antes de que el dispositivo se bloquee, con valor y unidad configurables.

Mantener encendido mientras está enchufado

Qué fuentes de alimentación mantienen la pantalla activa: Cargador de CA, Puerto USB y/o Inalámbrico. Útil para quioscos fijos o terminales siempre activos.

La interfaz del launcher también admite un **encabezado** y un **pie de página** personalizables, configurables tocando el área correspondiente en la vista previa: - **Encabezado**: Texto que se muestra en la parte superior de la interfaz del launcher o quiosco. - **Pie de página**: Texto que se muestra en la parte inferior de la interfaz del launcher o quiosco. Ambos admiten [variables dinámicas](https://docs.applivery.com/es/device-management/general-settings/dynamic-variables/) — por ejemplo, el nombre del dispositivo o el correo electrónico del usuario — lo que es especialmente útil para dispositivos compartidos desplegados en múltiples ubicaciones. ### Cómo elegir el modo de quiosco adecuado

Escenario de despliegue

Modo recomendado

Terminal de punto de venta con una sola app de TPV

Aplicación única

Quiosco de autoservicio o panel informativo

Aplicación única

Dispositivo de recopilación de datos (una app de campo)

Aplicación única

Dispositivo compartido con múltiples apps de trabajo aprobadas

Launcher básico

Dispositivo gestionado que necesita un launcher corporativo con controles de política, sin bloqueo completo de quiosco

Launcher avanzado — modo Launcher

Dispositivo retail con experiencia de marca y herramientas corporativas

Launcher avanzado — modo Kiosk

Señalización digital con requisito de pantalla siempre encendida

Launcher avanzado — modo Kiosk

Dispositivo compartido que requiere identificación por ubicación

Launcher avanzado — modo Kiosk (con variables dinámicas en encabezado/pie)

Quiosco que requiere acceso a Configuración solo para técnicos

Launcher avanzado — modo Kiosk (con Configuración protegida por contraseña)

### Soporte para dispositivos AOSP En dispositivos AOSP, el modo quiosco es compatible tanto a través del **quiosco de Aplicación única** como del **Launcher avanzado**. El **Launcher básico** no está disponible en AOSP — depende de la infraestructura del Device Policy Controller (DPC) nativo de Android que los dispositivos AOSP no tienen. #### Launcher avanzado en AOSP El Launcher avanzado funciona en dispositivos AOSP exactamente igual que en dispositivos totalmente gestionados (AMAPI) — sin limitaciones. Están disponibles ambos modos operativos (**Launcher** y **Quiosco**), junto con todas las opciones de configuración descritas en la sección [Launcher avanzado](#launcher-avanzado-modo-quiosco-multiaplicación) anterior, incluyendo la personalización, el control de acceso a la configuración, los ajustes avanzados de pantalla y el escape de red. Se configura exactamente de la misma manera, desde la sección **Quiosco** de la política. #### Quiosco de Aplicación única en AOSP Para configurar el quiosco de Aplicación única en un dispositivo AOSP, añade la app de destino a la política con **Tipo de instalación = Quiosco** (solo una app por política puede tener este tipo de instalación) y, a continuación, abre la sección **Quiosco** y configura:

Ajuste

Descripción

Botón de encendido

Permitir, desactivar o pulsar una vez para apagar la pantalla.

Advertencias de error del sistema

Mostrar u ocultar los diálogos de error del sistema.

Navegación del sistema

ENABLED, DISABLED o HOME_BUTTON_ONLY.

Barra de estado

Mostrar u ocultar la barra de estado.

Configuración del dispositivo

Permitir o bloquear el acceso a la Configuración.

Escape de red

Solicitar al usuario que se conecte temporalmente a una red si el dispositivo no puede alcanzar el backend de Applivery al arrancar.

:::warning **Activa el escape de red en todas las políticas de quiosco AOSP.** Sin él, un dispositivo que no consiga conectarse al arrancar puede volverse inaccesible y requerir un restablecimiento de fábrica para recuperarlo. ::: --- ## Gestión de la ubicación Source: https://docs.applivery.com/es/device-management/android/policies/location-management/ Description: Controla la ubicación en dispositivos Android con Applivery — el servicio de ubicación a nivel de sistema (locationMode) y los permisos de ubicación por app, y cómo cada uno depende del modo de gestión. TL;DR: Applivery controla la ubicación a dos niveles: a nivel de sistema (modo de localización, cualquier dispositivo) y por app (Concesión de permisos). Puedes pre-conceder la ubicación sin interacción en dispositivos completamente administrados y dedicados, pero no en COPE ni perfil de trabajo (BYOD), donde Android exige que el usuario la apruebe. Answers: ¿Puedo forzar la ubicación de alta precisión en todos mis dispositivos Android? · ¿Puedo pre-conceder el permiso de ubicación a una app sin que el usuario lo apruebe? · ¿Por qué no puedo pre-conceder ubicación en un dispositivo COPE o BYOD? · ¿Applivery puede mostrarme la última ubicación conocida de mis dispositivos? Key topics: Control de ubicación a nivel de sistema, Permisos de ubicación por app, Diferencias por modo de gestión, Reporte de ubicación, Android, Applivery, Android Management API, COPE, perfil de trabajo El control disponible sobre la ubicación en Android no es el mismo en todos los dispositivos: depende de si el dispositivo es completamente administrado / dedicado o si tiene un perfil de trabajo (COPE o BYOD). Applivery te da dos niveles de control — el servicio de ubicación del sistema y los permisos de ubicación por app — y el segundo se comporta de forma distinta según el modo. ### Control de ubicación a nivel de sistema Independientemente del modo de gestión, puedes controlar si el servicio de ubicación está activo con el campo **Modo de localización**. Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a cualquiera de tus **Políticas**. Desde el menú lateral izquierdo, selecciona **Todas las propiedades** y localiza la configuración **Modo de localización**. Tiene tres valores posibles:

Valor

Qué hace

LOCATION_USER_CHOICE

El ajuste de ubicación no está restringido en el dispositivo. No se impone ningún comportamiento específico — el usuario decide.

LOCATION_ENFORCED

Fuerza la ubicación activada en el dispositivo.

LOCATION_DISABLED

Fuerza la ubicación desactivada en el dispositivo.

:::warning En Android 11 y versiones posteriores, los perfiles de trabajo en dispositivos de propiedad corporativa (COPE) **no pueden forzar directamente** la activación o desactivación de la ubicación a nivel de dispositivo. Si fuerzas `LOCATION_ENFORCED` o `LOCATION_DISABLED` en ese escenario, Applivery reporta un `NonComplianceDetail` con motivo `USER_ACTION`, y el cumplimiento solo se restaura cuando el usuario cambia el ajuste de ubicación manualmente desde los Ajustes del dispositivo. En la práctica, en COPE estos dos valores actúan más como una señal de cumplimiento — el dispositivo queda marcado como no conforme hasta que el usuario actúa — que como una imposición silenciosa e inmediata. ::: ![location mode](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/684327c1-1309-4627-b585-eeb24fc37cce.png) Existe además un campo separado, **Compartir ubicación desactivado**, que controla específicamente si el uso compartido de ubicación está desactivado. Es una configuración distinta a **Modo de localización** — más cercana a lo que la Feature List de Applivery describe como _Location sharing management_ (impedir que las apps del perfil de trabajo compartan ubicación) — y no debe confundirse con el interruptor de sistema. ### Permisos de ubicación por app: Concesión de permisos Applivery gestiona los permisos de apps —ubicación incluida— desde **Políticas → Apps**. Dentro de una política, abre la sección **Apps** desde el menú lateral izquierdo y selecciona la app de tu lista de apps instaladas. Si la app que quieres gestionar todavía no está instalada, instálala primero mediante una de las vías que Applivery proporciona y, una vez instalada, selecciónala. Esto abre las propiedades gestionadas de la app, incluida una sección **Permisos** con dos formas de control: - **Política de permisos por defecto**: una regla global (Solicitar / Conceder / Denegar) para todos los permisos que pida la app. ![default permission policy](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/d7bba615-df3c-49aa-a55c-2c2387a0b0b0.png) - **Concesión de permisos**: reglas específicas por permiso. Para la ubicación, añade un elemento, elige el permiso `location` en el desplegable y fija su política en **Conceder** (concedido automáticamente), **Denegar** (denegado automáticamente) o **Solicitar** (el usuario decide). ![permission grant](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/870151dd-85c6-4e54-ba74-ac84e490bb2a.png) Esto aplica a apps con `targetSdkVersion` 23 o superior, y funciona igual en dispositivos AOSP. #### Dispositivos completamente administrados y dispositivos dedicados En dispositivos totalmente corporativos (sin perfil personal separado), una **Concesión de permiso** en **Conceder** concede el permiso de ubicación sin que el usuario vea ningún diálogo. Es el enfoque habitual para: - Apps de seguimiento de flotas en dispositivos de logística. - Apps de servicio de campo en dispositivos dedicados. - Dispositivos de punto de venta o reparto que necesitan ubicación para operar. #### COPE y Perfil de trabajo (BYOD) :::warning En COPE y Perfil de trabajo (BYOD), `ACCESS_FINE_LOCATION` y `ACCESS_COARSE_LOCATION` **no se pueden pre-conceder ni bloquear** dentro del perfil de trabajo. Es una limitación técnica de la plataforma Android, no una recomendación de buenas prácticas — el usuario siempre debe aprobar el permiso manualmente. ::: Esto forma parte de un patrón más amplio: en COPE, cualquier permiso, restricción o configuración aplicada por política solo afecta al perfil de trabajo, nunca al perfil personal — y ciertos permisos sensibles (ubicación, cámara, micrófono) no se pueden pre-conceder ni siquiera dentro del propio perfil de trabajo. Consulta [Limitaciones de permisos COPE](https://docs.applivery.com/es/device-management/android/cope-permission-limits/) para el detalle completo. Por eso, para COPE y BYOD, informa con claridad a los usuarios sobre qué apps del perfil de trabajo acceden a su ubicación y con qué finalidad, en lugar de intentar forzar una concesión silenciosa que la plataforma no permite de todos modos. ### Reporte de ubicación a Applivery Además del permiso de la app en sí, que Applivery muestre la última ubicación conocida de un dispositivo en la consola depende de dos cosas: que el agente de Applivery tenga el permiso de ubicación concedido y que el servicio de ubicación del sistema no esté desactivado. Esto alimenta la pestaña de ubicación en el detalle del dispositivo — útil para localizar equipos perdidos o verificar que los dispositivos de campo operan en la zona esperada. Applivery muestra la **última ubicación conocida**, no un seguimiento continuo en tiempo real. El seguimiento continuo requeriría una app de seguimiento dedicada. ### Recomendaciones por caso de uso

Caso de uso

Recomendación

Flotas de logística o trabajadores de campo (Completamente administrados / Dedicados)

Concede el permiso de ubicación vía la Concesión de permisos (Conceder). Fuerza el servicio del sistema con LOCATION_ENFORCED si debe estar siempre activo.

Flotas BYOD o COPE corporativas

No intentes pre-conceder el permiso — la plataforma no lo permite en el perfil de trabajo. Informa a los usuarios qué apps acceden a su ubicación y por qué.

Dispositivos en modo quiosco

Si el caso de uso no necesita ubicación, desactiva el servicio a nivel de sistema para reducir el consumo de batería.

--- ## Pantalla de bloqueo con Keyguard Source: https://docs.applivery.com/es/device-management/android/policies/lock-screen-keyguard/ Description: Protege los dispositivos Android gestionando las funciones del Keyguard. Personaliza los ajustes de la pantalla de bloqueo, desactiva funciones y aplica políticas de seguridad con Applivery. TL;DR: Applivery permite a los administradores gestionar las funciones del Keyguard de Android, personalizando la seguridad de la pantalla de bloqueo y aplicando políticas para una mayor protección del dispositivo. Answers: ¿Cómo gestionar el Keyguard de Android con Applivery? · ¿Cómo desactivar la cámara en la pantalla de bloqueo de Android con MDM? · ¿Cómo ocultar las notificaciones en la pantalla de bloqueo de Android con Applivery? · ¿Qué funciones del Keyguard se pueden desactivar mediante MDM? · ¿Cómo aplicar políticas de contraseña en la pantalla de bloqueo de Android? · ¿Cómo configurar los ajustes de seguridad de la pantalla de bloqueo de Android? · ¿Cómo desactivar el desbloqueo por huella dactilar en dispositivos Android de forma remota? Key topics: Gestión del Keyguard de Android, Configuración de la seguridad de la pantalla de bloqueo, Funciones de Applivery MDM, Desactivación de funcionalidades del Keyguard, Buenas prácticas de seguridad en Android, Android, Keyguard, Applivery, Android 6, Android 7, Android 14, Administradores de TI Los dispositivos Android cuentan con potentes funciones de seguridad diseñadas para proteger los datos y la privacidad del usuario. La más importante es el **keyguard**, o pantalla de bloqueo, que aparece antes de acceder a la pantalla de inicio o las apps del dispositivo y sirve como primera línea de defensa contra el acceso no autorizado. El Keyguard exige una autenticación segura mediante PIN, contraseña, patrón o biometría — como huella dactilar o reconocimiento facial — y también ofrece funciones adicionales como la visualización de notificaciones, accesos directos a la cámara y controles multimedia directamente en la pantalla de bloqueo. Gestionar las funciones del **Keyguard de Android** y de la **pantalla de bloqueo** permite a los administradores de TI definir qué funciones permanecen accesibles antes de la autenticación del usuario, aplicar las políticas de seguridad de la organización y crear una experiencia de usuario fluida. Con Applivery, los administradores pueden configurar el comportamiento de la pantalla de bloqueo de forma centralizada, personalizar qué funciones están habilitadas y garantizar el cumplimiento en toda la flota de dispositivos, ayudando a equilibrar la comodidad y una protección robusta del dispositivo. ### Personalizar el comportamiento del Keyguard Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a cualquiera de tus políticas 1. En el menú lateral izquierdo, dirígete a **Restricciones** y localiza la sección **Apps**. ![funciones del keyguard desactivadas](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/02901587-f1e4-4c83-bc19-a6936151cb98.png) Localiza las **Funciones del Keyguard desactivadas** 2 y haz clic en **\+ Añadir elemento** para expandir todos los campos de configuración: - **Cámara**: Desactiva la cámara en las pantallas del keyguard seguro, impidiendo el acceso incluso si la pantalla de bloqueo normalmente lo permite (p. ej., el widget de cámara no será accesible). - **Notificaciones**: Oculta todas las notificaciones en las pantallas del keyguard seguro. Cuando está activado, no aparecerá ninguna notificación — independientemente del contenido. - **Notificaciones sin redactar**: Oculta solo el contenido sensible o "sin redactar" en las pantallas del keyguard seguro. La notificación en sí sigue siendo visible, pero sus detalles quedan ocultos. - **Agentes de confianza**: Ignora los agentes de confianza que normalmente mantienen el dispositivo desbloqueado en ciertas condiciones (p. ej., cuando está emparejado con un smartwatch de confianza). Cuando está desactivado, el dispositivo siempre se bloquea independientemente de los agentes de confianza activos. - **Desactivar huella dactilar**: Impide la autenticación por huella dactilar en la pantalla del keyguard. Los usuarios deben desbloquear con PIN, contraseña o patrón. - **Desactivar entrada remota**: En Android 6 y versiones anteriores, desactiva la introducción de texto en notificaciones en pantallas del keyguard seguro. No tiene efecto en Android 7 o posterior. - **Cara**: Desactiva la autenticación por reconocimiento facial en las pantallas del keyguard seguro. - **Iris**: Desactiva la autenticación por iris en las pantallas del keyguard seguro, impidiendo el desbloqueo mediante escáner de iris. - **Biometría**: Desactiva toda la autenticación biométrica (huella dactilar, cara, iris) en las pantallas del keyguard seguro. Es una opción más amplia que los controles biométricos individuales. - **Accesos directos**: En Android 14 y posterior, desactiva todos los accesos directos de la pantalla de bloqueo, impidiendo el acceso rápido a funciones como la cámara o la linterna. - **Todas las funciones**: Desactiva todas las funciones y personalizaciones actuales y futuras del keyguard a la vez (p. ej., cámara, notificaciones, biometría). Ideal para entornos que requieren un control estricto, como quioscos, donde los usuarios solo deben acceder a la aplicación designada. Gestionar las funciones del Keyguard en dispositivos Android es esencial para controlar tanto la seguridad como la experiencia del usuario. Al desactivar funciones específicas como la autenticación biométrica, las notificaciones o los accesos directos, puedes adaptar el comportamiento del dispositivo para satisfacer necesidades específicas, ya sea mejorar la seguridad en un entorno corporativo u optimizar un dispositivo para su uso como quiosco digital. Comprender estas funcionalidades permite a los administradores de dispositivos y desarrolladores de apps implementar políticas de seguridad robustas y garantizar que los usuarios solo puedan acceder a las funciones que necesitan. En definitiva, un keyguard bien configurado no solo protege el dispositivo frente al acceso no autorizado, sino que también contribuye a un ecosistema Android más seguro y controlable. Con las herramientas y los conocimientos adecuados, el keyguard evoluciona de una simple pantalla de bloqueo a una potente herramienta de gestión de la seguridad del dispositivo. ### Controlar cuándo se bloquea el dispositivo Las funciones desactivadas del Keyguard controlan **qué** está disponible en la pantalla de bloqueo. Para controlar **cuándo** se bloquea el dispositivo tras un periodo de inactividad, necesitas dos ajustes distintos. Los dos están disponibles en cualquier política Android. Ve a tu política y abre la sección **Todas las propiedades** desde el menú lateral izquierdo: - **Tiempo de espera de pantalla**: controla cuánto tiempo permanece inactivo el dispositivo antes de que se apague la pantalla. Para aplicar un valor en lugar de dejarlo a elección del usuario, pon el **modo del tiempo de espera de pantalla** en *aplicado*. Si lo dejas en *elección del usuario*, el valor lo elige el usuario y el tiempo de espera no debe configurarse. - **Tiempo máximo hasta el bloqueo**: el tiempo máximo de inactividad antes de que el sistema bloquee el dispositivo. El valor `0` significa que no hay restricción. Para cumplir un requisito del tipo *"el dispositivo debe bloquearse tras 90 segundos de inactividad"*, configura **los dos**: uno apaga la pantalla y el otro es el techo tras el cual el sistema fuerza el bloqueo. :::warning **El tiempo de espera de pantalla no debe ser mayor que el tiempo máximo hasta el bloqueo.** Si lo es, Android ajusta el tiempo de espera al valor del tiempo máximo hasta el bloqueo y marca el dispositivo como no conforme, con motivo `INVALID_VALUE` y razón específica `SCREEN_TIMEOUT_GREATER_THAN_MAXIMUM_TIME_TO_LOCK`. El tiempo de espera de pantalla también debe ser mayor que 0, o la política se rechaza. ::: :::info **Cada modelo de dispositivo tiene su propio límite inferior para el tiempo de espera de pantalla.** Si configuras un valor por debajo, Android lo sube a ese límite sin avisar. Google no publica estos límites y varían según el dispositivo, así que si necesitas un tiempo corto — por debajo de un minuto — pruébalo en un dispositivo de cada modelo del parque antes de desplegarlo. ::: **Requisitos de versión:** el tiempo de espera de pantalla requiere **Android 9 o posterior** en dispositivos totalmente gestionados; en versiones anteriores el dispositivo reporta una no conformidad con motivo `API_LEVEL`. En perfiles de trabajo sobre dispositivos corporativos requiere **Android 15 o posterior**. El tiempo máximo hasta el bloqueo no tiene restricción de versión. ### Soporte para dispositivos AOSP Todas las funciones desactivadas del Keyguard funcionan igual en AOSP — mismas opciones, mismos pasos. La diferencia clave es el alcance: como el Applivery DPC se ejecuta como propietario del dispositivo, las restricciones se aplican a toda la pantalla de bloqueo del dispositivo en lugar de solo al perfil de trabajo. No hay un keyguard de desafío de trabajo separado en AOSP. --- ## Gestionar credenciales Source: https://docs.applivery.com/es/device-management/android/policies/manage-credentials/ Description: Controla qué apps pueden actuar como gestor de credenciales (contraseñas, passkeys y autocompletado) en los dispositivos Android gestionados con Applivery. TL;DR: Credential Provider Policy Default (Todas las propiedades) bloquea todos los gestores de credenciales con DISALLOWED o no restringe ninguno con ALLOWED. Con DISALLOWED, autoriza apps concretas con Credential Provider Policy = Allowed en sus propiedades. Requiere Android 15 o superior. Answers: ¿Cómo bloquear los gestores de contraseñas en Android con Applivery? · ¿Cómo impedir que el usuario active un gestor de credenciales distinto del corporativo? · ¿Cómo permitir un gestor de credenciales concreto desde las propiedades de la app? · ¿Cómo autorizar un gestor de contraseñas concreto (lista de permitidos) en Android? · ¿Cómo dejar los gestores de credenciales sin restricción? · ¿Dónde se configura credentialProviderPolicyDefault en Applivery? · ¿Qué ocurre con los gestores de credenciales en un perfil de trabajo? · ¿Por qué un dispositivo Android reporta que la política de proveedores de credenciales no es compatible? Key topics: Credential Provider Policy Default, Credential Provider Policy por app, Lista de permitidos de gestores de credenciales, Perfil de trabajo, Resolución de problemas, Applivery, Android, Android Management API, Android Device Policy, Managed Google Play Un **gestor de credenciales** (o proveedor de credenciales) es la app que guarda y rellena contraseñas, passkeys y otros datos de acceso en el dispositivo. El usuario elige el suyo en **Ajustes → Contraseñas, claves de acceso y cuentas → Servicio preferido** (el nombre exacto varía según el fabricante). Con Applivery decides cuáles de esos servicios puede activar. El ajuste **Credential Provider Policy Default**, en **Todas las propiedades** de la política Android, define qué ocurre por defecto: con `DISALLOWED` se bloquean todos los gestores y con `ALLOWED` no se restringe ninguno. Con `DISALLOWED` puedes autorizar apps concretas poniendo **Credential Provider Policy** en **Allowed** en las propiedades de cada app dentro de la política. ### Antes de empezar - El dispositivo debe ejecutar **Android 15 o superior**. En versiones anteriores no se garantiza que el ajuste se aplique. - El ajuste se configura en cualquier política Android del panel de Applivery y se aplica a los dispositivos a los que esa política esté asignada. - Para autorizar un gestor concreto, la app debe estar **añadida a la política** (sección **Apps**). En una app de terceros, lo habitual es distribuirla con instalación forzada desde Managed Google Play. :::info Esta política decide **qué gestores puede activar el usuario**; no define reglas de contraseña ni de bloqueo de pantalla. Para eso, consulta [Políticas de contraseña](https://docs.applivery.com/es/device-management/android/policies/password-policy/) y [Pantalla de bloqueo con Keyguard](https://docs.applivery.com/es/device-management/android/policies/lock-screen-keyguard/). ::: ### Cómo se combinan los dos ajustes

Quieres…

Credential Provider Policy Default

Credential Provider Policy (por app)

Bloquear todos los gestores de credenciales

DISALLOWED

No autorizar ninguna app (dejar en Unspecified)

Permitir solo los gestores que apruebes

DISALLOWED

Allowed en cada app aprobada

No restringir los gestores de credenciales

ALLOWED

No hace falta configurar ninguna app (las apps en Unspecified pueden actuar como gestor)

Valores del ajuste por defecto: - `DISALLOWED`: las apps cuyo _Credential Provider Policy_ no esté especificado **no pueden** actuar como gestor de credenciales. - `ALLOWED`: las apps cuyo _Credential Provider Policy_ no esté especificado **pueden** actuar como gestor de credenciales. Valores del ajuste por app: - `Unspecified`: la app se rige por el ajuste por defecto de la política. - `Allowed`: la app puede actuar como gestor de credenciales. :::warning El selector de **Credential Provider Policy Default** muestra también el valor **DISALLOWED EXCEPT SYSTEM**, pensado para bloquear todos los gestores salvo los preinstalados por el fabricante. Con este valor, la API de Android Management se comporta de forma incorrecta con las apps de sistema. Es una incidencia de Google, pendiente de corrección por su parte. Aunque siga apareciendo en la interfaz, evita usarlo hasta que se corrija. Para permitir solo los gestores que apruebes, usa **DISALLOWED** y autoriza cada app con **Allowed**. ::: ### Configurar el comportamiento por defecto **Abre la política** En el [**panel de Applivery**](https://dashboard.applivery.io/), ve a **Políticas** 1 y abre una política Android. En el menú lateral izquierdo, abre **Todas las propiedades** 2 y escribe `credential` en el buscador. **Elige el valor por defecto** En **Política de proveedores de credenciales por defecto** 3, selecciona `DISALLOWED` para bloquear todos los gestores o `ALLOWED` para no restringirlos. ![credentials](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/3709a198-6fb2-41f4-87b5-dd19f30fb423.png) :::info Junto a este ajuste aparece **Configuración de credenciales desactivada**, que controla si el usuario puede configurar credenciales de usuario en el dispositivo. Es un ajuste distinto y no afecta a qué gestores de contraseñas puede activar. ::: **Guarda y despliega** Haz clic en **Guardar cambios** en la tarjeta de la política. En el cuadro **Save policy**, revisa el número de dispositivos afectados y los cambios, y haz clic en **Guardar y desplegar**. Verás el aviso _Saved successfully!_. ### Permitir un gestor de credenciales desde las propiedades de la app Usa este procedimiento cuando el ajuste por defecto es `DISALLOWED` y quieres que los usuarios puedan usar uno o varios gestores concretos. El permiso se concede app por app, en el mismo panel donde se configuran las [propiedades gestionadas de las apps](https://docs.applivery.com/es/device-management/android/app-management/managed-apps-properties/). Antes, **Credential Provider Policy Default** debe estar en `DISALLOWED` y guardado, como en la sección anterior. **Abre las apps de la política** En el [**panel de Applivery**](https://dashboard.applivery.io/), ve a **Políticas**, abre la política Android a la que asignarás el gestor y entra en **Apps** en el menú lateral izquierdo. **Añade el gestor si no está en la lista** Si el gestor no aparece en la lista: 1. Haz clic en **\+ Añadir App**. Se abre el iframe de **Managed Google Play**. 2. Busca la app (si es pública) y apruébala. Si es una app privada, súbela como se explica en [Distribución de apps privadas con Managed Google Play](https://docs.applivery.com/es/device-management/android/app-management/private-app-managed-google-play/). 3. Define el **tipo de instalación**. Para un gestor corporativo, lo habitual es **Forzar instalación**: se instala sola y el usuario no puede eliminarla. Tienes todos los tipos en [Instalación forzosa de apps](https://docs.applivery.com/es/device-management/android/app-management/forced-install-apps/). **Autoriza la app** Haz clic en la app de la lista para abrir el **panel lateral** con sus propiedades configurables. Desplázate hasta el final y localiza **Política de proveedor de credenciales**, que aparece vacío (_Empty_) hasta que lo configures. Abre el desplegable y elige **Permitido** ("App is allowed to act as a credential provider"). La otra opción, **Sin especificar**, deja que la app se rija por el ajuste por defecto de la política. ![credential provider policy](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ffcdcebe-e6b9-4e61-b6f2-fb992e234e26.png) **Guarda y despliega** Cierra el panel lateral y haz clic en **Guardar cambios** en la tarjeta de la política. En el cuadro **Save policy**, revisa los dispositivos afectados y haz clic en **Guardar y desplegar**. Verás el aviso _Saved successfully!_. Repite **Autoriza la app** y **Guarda y despliega** para cada gestor que quieras autorizar. La lista de permitidos es el conjunto de apps con **Allowed** en la política. **Comprueba el resultado** En el dispositivo, abre **Ajustes → Contraseñas, claves de acceso y cuentas → Servicio preferido**. El gestor autorizado debe poder seleccionarse y el resto debe aparecer deshabilitado. :::info El campo **Credential Provider Policy** de la app solo tiene efecto si la app está incluida en la política y asignada al dispositivo. Si la app no está en la política, el usuario no puede usarla como gestor de credenciales cuando el ajuste por defecto es `DISALLOWED`. ::: ### Qué ve el usuario en el dispositivo El usuario gestiona su servicio en **Ajustes → Contraseñas, claves de acceso y cuentas → Servicio preferido**.

Configuración

Comportamiento en el dispositivo

DISALLOWED, ninguna app autorizada

Los servicios aparecen deshabilitados y no se pueden activar; el sistema indica que la opción está bloqueada por la política de trabajo.

DISALLOWED + una app con Allowed

Esa app se puede seleccionar como servicio preferido; el resto sigue deshabilitado. Al elegirla, Android pide confirmar el cambio de servicio.

ALLOWED

La política no bloquea los gestores: las apps sin especificar pueden actuar como gestor de credenciales.

:::info Los cambios pueden tardar unos instantes en llegar al dispositivo. Si no ves el efecto, comprueba que la política aparece como aplicada en la ficha del dispositivo y vuelve a abrir la pantalla de **Servicio preferido**. ::: ### Dispositivos con perfil de trabajo Esta política se puede usar en dispositivos totalmente gestionados, dedicados y con perfil de trabajo (tanto personales como corporativos). :::warning En dispositivos con **perfil de trabajo**, la política solo se aplica al **perfil de trabajo**. El espacio personal del usuario no se ve afectado y sus gestores de credenciales personales siguen funcionando con normalidad. ::: ### Resolución de problemas #### El dispositivo muestra "The policy is not supported by the version of Android Device Policy on this device" El aviso aparece en **Compliance checks** de la ficha del dispositivo, en el campo `credentialProviderPolicyDefault`. Comprueba que el dispositivo ejecuta Android 15 o superior y que Android Device Policy está actualizado. Si el aviso persiste, contacta con el soporte de Applivery indicando el modelo del dispositivo, la versión de Android y la versión de Android Device Policy. #### El usuario sigue pudiendo activar un gestor que debería estar bloqueado Revisa que la política con el ajuste está asignada a ese dispositivo y que has hecho clic en **Guardar y desplegar**. Comprueba también que el ajuste por defecto es `DISALLOWED` (y no `ALLOWED`) y que el gestor no tiene `Allowed` en las propiedades de la app. #### He autorizado un gestor con Allowed y el usuario no puede seleccionarlo Comprueba que la app está incluida en la política, que está instalada en el dispositivo, que has guardado y desplegado la política tras cambiar el campo **Credential Provider Policy** y que el dispositivo ejecuta Android 15 o superior. #### He seleccionado DISALLOWED EXCEPT SYSTEM y no puedo activar el gestor preinstalado El problema está en la API de Google con las apps de sistema y está pendiente de corrección por su parte. Usa `DISALLOWED` y autoriza el gestor que quieras con `Allowed` en las propiedades de la app. #### No encuentro el ajuste en la política Abre **Todas las propiedades** y busca `credential`. El ajuste por defecto está ahí; el ajuste por app está en el panel de propiedades de cada app dentro de **Apps**. --- ## Gestionar actualizaciones del OS Source: https://docs.applivery.com/es/device-management/android/policies/manage-os-updates/ Description: Gestiona las actualizaciones del OS Android con Applivery: automatiza despliegues, programa actualizaciones y configura periodos de congelación. TL;DR: Gestiona y automatiza las actualizaciones del OS Android en dispositivos gestionados con Applivery mediante políticas de actualización y periodos de congelación para mayor seguridad y estabilidad. Answers: ¿Cómo automatizar las actualizaciones del OS Android con Applivery? · ¿Cómo configurar políticas de actualización del sistema en Applivery? · ¿Qué son los periodos de congelación de Android y cómo usarlos? · ¿Cómo aplazar las actualizaciones del OS Android con Applivery? · ¿Cómo actualizar dispositivos en modo quiosco Android con Applivery? · ¿Cómo programar actualizaciones del OS Android con Applivery? · ¿Cómo gestionar las actualizaciones del OS Android en dispositivos corporativos? · ¿Cómo configurar una ventana de mantenimiento para actualizaciones Android? Key topics: Gestión de actualizaciones del OS Android, Políticas de actualización del sistema en Applivery, Configuración de periodos de congelación, Despliegue automatizado de actualizaciones, Seguridad del dispositivo, Android, Applivery, OTA (Over-the-Air) Mantener el sistema operativo (OS) de un dispositivo Android actualizado es una de las prácticas más importantes para garantizar su **seguridad y estabilidad**. Las actualizaciones del OS no solo incorporan nuevas funciones y mejoras de rendimiento, sino que también incluyen parches de seguridad críticos para proteger los dispositivos frente a vulnerabilidades emergentes y amenazas cibernéticas. Ignorar estas actualizaciones puede dejar los dispositivos expuestos a riesgos significativos, comprometiendo tanto los datos del usuario como la integridad del sistema. Para las empresas que gestionan una flota de dispositivos, ya sea en un entorno de quiosco, punto de venta o uso de los empleados, actualizar el OS manualmente es inviable. Este documento te guiará a través de los pasos necesarios para controlar y automatizar el despliegue de estas actualizaciones. Con Applivery, puedes garantizar que tus dispositivos siempre ejecuten las versiones de OS más recientes y seguras, manteniendo la continuidad del negocio y una protección sólida sin la carga de la gestión individual. ### Configurar una política de actualización del sistema Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a cualquiera de tus políticas 1. En el menú lateral izquierdo, dirígete a **Restricciones** 2, selecciona la sección **Sistema** y localiza la configuración de **Actualización del sistema** 3. ![system updates](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/4136e6ef-699b-490a-9986-b419bb7569c6.png) #### Tipos de actualización Esta es la configuración principal que define cómo se gestionan las actualizaciones del OS: - **UNSPECIFIED**: Sigue el comportamiento de actualización por defecto del dispositivo, que normalmente requiere que el usuario acepte e inicie la actualización manualmente. - **AUTOMATIC**: Las actualizaciones se instalan automáticamente en cuanto hay una nueva versión disponible. Esta opción es ideal para entornos que necesitan estar siempre al día con las últimas funciones y parches de seguridad. - **WINDOWED**: Las actualizaciones se instalan automáticamente dentro de una ventana de mantenimiento diaria que defines. Esta opción es muy recomendable para dispositivos en modo quiosco, ya que las actualizaciones se realizarán fuera del horario de trabajo. También permite que las apps de Play Store se actualicen dentro de esta misma ventana. Si una app está configurada con el modo de actualización **HIGH PRIORITY**, ignorará la ventana y se actualizará inmediatamente. - **POSTPONE**: Las actualizaciones se aplazan automáticamente hasta **30 días**. Esta política no afecta a las actualizaciones de seguridad críticas, que siempre se desplegarán de inmediato. #### Minutos de inicio y fin Estos ajustes solo se aplican si el **tipo de actualización** está configurado como **WINDOWED**. Permiten definir la ventana de mantenimiento diaria en minutos, contados desde medianoche. - **Minutos de inicio**: Define la hora de inicio de la ventana de mantenimiento (p. ej., 120 para las 2:00 AM). - **Minutos de fin**: Define la hora de fin de la ventana de mantenimiento (p. ej., 300 para las 5:00 AM). #### Periodos de congelación Los **periodos de congelación** son una función clave para los administradores que necesitan un control estricto sobre las actualizaciones del sistema operativo. Permiten aplazar las actualizaciones OTA (Over-the-Air) del OS Android durante un periodo recurrente cada año. Esto es muy útil para evitar que los dispositivos se actualicen durante momentos críticos del negocio, como temporadas de máxima actividad en ventas, grandes eventos o periodos de alta demanda operativa. Para añadirlos a la política, haz clic en **\+ Añadir elemento** para expandir todos los campos de configuración. ##### ¿Cómo funciona? - **Definición del periodo**: Puedes definir una fecha de inicio y una fecha de fin para el periodo de congelación. - **Comportamiento**: Cuando un dispositivo está dentro de un periodo de congelación, todas las actualizaciones del sistema (incluidos los parches de seguridad) quedan bloqueadas y no se instalan. El dispositivo volverá a su política de actualización normal una vez que termine el periodo de congelación. - **Configuración**: Para configurarlo, debes especificar el día y mes de inicio y fin y, opcionalmente, el año. Un periodo de congelación debe durar un mínimo de **60 días**. Dentro de la sección **Periodos de congelación**, cada periodo que añadas tiene dos subsecciones principales: **Fecha de inicio** y **Fecha de fin**. Cada una contiene los siguientes campos de configuración: - **Día**: Introduce un número del 1 al 31 que represente el día del mes en que comienza o termina el periodo de congelación. - **Mes**: Introduce un número del 1 al 12 que represente el mes en que comienza o termina el periodo de congelación. - **Año**: Introduce un número del 1 al 9999 que represente el año. Si dejas el campo **Año** en blanco (o lo pones a 0), el periodo de congelación se considerará **recurrente anualmente**. Esto significa que las fechas que definas (día y mes) se aplicarán cada año, aplazando automáticamente las actualizaciones del OS durante ese mismo periodo. Esta es la forma más habitual de usar los periodos de congelación para eventos recurrentes, como la temporada navideña o las vacaciones de verano. ##### Ejemplo práctico Si un comercio se prepara para la campaña navideña y no quiere que las actualizaciones del OS interrumpan el funcionamiento de sus dispositivos de punto de venta, puede establecer un periodo de congelación del 1 de noviembre al 31 de diciembre. Durante este tiempo, ningún dispositivo se actualizará automáticamente. Usar **periodos de congelación** te garantiza que tus dispositivos mantendrán una versión estable del OS durante los momentos más críticos, asegurando la continuidad del negocio sin interrupciones inesperadas. Gestionar las actualizaciones del sistema operativo es un componente crítico de la administración de dispositivos Android, ya que afecta directamente a la **seguridad**, **estabilidad** y **rendimiento** de toda la flota. Applivery proporciona las herramientas necesarias para convertir un proceso complejo y potencialmente arriesgado en un flujo de trabajo controlado y automatizado. Al configurar los modos de actualización (**AUTOMATIC**, **WINDOWED**, **POSTPONE**) y usar los **periodos de congelación**, los administradores pueden diseñar una estrategia que se adapte perfectamente a las necesidades operativas de su organización. Este enfoque proactivo no solo protege los dispositivos frente a vulnerabilidades, sino que también minimiza las interrupciones inesperadas, garantizando unas operaciones fluidas incluso durante los periodos más críticos. En resumen, una gestión estratégica de las actualizaciones del OS es clave para mantener un ecosistema Android robusto y fiable a largo plazo. --- ## Políticas de contraseña Source: https://docs.applivery.com/es/device-management/android/policies/password-policy/ Description: Configura las políticas de contraseña de Android en Applivery — aplica contraseñas robustas, establece reglas de caducidad y protege los dispositivos gestionados. TL;DR: Configura políticas de contraseña robustas en Android con Applivery para mejorar la seguridad del dispositivo, aplicar el cumplimiento y proteger los datos de la organización. Answers: ¿Cómo aplicar políticas de contraseña robustas en dispositivos Android? · ¿Cómo configurar los requisitos de complejidad de contraseña en Applivery? · ¿Cuáles son las buenas prácticas de seguridad de contraseñas en Android con MDM? · ¿Cómo establecer el tiempo de caducidad de contraseña en dispositivos Android con Applivery? · ¿Cómo evitar la reutilización de contraseñas en dispositivos Android? · ¿Cómo gestionar remotamente las políticas de contraseña de Android con Applivery? · ¿Qué ocurre después de demasiados intentos de contraseña fallidos en Android? · ¿Cómo afecta la Calidad de contraseña a los requisitos de contraseña en Applivery? Key topics: Configuración de políticas de contraseña de Android, Gestión de dispositivos con Applivery, Buenas prácticas de seguridad en dispositivos móviles, Ajustes de complejidad y caducidad de contraseñas, Android, Applivery, MDM, PIN, Password Quality, Password Scope Al gestionar dispositivos Android con Applivery, uno de los aspectos más importantes es garantizar que están protegidos con una contraseña robusta. No se trata solo de establecer cualquier código de acceso, sino de aplicar reglas mínimas que garanticen un nivel de seguridad adecuado en todos los dispositivos. Con Applivery, puedes configurar estos requisitos de forma remota fácilmente, asegurándote de que todos los dispositivos cumplen las políticas de seguridad de tu organización sin complicaciones. ### Configura las políticas de contraseña de Android para una mayor seguridad **Navegar a Políticas** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), navega a **Políticas** 1. **Seleccionar la política de Android** Selecciona la política de Android donde quieres aplicar la seguridad de contraseña. **Acceder a los ajustes de Seguridad** En el menú lateral izquierdo, selecciona **Seguridad**. **Añadir política de contraseña** Haz clic en el botón **\+ Añadir política de contraseña** 2. Aparecerá un modal pidiéndote que elijas el tipo de requisito de contraseña: **Complejidad de contraseña** o **Calidad de contraseña**. ![añadir política de contraseña](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/9c1a18d3-1180-4b6c-817f-fbbd182506c9.png) La API de Android tiene dos conceptos para las políticas de contraseña: - **Complejidad de contraseña** — El nuevo enfoque simplificado introducido en Android 12. - **Calidad de contraseña** — El enfoque heredado, que permite una configuración más detallada. Para la compatibilidad con versiones anteriores, cuando se envía una configuración de Complejidad a la API de Android Management (AMAPI), también se requiere enviar la configuración de Calidad heredada equivalente junto a ella. Son dos formas de expresar el mismo requisito, pero la API necesita ambas. ![fortaleza de contraseña](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/70e57d8e-2875-4748-b19b-7e05fdf8c9e5.png) :::info Si no se define ninguna política de calidad heredada para el mismo ámbito, se generará automáticamente un equivalente heredado compatible. Esto garantiza la compatibilidad con versiones anteriores de Android. ::: #### Complejidad de contraseña Disponible en Android 12 y versiones superiores, con tres niveles predefinidos: - **Baja**: Se permite un patrón o PIN con secuencias repetidas (4444) u ordenadas (1234, 4321, 2468). - **Media**: PIN sin secuencias repetidas ni ordenadas; contraseña alfabética o alfanumérica con una longitud mínima de 4 caracteres. - **Alta**: PIN sin secuencias repetidas ni ordenadas y al menos 8 caracteres, o contraseña alfabética/alfanumérica con al menos 6 caracteres. #### Calidad de contraseña El enfoque heredado, que proporciona un control más granular sobre los requisitos de contraseña: - **Sin especificar**: No se aplican requisitos de contraseña. - **Biométrico débil**: Requiere un método de reconocimiento biométrico de baja seguridad. - **Algo**: Se requiere una contraseña, pero sin restricciones sobre lo que debe contener. - **Numérica**: La contraseña debe contener caracteres numéricos. - **Numérica compleja**: Solo caracteres numéricos, sin secuencias repetidas (4444) ni ordenadas (1234, 4321, 2468). - **Alfabética**: La contraseña debe contener caracteres alfabéticos o símbolos. - **Alfanumérica**: La contraseña debe contener tanto caracteres numéricos como alfabéticos. - **Compleja**: La contraseña debe cumplir los requisitos mínimos definidos en los campos siguientes. Cuando se selecciona **Compleja**, se aplican los siguientes campos adicionales: - **Longitud mínima de contraseña**: Establece el número mínimo de caracteres requeridos. - **Mínimo de letras en la contraseña**: Número mínimo de caracteres de letra requeridos. - **Mínimo de minúsculas en la contraseña**: Número mínimo de letras minúsculas requeridas. - **Mínimo de caracteres no letra en la contraseña**: Número mínimo de caracteres que no sean letras (números o símbolos). - **Mínimo de caracteres numéricos en la contraseña**: Número mínimo de dígitos numéricos requeridos. - **Mínimo de símbolos en la contraseña**: Número mínimo de símbolos requeridos (p. ej., @, #, %). - **Mínimo de mayúsculas en la contraseña**: Número mínimo de letras mayúsculas requeridas. #### Ajustes comunes Los siguientes ajustes se aplican independientemente del tipo de política elegido: - **Ámbito de contraseña**: Determina a qué parte del dispositivo se aplica la política — el Perfil de trabajo, todo el dispositivo, o ambos. - **Requerir desbloqueo con contraseña**: Especifica el tiempo transcurrido tras desbloquear el dispositivo con un método seguro (p. ej., PIN o patrón) antes de que el usuario deba volver a usar ese método en lugar de la biometría. - **Ajustes de bloqueo unificado**: Controla si los mismos ajustes de bloqueo se aplican tanto al dispositivo como al Perfil de trabajo. Si se requieren contraseñas separadas y el usuario no ha configurado una, el dispositivo se marcará como no conforme. - **Máximo de contraseñas fallidas para borrar**: Especifica cuántos intentos de contraseña incorrectos están permitidos antes de que el dispositivo se borre completamente. Un valor de 0 significa que no hay límite. - **Tiempo de caducidad de contraseña**: Define cuánto tiempo puede usarse una contraseña antes de que el usuario deba cambiarla. **Introduce este valor en segundos**, no en días: por ejemplo, `31536000` para 365 días, o `7776000` para 90 días. Cumplido el plazo, el dispositivo pide al usuario una contraseña nueva antes de desbloquearse. - **Longitud del historial de contraseñas**: Indica cuántas contraseñas anteriores se recuerdan para evitar su reutilización. Configurar correctamente las políticas de contraseña en dispositivos Android a través de Applivery es una forma sencilla y eficaz de reforzar la seguridad. Ajustando estos valores, garantizas que todos los dispositivos cumplan los estándares de seguridad mínimos de tu organización, reduces los riesgos potenciales y mantienes un control centralizado. ### Soporte para dispositivos AOSP Las políticas de contraseña funcionan igual en AOSP — mismos campos, mismos pasos de configuración. Las únicas diferencias que merece la pena mencionar: - El **ámbito de contraseña** es siempre `DISPOSITIVO` en AOSP. No hay separación de Perfil de trabajo, por lo que la política siempre se aplica a toda la pantalla de bloqueo del dispositivo. - Los **ajustes de bloqueo unificado** no se aplican — solo hay una pantalla de bloqueo. --- ## Mensajes de soporte Source: https://docs.applivery.com/es/device-management/android/policies/personalized-support-messages/ Description: Crea mensajes de soporte personalizados para funciones bloqueadas en Android con Applivery para mejorar la experiencia y mantener la seguridad. TL;DR: Configura mensajes personalizados para funciones bloqueadas en Android con Applivery para mejorar la experiencia y guiar a los usuarios sobre las restricciones. Answers: ¿Cómo crear mensajes personalizados para funciones bloqueadas en Android? · ¿Cuáles son los beneficios de los mensajes de soporte personalizados en Android? · ¿Cómo configurar mensajes en la pantalla de bloqueo en dispositivos Android? · ¿Cómo ayuda Applivery con la gestión de dispositivos Android? · ¿Cómo mejorar la experiencia de usuario con restricciones de dispositivos? · ¿Qué tipos de mensajes de soporte ofrece Applivery? · ¿Cómo reducir las incidencias de soporte con mensajes personalizados? · ¿Cómo proporcionar orientación clara sobre las restricciones de Android? Key topics: Restricciones de dispositivos Android, Mensajes de soporte personalizados, Configuración de Applivery, Mejora de la experiencia de usuario, Gestión de dispositivos móviles, Android, Applivery, Device Owner Lock Screen Info, Long Support Message, Short Support Message En entornos corporativos donde los dispositivos Android se gestionan de forma centralizada, aplicar restricciones es una práctica habitual para reforzar la seguridad y garantizar el cumplimiento de las políticas de la empresa. Sin embargo, cuando los usuarios intentan acceder a una función bloqueada sin entender el motivo, la experiencia puede resultar confusa o frustrante. Los mensajes claros y personalizados ayudan a orientar al usuario en tiempo real, mejorando la comunicación sin comprometer los controles de seguridad establecidos por la organización. ### Tipos de mensajes de soporte Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a cualquiera de tus políticas. En el menú lateral izquierdo, localiza la **Pantalla de bloqueo**, donde encontrarás las opciones para configurar los diferentes tipos de mensajes asociados a las funciones bloqueadas. ![lock screen](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/f2b5a1d0-d664-4eb1-8f4d-f301365cdbdb.png) Las opciones disponibles son: - **Información del propietario en la pantalla de bloqueo**: Permite mostrar información personalizada directamente en la pantalla de bloqueo. Es útil para mostrar instrucciones, identificación de la empresa o datos de contacto en caso de pérdida o necesidades de soporte mientras el dispositivo está bloqueado. - **Mensaje de soporte largo**: Un mensaje extendido para los casos en que el sistema operativo permite descripciones más largas. Es ideal para explicaciones detalladas o guías de soporte, como instrucciones para resolver bloqueos o pasos a seguir cuando una pantalla de configuración está restringida por política. Este mensaje puede incluir información contextual o instrucciones paso a paso (p. ej., "Si no puedes continuar, contacta con el soporte técnico de Applivery…"). ![long message](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/611deaee-12da-4bf2-8331-283de56697b0.png) - **Mensaje de soporte corto**: Un mensaje breve que se muestra cuando solo se puede mostrar texto limitado en la pantalla de bloqueo. Se usa habitualmente para instrucciones rápidas o datos de contacto esenciales cuando el dispositivo solo admite información mínima (p. ej., "Dispositivo propiedad de Applivery. Contacto: support@applivery.com"). ![short message](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/94b93498-c8b0-4cec-90cb-a89d4a5d7ec7.png) Gestionar mensajes personalizados para las funciones restringidas no solo mejora la experiencia de usuario, sino que también refuerza la comunicación interna y el soporte. Ofrecer explicaciones claras —ya sean breves o detalladas— ayuda a los usuarios a entender las restricciones aplicadas, reduce la incertidumbre y proporciona orientación directa sobre qué hacer a continuación. Esta comunicación proactiva reduce las incidencias, acelera la resolución del soporte y refuerza la confianza en la estrategia de gestión de dispositivos. :::tip Los mensajes de soporte personalizados son clave para una experiencia de usuario positiva en la gestión de restricciones de dispositivos Android. ::: Gracias a las herramientas de Applivery, es posible transformar un momento potencialmente frustrante en una oportunidad para informar, guiar y apoyar al usuario, manteniendo al mismo tiempo el máximo nivel de seguridad y cumplimiento en los dispositivos Android gestionados. ### Compatibilidad con dispositivos AOSP Todos los tipos de mensaje funcionan igual en AOSP: misma configuración, mismo comportamiento. Como el Applivery DPC se ejecuta como Device Owner en todo el dispositivo, los mensajes se muestran a nivel de dispositivo, sin contexto de perfil de trabajo. --- ## Evitar la transferencia de datos Source: https://docs.applivery.com/es/device-management/android/policies/prevent-data-transfer/ Description: Evita la transferencia de datos entre perfiles de trabajo y personales en Android con las restricciones de perfiles cruzados de Applivery MDM. TL;DR: Evita fugas de datos entre perfiles de trabajo y personales en Android configurando restricciones de perfiles cruzados en Applivery. Answers: ¿Cómo evitar copiar y pegar entre perfiles de trabajo y personales en Android? · ¿Cómo bloquear el intercambio de datos entre perfiles en Android? · ¿Cómo ocultar los contactos de trabajo en el perfil personal en Android? · ¿Qué son las políticas de perfiles cruzados en Android? · ¿Cómo proteger los datos corporativos en dispositivos Android? · ¿Cómo configurar las restricciones de perfiles cruzados en Applivery? · ¿Cómo implementar la prevención de pérdida de datos en Android? Key topics: Seguridad Android, Restricciones de perfiles cruzados, Prevención de pérdida de datos, Configuración de Applivery, Android, Applivery, COPE, BYOD :::warning Las restricciones de perfiles cruzados requieren un perfil de trabajo (inscripción COPE o BYOD) y **no están disponibles en dispositivos AOSP**. En AOSP, el Applivery DPC se ejecuta como Device Owner en todo el dispositivo: no hay perfil personal del que separar los datos. ::: Proteger la privacidad de los datos corporativos es esencial para garantizar la seguridad e integridad de tu organización. Con la adopción de los métodos de inscripción COPE (Corporate-Owned, Personally Enabled) y BYOD (Bring Your Own Device), las empresas y sus empleados ganan flexibilidad, pero también se enfrentan a nuevos retos de seguridad. Para reducir el riesgo, es importante establecer un límite claro entre los perfiles personal y de trabajo en los dispositivos Android. Con Applivery, puedes evitar que se transfiera información entre perfiles, incluyendo la desactivación de funciones del sistema como _Copiar y pegar_ entre los entornos de trabajo y personal. ### Cómo configurar las restricciones de perfiles cruzados **Ir a Políticas** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a **Políticas** 1. **Seleccionar la política Android** Selecciona la política Android donde quieres aplicar la restricción. A continuación, dirígete a la sección **Cumplimiento** 2 en el menú lateral izquierdo. **Configurar las políticas de perfiles cruzados** Localiza los ajustes de **Políticas de perfiles cruzados** 3. Allí encontrarás las siguientes opciones: - **Copiar y pegar entre perfiles**: Selecciona **Copiar de trabajo a personal no permitido** para bloquear las acciones de copiar y pegar entre los perfiles de trabajo y personal. - **Intercambio de datos entre perfiles**: Selecciona **Intercambio de datos de trabajo a personal no permitido** para impedir que los datos se compartan entre apps de distintos perfiles. - **Mostrar contactos de trabajo en el perfil personal**: Desactiva esta opción si quieres ocultar los contactos de trabajo de la lista de contactos del perfil personal. ![cross profile polices](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/521a02bb-4511-42b4-9672-47c783915079.png) Aplicar estas políticas ayudará a garantizar que los datos corporativos permanezcan en el entorno gestionado, reforzando la separación entre el uso profesional y personal en los dispositivos Android. --- ## Espacios privados en COPE Source: https://docs.applivery.com/es/device-management/android/policies/private-space/ Description: Gestiona el espacio privado en dispositivos Android COPE con Applivery — controla el acceso, equilibra la seguridad y protege la privacidad del usuario. TL;DR: Applivery permite a las organizaciones gestionar el espacio privado de Android 15 en dispositivos COPE, controlando el acceso para equilibrar la seguridad y la privacidad del usuario mediante políticas configurables. Answers: ¿Qué es el espacio privado de Android 15? · ¿Cómo gestiona Applivery el espacio privado? · ¿Puedo bloquear el espacio privado en dispositivos COPE con Applivery? · ¿Cuáles son las implicaciones de seguridad del espacio privado? · ¿Cómo configuro las políticas de espacio privado en Applivery? · ¿Qué ocurre cuando se prohíbe el espacio privado? · ¿En qué se diferencia el espacio privado del perfil de trabajo? Key topics: Espacio privado de Android 15, Gestión con Applivery, Políticas de dispositivos COPE, Seguridad móvil, Privacidad del usuario, Android 15, Espacio privado, Applivery, COPE El [**espacio privado**](https://source.android.com/docs/security/features/private-space) es una nueva función de Android 15+ que permite a los usuarios configurar un área segura y oculta dentro de su perfil personal — una auténtica "caja fuerte secreta" para apps y datos sensibles. ### Qué hace único al espacio privado - **Instalación privada**: Los usuarios pueden instalar apps confidenciales y datos en un entorno completamente aislado, invisible desde el perfil principal cuando está bloqueado. - **Modo invisible**: Las apps y notificaciones del espacio privado no aparecen en el selector de aplicaciones, las apps recientes ni la configuración del sistema hasta que se desbloquea. - **Seguridad adicional**: El espacio privado puede usar su propia autenticación (como PIN o biometría), separada del bloqueo principal del dispositivo, para una mayor protección. ### En qué se diferencia del perfil de trabajo y personal - El **perfil de trabajo** (gestionado por Applivery) mantiene separadas las apps y datos de trabajo; las organizaciones controlan, protegen y supervisan este espacio. - El **perfil personal** es el área predeterminada para las apps y datos personales, con supervisión opcional de la empresa en configuraciones COPE. - El **espacio privado** no es un perfil de trabajo ni personal — es un espacio seguro creado por el usuario dentro del perfil personal. Una vez configurado, Applivery y los administradores de TI no pueden ver su interior, pero pueden permitir o bloquear la creación del espacio privado en los dispositivos corporativos. ### Por qué Applivery permite gestionarlo Aunque Applivery no puede acceder al contenido del espacio privado, permite a las organizaciones decidir si permitir su uso en dispositivos COPE. Esto capacita a las empresas para: - **Garantizar la auditabilidad**: Bloquear el espacio privado si se requiere visibilidad o auditabilidad completa. - **Conceder flexibilidad**: Permitir el espacio privado para los usuarios que necesitan privacidad y libertad adicionales en el uso personal de su dispositivo. ### Configurar el espacio privado Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a cualquiera de tus políticas 1. En el menú lateral izquierdo, dirígete a **Cumplimiento**, localiza la opción **Políticas de uso personal** y configura el ajuste **Política de espacio privado** 2. ![política de espacio privado](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/726ba04a-748d-4a05-9dba-648ce45e705b.png) **Permitir el espacio privado** **Permitido**: Elige esta opción si quieres que los usuarios puedan configurar y usar el espacio privado en los dispositivos corporativos. **Prohibir el espacio privado** **No permitido**: Elige esta opción para evitar que los usuarios creen o accedan al espacio privado. Esto oculta la función, y los espacios privados existentes se eliminarán. :::warning Asegúrate de que esta política esté asignada a todos los dispositivos relevantes (especialmente los dispositivos **COPE**). ::: Una vez que los dispositivos se sincronicen con Applivery (esto puede tardar unos minutos): - Si el espacio privado está **desactivado**, los usuarios no verán la opción en Configuración y cualquier espacio existente se eliminará automáticamente. - Si el espacio privado está **activado**, los usuarios pueden acceder a él y configurarlo desde las opciones de su perfil personal. Gestionar los dispositivos móviles con Applivery significa que puedes controlar con precisión cómo se usan los dispositivos Android corporativos — equilibrando la seguridad de la organización y la privacidad del usuario. El espacio privado de Android 15 es un ejemplo de innovación móvil flexible. Al aplicar estas políticas, tu empresa garantiza que los dispositivos COPE (Corporate-Owned, Personally Enabled) cumplan los requisitos de seguridad mientras se respeta la privacidad del empleado — un enfoque inteligente para un lugar de trabajo productivo y seguro. ### Soporte para dispositivos AOSP El espacio privado también es configurable en dispositivos AOSP con Android 15+. Aunque AOSP no tiene perfil de trabajo, el espacio privado reside en el perfil de usuario principal — y el Applivery DPC, ejecutándose como propietario del dispositivo, puede controlar si los usuarios pueden crear uno. La configuración es la misma: Permitido o No permitido, mismos pasos. --- ## Restringir la inscripción a un dominio corporativo Source: https://docs.applivery.com/es/device-management/android/policies/restrict-enrollment-to-corporate-domain/ Description: Obliga a que los dispositivos Android solo se aprovisionen con las Cuentas de Google administradas de tu empresa usando workAccountSetupConfig — restringe el acceso a tu dominio corporativo o a una cuenta concreta. TL;DR: Si Applivery está vinculado como managed Google domain, usa el campo de política workAccountSetupConfig con authenticationType en GOOGLE_AUTHENTICATED para obligar a iniciar sesión con una Cuenta de Google administrada corporativa. Añade requiredAccountEmail para fijar una cuenta concreta. Key topics: Modelos de identidad de Android Enterprise, Managed Google domain, workAccountSetupConfig, Restricciones por dominio y por cuenta, Android Enterprise, Google Workspace, Cuentas de Google administradas, Applivery, Android Management API Restringir el aprovisionamiento de dispositivos a un dominio corporativo depende directamente del modelo de identidad configurado en tu Android Enterprise. Antes de poder limitar la inscripción a las cuentas de tu empresa, conviene entender los dos modelos disponibles y qué te permite hacer cada uno. ### Los dos modelos de identidad de Android Enterprise Android Enterprise admite dos modelos de identidad para el aprovisionamiento de dispositivos: - **Managed Google Play Accounts enterprise** — los usuarios se registran mediante _Managed Google Play Accounts_, cuentas aprovisionadas directamente por el proveedor EMM y no vinculadas a un dominio corporativo existente. Las _managed Google accounts_ no están soportadas en este modelo, ya que estructuralmente no forman parte de él. - **Managed Google domain** — la organización opera sobre un dominio de Google gestionado (por ejemplo, Google Workspace o Cloud Identity). Los usuarios se autentican con sus _managed Google accounts_ corporativas y esa identidad se asocia directamente a los dispositivos Android gestionados. En la práctica, esto determina el nivel de control de identidad disponible. Si necesitas restringir el aprovisionamiento a identidades corporativas de un dominio específico, el modelo adecuado es el managed Google domain. Bajo un managed Google Play Accounts enterprise, el control de identidad queda limitado al esquema de Managed Google Play Accounts, sin posibilidad de aplicar restricciones a nivel de dominio. Por eso, cuando necesites restringir el alta de cuentas en el dispositivo únicamente a las que pertenecen a tu dominio corporativo, Applivery debe haberse vinculado como **managed Google domain**. Con eso en marcha, si un usuario inicia sesión con una cuenta de Google en su dispositivo gestionado, el sistema le obliga a que esa cuenta pertenezca a los dominios de la empresa — y si no es así, no le deja iniciar sesión. Y si, además, quieres **obligar** al usuario a iniciar sesión y evitar que pueda saltarse ese paso, lo controlas a través del campo de política `workAccountSetupConfig`, que forma parte de la Android Management API de Google. :::info Esta configuración exige un dominio de Google Workspace **verificado** y las Cuentas de Google administradas de tus usuarios ya deben existir en la Google Admin Console antes de aplicar la política. No las crea por sí sola: solo controla qué cuenta se acepta durante la configuración. ::: ### Requisitos previos - Un dominio gestionado de Google Workspace, verificado en la Google Admin Console y enlazado con Applivery. - Cuentas de Google administradas ya creadas para los usuarios que van a inscribir dispositivos. - Un Enterprise de Android vinculado a Applivery mediante Google Workspace (una cuenta gestionada bajo tu dominio corporativo). Consulta [Primeros pasos con Android](https://docs.applivery.com/es/device-management/android/get-started/#google-workspace-dominio-gestionado) si todavía usas una cuenta de Google Play administrada no gestionada. ### Configurar la restricción por dominio Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a cualquiera de tus **Políticas** 1. En el menú lateral izquierdo, dirígete a **Conformidad** y localiza el ajuste **Configuración de la cuenta de trabajo** 2. También puedes abrir la sección **Todas las propiedades** y buscarlo directamente. ![work account setup config](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/49b7e28f-fde8-4553-a47b-538cc7b944cf.png) Dentro de la configuración de la política Android, el bloque `workAccountSetupConfig` acepta dos parámetros relevantes para este caso de uso:

Campo

Tipo

Descripción

Tipo de autenticación

enum

Establece GOOGLE_AUTHENTICATED para exigir una cuenta de Google administrada durante la configuración del dispositivo.

Correo electrónico requerido de la cuenta

string (opcional)

La dirección de correo exacta que el usuario debe usar. Si se omite, se acepta cualquier cuenta de Google administrada que pertenezca a tu enterprise — es decir, cualquier cuenta del dominio.

#### Solo restringir al dominio (cualquier cuenta de la empresa) Si no necesitas fijar una cuenta concreta, basta con activar la autenticación de Google sin **Correo electrónico requerido de la cuenta**. El dispositivo acepta cualquier cuenta de Google administrada que pertenezca a tu enterprise. Si el usuario intenta acceder con una cuenta ajena al dominio, Android Device Policy la rechaza automáticamente — y no puede saltarse este paso, así que queda obligado a iniciar sesión con una cuenta de la empresa. #### Restringir a una cuenta específica Añade el **Correo electrónico requerido de la cuenta** cuando quieras decidir de antemano qué usuario debe usar ese dispositivo — por ejemplo, en inscripciones dirigidas a una persona concreta. ![requireda ccount email](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/070e94d8-9f58-448e-ba63-a1a327e6f234.png) :::warning Si defines el **Correo electrónico requerido de la cuenta** con una dirección que **no** pertenece a tu dominio empresarial por error, el dispositivo quedará permanentemente no conforme y el usuario verá un mensaje de error hasta que un administrador corrija la política. ::: ### Qué experimenta el usuario El comportamiento exacto depende de si el dispositivo ya tiene una cuenta configurada y de si se especifica **Tipo de autenticación**: - **Sin cuenta previa + con** **Correo electrónico requerido de la cuenta**: se solicita al usuario iniciar sesión con esa cuenta exacta. - **Sin cuenta previa + sin** **Correo electrónico requerido de la cuenta**: se solicita cualquier Cuenta de Google administrada válida del dominio. - **La cuenta requerida ya está en el dispositivo**: la actualización ocurre en segundo plano, sin pedir al usuario que inicie sesión de nuevo. - **El usuario introduce una cuenta distinta a la requerida**: ve un error directamente en la pantalla de acceso de Google y debe volver a intentarlo con la cuenta correcta. - **El usuario introduce una cuenta fuera del dominio empresarial (sin** **Correo electrónico requerido de la cuenta)**: la cuenta se retira automáticamente del dispositivo y se le pide volver a iniciar sesión con una cuenta válida. ### Resolución de problemas

Situación

Causa probable

Motivo de incumplimiento reportado

El usuario ve "La política del trabajo requiere la cuenta laboral especificada" o similar

Intentó acceder con una cuenta distinta a Correo electrónico requerido de la cuenta

(bloqueado en el acceso, no llega a reportarse como no conformidad)

El dispositivo queda permanentemente no conforme y muestra "Comunícate con el administrador de TI" o similar

Correo electrónico requerido de la cuenta apunta a una cuenta que no pertenece a tu enterprise

REQUIRED_ACCOUNT_NOT_IN_ENTERPRISE

Se retira la cuenta del dispositivo automáticamente

El usuario inició sesión con una cuenta fuera del dominio y no había Correo electrónico requerido de la cuenta fijado

NEW_ACCOUNT_NOT_IN_ENTERPRISE

Si combinas esta configuración con [reglas de cumplimiento](https://docs.applivery.com/es/device-management/android/policies/enforcement-rules/) (bloqueo o borrado tras N días de incumplimiento), el dispositivo mostrará avisos progresivos antes de aplicar la acción de mitigación configurada. :::info Google no publica una versión mínima de Android específica para la **Configuración de la cuenta de trabajo** o `GOOGLE_AUTHENTICATED`; el requisito base es que el dispositivo sea compatible con Android Enterprise, disponible desde Android 5.0 o superior. ::: Con la **Configuración de la cuenta de trabajo**, vinculas el aprovisionamiento de Android Enterprise a tu dominio corporativo — obligando a que los dispositivos solo se configuren con Cuentas de Google administradas de la empresa y, si lo necesitas, con una cuenta concreta mediante Correo electrónico requerido de la cuenta. Aplicada sobre un entorno con Google Workspace verificado y cuentas gestionadas correctamente aprovisionadas, esta configuración refuerza la seguridad de identidad, reduce errores de inscripción y te da control granular sobre qué usuario puede iniciar sesión en cada dispositivo, manteniendo la experiencia de usuario alineada con las políticas de cumplimiento definidas en Applivery. --- ## Restringir acceso Wi-Fi Source: https://docs.applivery.com/es/device-management/android/policies/restrict-wifi-access/ Description: Restringe el acceso Wi-Fi en dispositivos Android con políticas de Applivery: permite o bloquea redes específicas para controlar la conectividad. TL;DR: Aprende a restringir o permitir el acceso a redes Wi-Fi en dispositivos Android con la función de política Wi-Fi de Applivery. Answers: ¿Cómo bloquear Wi-Fi en dispositivos Android? · ¿Cómo permitir redes Wi-Fi específicas en Android? · ¿Cómo configurar una política Wi-Fi en Applivery? · ¿Qué es la lista de SSID permitidos? · ¿Qué es la lista de SSID bloqueados? · ¿Cómo proteger dispositivos Android con políticas Wi-Fi? · ¿Cómo gestionar el acceso Wi-Fi en dispositivos Android? · ¿Cómo añadir un SSID Wi-Fi en Applivery? Key topics: Configuración de política Wi-Fi, Gestión de dispositivos Android, Seguridad de red, Panel de Applivery, Android, Applivery, Wi-Fi, SSID En ciertos entornos corporativos puede ser necesario restringir el acceso a redes Wi-Fi específicas, ya sea para mejorar la seguridad, evitar interferencias de redes no autorizadas o garantizar que los dispositivos se conecten a la correcta. A continuación encontrarás una guía paso a paso para permitir o bloquear el acceso a una red Wi-Fi concreta desde los dispositivos gestionados. #### Configurar una política Wi-Fi **Ir a Políticas** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a **Políticas** 1. **Seleccionar la política Android** Elige la política Android específica que quieres modificar. **Acceder a los ajustes de red** En el menú lateral izquierdo, haz clic en la sección **Red**. **Elegir el tipo de política Wi-Fi SSID** En los ajustes de **Gestión de conectividad del dispositivo**, selecciona **Allowlist** o **Denylist** en **Tipo de política Wi-Fi SSID** 2, dentro de la sección **Política Wi-Fi SSID**. - **Allowlist**: Solo se permitirán las redes Wi-Fi especificadas. - **Denylist**: Las redes Wi-Fi especificadas quedarán bloqueadas. ![Wi-Fi ssid policy](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/3e6288bf-4a4b-46d9-b010-f49a677be182.png) **Añadir SSID Wi-Fi** Para especificar la red Wi-Fi que quieres permitir o bloquear, haz clic en **\+ Añadir elemento** en la configuración de **SSID Wi-Fi** 3. Aparecerá un formulario donde podrás introducir el SSID de la red concreta. Puedes añadir tantos SSID como necesites. Cuando termines, guarda los cambios haciendo clic en **Guardar cambios** en la vista de la política. ![Wi-Fi ssid](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/7c71f42f-0503-4d61-9224-fa207e0e87db.png) Restringir el acceso a redes Wi-Fi específicas es una forma sencilla y eficaz de controlar la conectividad de los dispositivos en tu organización. Aplicar estas reglas ayuda a mantener un entorno de red más seguro, estable y alineado con tus políticas. :::tip Revisa y actualiza tus políticas Wi-Fi con regularidad para asegurarte de que siguen siendo eficaces y están alineadas con las necesidades de seguridad de tu organización. ::: ### Compatibilidad con dispositivos AOSP La política Wi-Fi SSID funciona igual en AOSP: mismas opciones, mismos pasos. El Applivery DPC aplica las restricciones a nivel de dispositivo a través de las API nativas de Android `DevicePolicyManager`, por lo que no se requieren servicios de Google. --- ## Configuración de políticas comunes Source: https://docs.applivery.com/es/device-management/android/policies/sample-policies/ Description: Configuraciones de políticas comunes para la gestión de dispositivos Android, incluyendo modo quiosco, apps web, fuentes desconocidas y ajustes de red. TL;DR: Guía con ejemplos de configuraciones JSON para políticas Android comunes: modo quiosco y ajustes de red. Answers: ¿Qué es el launcher personalizado del modo quiosco de Android? · ¿Qué es el modo quiosco de app única de Android? · ¿Cuál es el propósito de Network Escape Hatch? · ¿Cómo configuro el modo quiosco de web app? · ¿Cómo permito a los usuarios instalar apps de fuentes desconocidas? · ¿Cuál es la diferencia entre 'Permitir instalación desde fuentes desconocidas' y 'Permitir instalar apps desconocidas'? · ¿Cómo configuro los ajustes de Wi-Fi de forma remota en dispositivos Android? · ¿Cuáles son los campos obligatorios para la configuración de Wi-Fi usando Open Network Configuration? Key topics: Configuración del modo quiosco, Políticas de instalación de aplicaciones, Configuración de red, Gestión de dispositivos Android, Configuración de políticas, Android, Google Chrome, Applivery, JSON, Google Play Store Como ya sabes, las posibilidades de configuración de las políticas de gestión de dispositivos Android son ilimitadas. A continuación, encontrarás un repositorio con las configuraciones más comunes que nuestros usuarios utilizan para sus proyectos. ### Modo quiosco con launcher personalizado Reemplaza la pantalla de inicio con un launcher que restringe el dispositivo a las apps instaladas a través de la configuración de aplicaciones. Las apps aparecen en una sola página en orden alfabético. - **Modo quiosco con launcher personalizado activado** = `true`. - **Personalización del modo quiosco** (opcional): Hay muchas opciones disponibles que puedes usar para personalizar el comportamiento del modo quiosco personalizado. :::tip Recomendamos activar **Escotilla de Escape de Red Activada** (`networkEscapeHatchEnabled`: `true`), ya que permite a los usuarios conectarse temporalmente a una red si el dispositivo no puede establecer conectividad al arrancar, asegurando que las políticas de dispositivos puedan actualizarse correctamente. ::: ``` { "config": { "applications": [...], "networkEscapeHatchEnabled": true, "kioskCustomization": { "deviceSettings": "SETTINGS_ACCESS_ALLOWED" } } } ``` ### Modo quiosco de app única La app se instala automáticamente en modo quiosco: se establece como la intención de inicio preferida y se incluye en la lista blanca para el modo de tarea bloqueada. La configuración del dispositivo no se completará hasta que la app esté instalada. Después de la instalación, los usuarios no podrán eliminar la app. Solo puedes establecer este **tipo de instalación** para una app por política. Cuando esto está presente en la política, la barra de estado se deshabilitará automáticamente. - **Configuración de la app**: - Tipo de instalación: `KIOSK`. - **Configuración de la política** (opcional). **Actividades preferidas persistentes**: - **Actividad receptora**: nombre de tu actividad receptora, ej.: `com.applivery.kiosk.demo001/.AppliveryDeviceAdminReceiver` - **Categorías**: ej. `android.intent.category.LAUNCHER`. `android.intent.category.HOME`. `android.intent.category.DEFAULT`. - **Acciones**: ej.: `android.intent.action.MAIN`. :::tip Recomendamos activar **Escotilla de Escape de Red Activada** (`networkEscapeHatchEnabled`: `true`), ya que permite a los usuarios conectarse temporalmente a una red si el dispositivo no puede establecer conectividad al arrancar, asegurando que las políticas de dispositivos puedan actualizarse correctamente. ::: ``` { "config":{ "applications":[ { "packageName":"com.applivery.kiosk.demo001", "installType":"KIOSK", "defaultPermissionPolicy":"GRANT", "permissionGrants":[ { "permission":"android.permission.BIND_DEVICE_ADMIN", "policy":"GRANT" } ] } ], "persistentPreferredActivities":[ { "receiverActivity":"com.applivery.kiosk.demo001/.AppliveryDeviceAdminReceiver", "actions":[ "android.intent.action.MAIN" ], "categories":[ "android.intent.category.LAUNCHER", "android.intent.category.HOME", "android.intent.category.DEFAULT" ] } ], "networkEscapeHatchEnabled":true } } ``` ### Modo quiosco de web app También puedes usar Google Chrome en modo quiosco para mostrar una URL específica como una app única, logrando el comportamiento deseado en tu dispositivo dedicado. Para configurar esto, sigue los pasos descritos en la sección [Modo quiosco de app única](#modo-quiosco-de-app-única) anterior, que implica configurar tanto la opción de actividades preferidas persistentes como el **Network Escape Hatch**. - **Configuración de la web app**: - Tipo de instalación: `KIOSK`. - **Configuración de Google Chrome**: - Tipo de instalación: `FORCE_INSTALLED`. - Configuración gestionada: Lista de URLs permitidas:`["URL permitida"]`. Lista de URLs bloqueadas:`["*"]`. :::info Se permiten múltiples web apps, separadas por comas, ej.: `["URL permitida 1", "URL permitida 2"]` ::: ``` { "applications": [ { "packageName": "com.google.enterprise.webapp.xbf6a96eb033caa10", "installType": "KIOSK", "defaultPermissionPolicy": "GRANT" }, { "packageName": "com.android.chrome", "installType": "FORCE_INSTALLED", "defaultPermissionPolicy": "GRANT", "managedConfiguration": { "URLAllowlist": "["applivery.com/docs/"]", "URLBlocklist": "["*"]" } } ], "persistentPreferredActivities": [ { "receiverActivity": "com.android.chrome/com.google.android.apps.chrome.Main", "actions": [ "android.intent.action.MAIN" ], "categories": [ "android.intent.category.HOME", "android.intent.category.DEFAULT" ] } ], "networkEscapeHatchEnabled": true, "kioskCustomization": { "systemNavigation": "NAVIGATION_DISABLED" } } ``` ### Permitir instalación desde fuentes desconocidas A veces necesitarás permitir a tus usuarios instalar apps (archivos `.apk` o `.aab`) de terceros o de tu Enterprise Store en Applivery MAM. Esto normalmente está bloqueado por defecto en todas las políticas, por lo que deberás personalizar la siguiente propiedad de política para hacerlo posible: - **Anulaciones de seguridad avanzadas**: - **Política de apps no confiables** = `ALLOW_INSTALL_DEVICE_WIDE`. - **Modo Play Store** = `BLACKLIST`. ``` { "config": { "applications": [...], "advancedSecurityOverrides": { "untrustedAppsPolicy": "ALLOW_INSTALL_DEVICE_WIDE" } "playStoreMode: "BLACKLIST" } } ``` ### Permitir instalar apps desconocidas A veces necesitarás permitir a los usuarios conceder permiso a apps específicas para instalar otras apps (archivos `.apk`) en su dispositivo. **Esto es diferente de la configuración de fuentes desconocidas**, que permite la instalación de apps de fuentes distintas a Google Play Store. Esta característica proporciona un control más granular sobre qué apps pueden instalar otras apps en tu dispositivo Android. A menudo se utiliza para apps como gestores de archivos o navegadores web que pueden necesitar descargar e instalar archivos `.apk`. :::warning Recuerda que permitir a las apps instalar apps desconocidas puede suponer un riesgo de seguridad, abriendo la puerta a la instalación de apps potencialmente dañinas o no verificadas en tu dispositivo. ::: ``` { "advancedSecurityOverrides": { "untrustedAppsPolicy": "ALLOW_INSTALL_DEVICE_WIDE", "developerSettings": "DEVELOPER_SETTINGS_ALLOWED" } } ``` ### Configuración de red A veces necesitarás desplegar remotamente configuraciones de red, incluyendo Wi-Fi y otras. Esto se puede hacer utilizando la propiedad **Open Network Configuration**, que permite desplegar múltiples configuraciones al mismo tiempo utilizando el [estándar ONC](https://chromium.googlesource.com/chromium/src/+/main/components/onc/docs/onc_spec.md). Las propiedades más comunes son: - **GUID:** identificador único para esta red. - **Name:** nombre descriptivo de la red. - **Type:** tipo de red. Los valores permitidos son: `VPN`, `WiFi`, `Tether`, `Ethernet`, `Cellular`. - **Security:** tipo de seguridad. Los valores permitidos son: `WEP-PSK`, `WEP-8021X`, `WPA-PSK`, `WPA-EAP`. - **AutoConnect:** indica si la red debe conectarse automáticamente cuando sea posible (`true` o `false`). ![onc](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/233c5a28-c945-44ca-be39-b4a3e94fa0e7.png) ``` { "NetworkConfigurations": [{ "GUID": "a", "Name": "Example A", "Type": "WiFi", "WiFi": { "SSID": "Example A", "Security": "None", "AutoConnect": true } }, { "GUID": "b", "Name": "Example B", "Type": "WiFi", "WiFi": { "SSID": "Example B", "Security": "WEP-PSK", "Passphrase": "1234567890" } }, { "GUID": "c", "Name": "Example C", "Type": "WiFi", "WiFi": { "SSID": "Example C", "Security": "WPA-PSK", "Passphrase": "baseball" } }] } ``` Puedes leer más sobre las [especificaciones de Open Network Configuration aquí](https://chromium.googlesource.com/chromium/src/+/main/components/onc/docs/onc_spec.md). --- ## Acciones de configuración Source: https://docs.applivery.com/es/device-management/android/policies/setup-actions/ Description: Automatiza la configuración inicial de dispositivos Android Enterprise con Acciones de configuración de Applivery para garantizar el cumplimiento. TL;DR: Las Acciones de configuración de Applivery simplifican la inscripción de dispositivos Android Enterprise automatizando las tareas de configuración inicial para garantizar el cumplimiento y la consistencia. Answers: ¿Cómo automatizar la configuración de dispositivos Android? · ¿Qué son los Acciones de configuración de Android en Applivery? · ¿Cómo configurar Acciones de configuración en Applivery? · ¿Qué es la inscripción Zero-Touch para Android? · ¿Cómo garantizar el cumplimiento en dispositivos Android con Applivery? · ¿Cómo usar Applivery para MDM en Android? · ¿Cuáles son las limitaciones de los Acciones de configuración de Android en Applivery? · ¿Cómo lanzar apps automáticamente durante la configuración de Android? Key topics: Android Enterprise, Acciones de configuración de Applivery, Configuración automatizada de dispositivos, Políticas MDM, Zero-Touch Enrollment, Applivery, Android Management API (AMAPI), Google, Slack Durante la inscripción de dispositivos Android gestionados con Android Enterprise, a menudo es necesario ejecutar ciertas acciones automáticamente durante la configuración inicial. Estas acciones preparan el dispositivo antes de que el usuario empiece a usarlo, garantizando el cumplimiento de los requisitos de la organización en materia de seguridad, operaciones y configuración técnica. Las Acciones de configuración en Applivery permiten a los administradores de IT ejecutar estas acciones como parte del flujo de aprovisionamiento, proporcionando consistencia en los dispositivos corporativos, despliegues masivos o configuraciones críticas que deben aplicarse antes de que el usuario interactúe con el dispositivo. ### Configuración **Ir a Políticas** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a **Políticas** 1. **Seleccionar la política Android** Elige la política Android específica que quieres modificar. **Acceder a Todas las propiedades** En el menú lateral izquierdo, haz clic en la sección **Todas las propiedades** 2. **Elegir Acciones de configuración** Localiza **Acciones de configuración** 3 y haz clic en el botón **\+ Añadir elemento**. ![Acciones de configuración](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/bf112771-4b7b-4035-a44e-aac70472e6ef.png) Cada Setup Action requiere definir los siguientes elementos: - **Descripción** (opcional): Texto adicional que se muestra durante la ejecución de la acción. - **Lanzar app**: Permite que una aplicación se ejecute automáticamente durante la configuración inicial del dispositivo. Especifica el **nombre de paquete** de la app Android que se va a ejecutar (p. ej., una app corporativa, un agente de seguridad o una app de configuración como com.slack). - Opcionalmente, incluye un mensaje de **Título** visible para el usuario durante la configuración, explicando qué se está configurando. :::warning La aplicación debe estar incluida en la política y configurada como `REQUIRED FOR SETUP`; de lo contrario, el proceso de aprovisionamiento fallará. La acción solo se ejecutará una vez durante la configuración inicial del dispositivo. ::: ### Consideraciones importantes - **Ejecución única**: Los Acciones de configuración solo se ejecutan durante la primera configuración del dispositivo. No se repetirán en actualizaciones o sincronizaciones posteriores de la política. - **Dispositivos compatibles**: Los Acciones de configuración están pensados principalmente para dispositivos de empresa totalmente administrados o escenarios de inscripción Zero-Touch / QR. - **Dependencia de la aplicación**: Si la acción lanza una aplicación, esta debe estar configurada como `REQUIRED FOR SETUP`, y cualquier fallo durante la instalación o ejecución bloqueará el proceso de aprovisionamiento. - **Experiencia de usuario**: Las acciones se ejecutan antes de que el usuario tenga acceso completo al dispositivo, lo que garantiza la consistencia pero puede aumentar el tiempo de configuración inicial. - **Uso recomendado**: Usa los Acciones de configuración solo para configuraciones críticas, apps necesarias para completar la incorporación o flujos de trabajo de aprovisionamiento automatizado. :::warning Debido a las restricciones de la Android Management API (AMAPI), solo se puede configurar un Setup Action en esta sección. Los Acciones de configuración adicionales se pueden implementar usando el [Launcher avanzado de Applivery en modo quiosco](https://docs.applivery.com/es/device-management/android/policies/kiosk-mode/#launcher-avanzado-modo-quiosco-multiaplicación) con la opción de inicio automático en el primer arranque, teniendo en cuenta las limitaciones propias del modo quiosco. ::: Los Acciones de configuración de Android en Applivery son una herramienta esencial para automatizar y estandarizar la configuración del primer arranque de los dispositivos Android gestionados. Garantizan que las aplicaciones y procesos críticos se ejecuten de inmediato, reducen los errores manuales y mejoran la eficiencia en los despliegues corporativos. Cuando se planifican y aplican correctamente, los Acciones de configuración permiten una experiencia de incorporación controlada, segura y repetible, especialmente en entornos con grandes volúmenes de dispositivos o requisitos de configuración estrictos. --- ## Tethering Source: https://docs.applivery.com/es/device-management/android/policies/tethering/ Description: Controla el tethering en dispositivos Android con políticas de Applivery: hotspot Wi-Fi, USB y Bluetooth. TL;DR: Gestiona las políticas de tethering Android con Applivery para habilitar, deshabilitar o restringir el tethering según las necesidades de tu organización. Answers: cómo deshabilitar el tethering en Android · configuración de políticas Android con Applivery · tethering en gestión de dispositivos móviles · política de tethering Android · controlar el hotspot Android · gestionar el uso de datos móviles · gestión de dispositivos Applivery · ajustes de tethering Android Key topics: Gestión de dispositivos Android, Seguridad móvil, Configuración de políticas, Applivery, Android, Wi-Fi, USB, Bluetooth El tethering en dispositivos Android permite a los usuarios compartir su conexión de datos móviles con otros dispositivos mediante **Wi-Fi**, **USB** o **Bluetooth**. En un entorno gestionado, controlar esta función es fundamental para garantizar un uso seguro y eficiente de los recursos corporativos. **Habilitar el tethering** puede ser beneficioso en ciertos escenarios, como cuando los empleados viajan o trabajan en zonas con acceso Wi-Fi limitado. Sin embargo, también presenta riesgos, como el uso excesivo de datos, accesos no autorizados a la red y potenciales vulnerabilidades de seguridad. Por otro lado, **deshabilitar el tethering** respalda políticas de uso de datos más estrictas, ayuda a evitar el uso indebido de los dispositivos como puntos de acceso móviles y minimiza el riesgo de amenazas externas. ### Configurar una política de tethering **Ir a Políticas** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a **Políticas** 1. **Seleccionar la política Android** Selecciona la política Android donde quieres configurar el tethering. **Ir a la sección Red** En el menú lateral izquierdo, haz clic en la sección **Red**. **Elegir la opción de tethering deseada** En la configuración de **Gestión de conectividad del dispositivo** 2, elige la opción que mejor se adapte a tus necesidades en **Ajustes de tethering** 4: - **ALLOW ALL TETHERING**: Esta opción habilita todas las formas de tethering (Wi-Fi, USB y Bluetooth) en el dispositivo. - **DISALLOW Wi-Fi TETHERING**: Esta opción bloquea el tethering Wi-Fi, mientras que otros tipos (p. ej., USB, Bluetooth) pueden seguir disponibles. - **DISALLOW ALL TETHERING**: Esta opción deshabilita completamente el tethering en todos los tipos de conexión. Es compatible con dispositivos totalmente administrados, perfiles de trabajo en dispositivos de empresa y todas las versiones de Android compatibles con Applivery. En los tres casos, cualquier configuración relacionada con **Tethering Config Disabled** se ignorará. ![thetering](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/24135ff0-26d9-4270-91ee-62e188de8aec.png) :::warning **DISALLOW Wi-Fi TETHERING** solo es compatible con dispositivos de empresa con Android 13 o superior. Si el dispositivo ejecuta una versión anterior, el sistema aplicará **ALLOW ALL TETHERING** y se notificará un `nonComplianceDetail` indicando la incompatibilidad con el nivel de API. ::: Gestionar el tethering Android a través de Applivery permite a las organizaciones encontrar un equilibrio eficaz entre la flexibilidad del usuario y el control administrativo. Si bien **habilitar el tethering** puede aumentar la autonomía del usuario, especialmente en escenarios como viajes o conectividad limitada, también introduce riesgos relacionados con el consumo de datos y la seguridad de red. Por el contrario, **deshabilitar el tethering** refuerza la postura de seguridad y proporciona una mayor supervisión del uso de la red, lo que resulta especialmente valioso en entornos con requisitos de cumplimiento estrictos. Con Applivery, estos ajustes se pueden gestionar de forma centralizada y personalizar para grupos de dispositivos específicos, garantizando una aplicación coherente de las políticas en toda la flota de dispositivos móviles. ### Compatibilidad con dispositivos AOSP La política de tethering es totalmente compatible con AOSP: mismas opciones, mismos pasos. No se requieren servicios de Google. --- ## Configuración del fondo de pantalla Source: https://docs.applivery.com/es/device-management/android/policies/wallpaper-configuration/ Description: Aplica una imagen corporativa como fondo de pantalla en dispositivos Android gestionados mediante el Launcher avanzado de Applivery. TL;DR: Configura el fondo de pantalla en política → Quiosco → Launcher avanzado → Personalización → Fondo de pantalla, con la URL de la imagen. No hace falta bloquear el dispositivo: basta con el modo Launcher. Answers: ¿Cómo pongo un fondo de pantalla corporativo en dispositivos Android con Applivery? · ¿Dónde se configura el fondo de pantalla en una política Android? · ¿Necesito activar el modo quiosco para aplicar un fondo de pantalla? · ¿Qué tipo de dispositivos admiten el fondo de pantalla corporativo? · ¿Cómo indico la imagen: la subo o uso una URL? · ¿Por qué no se aplica el fondo de pantalla en mi dispositivo Android? Key topics: Fondo de pantalla en el Launcher avanzado, Modo Launcher frente a modo Kiosk, Personalización del launcher, Resolución de problemas, Applivery, Android, Launcher avanzado, AOSP En Android, el fondo de pantalla corporativo se configura desde el **Launcher avanzado** de Applivery, indicando la URL de la imagen. No hace falta bloquear el dispositivo en modo quiosco: basta con usar el modo **Launcher**. A diferencia de [Windows](https://docs.applivery.com/es/device-management/windows/policies/wallpaper-configuration/) y [macOS](https://docs.applivery.com/es/device-management/apple/macos/policies/wallpaper-configuration/), las políticas Android no tienen un ajuste independiente de fondo de pantalla. El fondo forma parte de la personalización del launcher gestionado de Applivery, que reemplaza al launcher predeterminado de Android y permite configuraciones que el launcher nativo no admite. ### Requisitos

Requisito

Detalle

Tipo de gestión

Dispositivos Totalmente gestionados

Funcionalidad

Launcher avanzado (modo Launcher o Kiosk)

Versión mínima de Android

Android 8 (requisito del Launcher avanzado)

Imagen

Alojada en un host accesible desde la web; se indica por URL

AOSP

Compatible: el Launcher avanzado funciona en AOSP igual que en dispositivos totalmente gestionados (AMAPI)

:::warning El Launcher avanzado reemplaza el launcher del dispositivo. Si solo necesitas el fondo de pantalla y quieres que el dispositivo siga comportándose como un Android normal, usa el modo **Launcher** y no el modo **Kiosk**. ::: ### Modo Launcher o modo Kiosk Ambos modos admiten el fondo de pantalla, porque la personalización forma parte de la configuración general del Launcher avanzado.

Modo

Qué hace

Cuándo elegirlo para el fondo de pantalla

Launcher

Launcher gestionado de Applivery, sin restricciones de quiosco

Dispositivos corporativos de uso general que solo necesitan imagen de marca y controles adicionales

Kiosk

Quiosco multiaplicación bloqueado

Dispositivos dedicados (retail, señalización) donde además quieres restringir el uso

### Configurar el fondo de pantalla **Aloja la imagen** Sube la imagen corporativa a un servidor accesible desde la web y copia su URL. **Abre la política** En el [**panel de Applivery**](https://dashboard.applivery.io/), ve a **Políticas** 1 y abre la política Android que quieres modificar, o [crea una nueva](https://docs.applivery.com/es/device-management/general-settings/create-policies/). En el menú lateral izquierdo, haz clic en **Quiosco** y cambia a la pestaña **Launcher avanzado** 2. En **Modo del launcher** 3, selecciona **Launcher**, o **Kiosk** si el dispositivo debe quedar bloqueado. En **Personalización**, rellena el campo **Fondo de pantalla** 4 con la URL de la imagen. ![wallpaper](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/19085ca5-7d6b-4037-9633-9d86ad5ee4fe.png) **Guarda y asigna** Guarda la política y asegúrate de que está asignada a los dispositivos de destino. :::info El fondo de pantalla se aplica a través de la capa del launcher de Applivery, no del launcher nativo de Android. ::: ### Qué más puedes personalizar en el mismo apartado En **Personalización** también puedes ajustar el **tamaño de iconos** (Pequeño, Mediano o Grande), la **disposición de apps** y las **carpetas**. Además, la interfaz admite un **encabezado** y un **pie de página** con texto, que puede incluir [variables dinámicas](https://docs.applivery.com/es/device-management/general-settings/dynamic-variables/) como el número de serie del dispositivo, el IMEI o el usuario. Tienes todos los detalles en [Modo quiosco](https://docs.applivery.com/es/device-management/android/policies/kiosk-mode/). ### Si el fondo de pantalla no se aplica - **Comprueba el tipo de gestión.** El Launcher avanzado está pensado para dispositivos totalmente gestionados. - **Comprueba la versión de Android.** El Launcher avanzado requiere Android 8 o superior. - **Comprueba la URL.** Debe apuntar a un host accesible desde la web donde esté almacenada la imagen. Ábrela desde un navegador fuera de tu red corporativa para confirmarlo. - **Comprueba que la política está asignada** al dispositivo y que este la ha recibido. --- ## Soporte Remoto Source: https://docs.applivery.com/es/device-management/android/remote-support/ Description: Habilita el soporte remoto Android en Applivery MDM para acceder y controlar dispositivos de forma remota. Facilita la resolución de problemas de TI. TL;DR: Habilita el Soporte Remoto Android en Applivery MDM para acceder y controlar dispositivos de forma remota, facilitando la resolución de problemas y la gestión eficiente. Answers: ¿Cómo habilitar el soporte remoto en Android con Applivery? · ¿Cómo iniciar una sesión de soporte remoto en Applivery MDM? · ¿Qué es el modo de soporte remoto desatendido? · ¿Qué permisos se requieren para el soporte remoto desatendido? · ¿Cómo calibrar la pantalla para el soporte remoto desatendido? · ¿Cómo solucionar problemas de dispositivos Android de forma remota? Key topics: Habilitar el soporte remoto en Applivery, Iniciar sesiones de soporte remoto, Soporte remoto atendido vs. desatendido, Gestión de dispositivos Android, Applivery, Android, MDM, Profesionales de TI ![remote support](https://www.applivery.com/wp-content/uploads/2024/11/Remote-Support-image-1024x623.png "remote support | Applivery") :::warning El Soporte Remoto requiere los Google Mobile Services y **no está disponible en dispositivos AOSP**. ::: El **Soporte Remoto MDM**, o **Soporte Remoto de Gestión de Dispositivos Móviles** (incluyendo el **Control Remoto** o el **Acceso Remoto**), permite a un administrador autorizado acceder y controlar de forma remota dispositivos como smartphones, tablets u ordenadores de escritorio. Esta capacidad se utiliza para gestionar y solucionar problemas de los dispositivos de manera eficiente. El Soporte Remoto permite a los profesionales de TI diagnosticar y resolver los problemas técnicos de los usuarios desde una ubicación remota. Sirve como una herramienta crítica para los gerentes de TI, facilitando la resolución rápida de problemas sin requerir presencia física. Este enfoque no solo mejora la eficiencia del soporte, sino que también aumenta la satisfacción y productividad del **usuario**. Con la **app de Soporte Remoto de Applivery**, puedes asistir a los usuarios viendo o controlando directamente sus dispositivos Android. Las sesiones de soporte se pueden iniciar instantáneamente desde Applivery, lo que te permite actuar como agente y proporcionar asistencia remota fluida a los usuarios de los dispositivos. ### Habilitar el Soporte Remoto a nivel de política El Soporte Remoto Android de Gestión de Dispositivos de Applivery se habilita a nivel de política. Ve a cualquiera de tus políticas 1 y selecciona la sección **Soporte remoto** 2 del menú lateral izquierdo. ![enable remote support](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/90e56935-985a-491d-ae80-688dfda6390e.png) Para habilitar la app de Soporte Remoto, haz clic en el botón **Habilitar** situado en la parte superior derecha 3. Por último, decide si quieres que la app se instale en el modo **Requerida para la Configuración**. Esta es la forma más común para los dispositivos nuevos, y la app se instalará durante el proceso de inscripción para asegurar que esté instalada antes de que el sistema se inicie. Si no seleccionas esta opción, la aplicación se instalará en modo de **instalación forzada**, que es el escenario más común. En este caso, la app de Soporte Remoto se instalará automáticamente en los dispositivos y no podrá ser eliminada. No olvides hacer clic en el botón **Guardar cambios** antes de salir de la página para desplegar todas tus modificaciones. ### Iniciar una nueva sesión Hay dos formas de solicitar asistencia remota: **por parte del usuario** o **por parte del administrador**. Si eres el administrador, navega a cualquiera de tus dispositivos Android para iniciar una sesión. En el lateral del dispositivo, haz clic en el botón **Acción** 4 y luego selecciona **Soporte Remoto** 5. Hay dos modos de operación: - **Solicitar permiso**: El usuario debe aceptar la solicitud para iniciar la sesión. - **Desatendido**: Inicia la sesión sin interacción del usuario. :::warning Para el **modo desatendido**, asegúrate de que la app de Soporte Remoto **se haya abierto al menos una vez**, **se hayan concedido todos los permisos necesarios** y **la pantalla se haya calibrado correctamente**. ::: ![action remote support](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/421ebc31-664c-49a4-b649-526abb211415.png) ### ¡Mira cómo hacerlo! :::warning Para el **modo desatendido**, sigue cuidadosamente las instrucciones en pantalla. La calibración requiere identificar la ubicación del botón "Iniciar ahora". Para lograr esto, **toma una captura de pantalla cuando aparezca el cuadro de diálogo**. **No tienes que pulsar el botón "Iniciar ahora"**. ::: --- ## Postura de seguridad Source: https://docs.applivery.com/es/device-management/android/security-posture/ Description: Entiende la postura de seguridad en Android con Applivery. Aprende qué significan Seguro, En riesgo y Potencialmente comprometido y cómo actuar ante un dispositivo comprometido. TL;DR: Applivery informa de si el sistema operativo de un dispositivo Android ha sido manipulado, mediante un escudo en el listado de dispositivos y una comprobación de conformidad dentro del dispositivo. Necesita Google Mobile Services, así que AOSP no está cubierto. Answers: ¿Qué es la postura de seguridad de un dispositivo Android? · ¿Dónde veo la postura de seguridad en Applivery? · ¿Qué significa "Potencialmente comprometido"? · ¿Detecta Applivery los dispositivos Android rooteados? · ¿Por qué mis dispositivos AOSP no tienen postura de seguridad? · ¿Puedo aplicar automáticamente una política restrictiva a un dispositivo comprometido? · ¿Cuál es la diferencia entre postura de seguridad y estado de conformidad? · ¿Una postura de seguridad mala bloquea el dispositivo automáticamente? Key topics: Postura de seguridad en Android, Play Integrity API, Detección de dispositivos comprometidos, Conformidad del dispositivo, Applivery, Android, Google Play Services No todos los riesgos de un dispositivo vienen de un ajuste que puedas configurar. Un dispositivo puede cumplir todas las políticas que le has asignado y aun así no ser de fiar, sencillamente porque alguien ha modificado su sistema operativo. La **postura de seguridad** es la señal que te avisa de que eso ha ocurrido. Responde a una pregunta distinta de la del resto de tus políticas: no _"¿está este dispositivo configurado como pedí?"_ sino _"¿puedo seguir confiando datos corporativos a este dispositivo?"_. ### Qué te dice la postura de seguridad Android Enterprise evalúa cada dispositivo y reporta uno de estos tres valores:

Valor

Qué significa

Seguro (SECURE)

El dispositivo es seguro.

En riesgo (AT_RISK)

El dispositivo puede ser más vulnerable ante actores maliciosos de lo recomendable para usarse con datos corporativos.

Potencialmente comprometido (POTENTIALLY_COMPROMISED)

El dispositivo puede estar comprometido y los datos corporativos que contiene podrían ser accesibles para terceros no autorizados.

**Potencialmente comprometido** es el valor que obtienes ante un dispositivo rooteado. Conviene tratarlo como un incidente y no como un aviso: a partir de ahí ya no puedes dar por hecho que las restricciones de tu política se estén aplicando de verdad, porque el sistema operativo que las aplica es justo la parte que se ha modificado. ### Dónde consultarla en el panel Applivery muestra la postura de seguridad en dos sitios, con dos niveles de detalle distintos. #### En el listado de dispositivos Cada dispositivo del listado muestra un **escudo** junto al campo de la política. Es un resumen de las [comprobaciones de conformidad](https://docs.applivery.com/es/device-management/general-settings/compliance-checks/) del dispositivo:

Escudo

Qué significa

🟢 Verde

El dispositivo es conforme y su postura es Segura.

⚪ Gris

Algo en el dispositivo requiere atención, pero no es la postura de seguridad.

🔴 Rojo

La postura de seguridad es En riesgo o Potencialmente comprometido.

![security posture devices list](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/27c6cb31-c0b5-4e8b-8dca-66b11e9e8f87.png) De aquí se derivan dos cosas, y las dos importan cuando estás triando un parque: - **El rojo siempre es un problema de seguridad**, nunca una configuración pendiente. Gris y rojo son categorías de incidencia distintas y piden respuestas distintas: el gris es operativo, el rojo es una cuestión de si se puede seguir confiando en el dispositivo. - **Los dos valores de riesgo levantan el mismo escudo rojo.** Para distinguir _En riesgo_ de _Potencialmente comprometido_, abre el dispositivo. #### En las comprobaciones de conformidad del dispositivo Abre el dispositivo y ve a la sección **Overview**, donde encontrarás los **Compliance checks**. Un dispositivo cuya postura esté en riesgo o comprometida tiene una comprobación propia, en rojo, titulada con el valor de la postura: **En riesgo** o **Potencialmente comprometido**. ![security posture device overview](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/3a32e80c-2687-47ff-abfd-7bb7c8a39b41.png) Dentro, por cada riesgo detectado, obtienes: - **El nombre del riesgo** — _SO desconocido_, _SO comprometido_ o _Evaluación de hardware fallida_ — con un tooltip que explica qué ha detectado Play Integrity. - **El consejo de Google** para mitigarlo, dirigido a ti como administrador. Por ejemplo: _"El usuario debería bloquear el bootloader de su dispositivo"_. Un dispositivo cuya postura sea **Segura** no muestra ninguna comprobación de seguridad. Aquí la ausencia es la buena noticia: no hay una entrada en verde que lo confirme, así que no interpretes "no hay comprobación de seguridad" como "no se ha evaluado". ### Por qué se marca un dispositivo Cuando la postura no es **Segura**, el riesgo concreto que hay detrás es uno de estos tres:

Riesgo

Qué ha detectado Google

SO desconocido (UNKNOWN_OS)

El dispositivo ejecuta un sistema operativo desconocido: la comprobación basicIntegrity se supera, pero ctsProfileMatch falla.

SO comprometido (COMPROMISED_OS)

El dispositivo ejecuta un sistema operativo comprometido: la comprobación basicIntegrity falla.

Evaluación de hardware fallida (HARDWARE_BACKED_EVALUATION_FAILED)

El dispositivo no ofrece una garantía sólida de integridad del sistema: falta la etiqueta MEETS_STRONG_INTEGRITY en su veredicto de integridad.

Existe un cuarto valor, **Riesgo de seguridad no especificado** (`SECURITY_RISK_UNSPECIFIED`), que aparece cuando Google no concreta el motivo. No es accionable por sí mismo. Los tres proceden de la **Play Integrity API** de Google, que es el componente que realmente inspecciona el dispositivo. Applivery reporta el veredicto; no lo genera. :::info Como la evaluación ocurre del lado de Google, la postura es un _informe_, no un _ajuste_. No hay nada que activar en una política para habilitarla, ni ningún valor que puedas configurar para hacerla más estricta. ::: ### Los dispositivos AOSP no tienen postura de seguridad La Play Integrity API forma parte de **Google Play Services**. Los dispositivos AOSP — las builds sin GMS, habituales en terminales rugerizados e industriales — no tienen Google Play Services, así que no hay ninguna señal de integridad que Android pueda reportar ni postura que Applivery pueda mostrar. No es una limitación de Applivery, y ningún MDM puede sortearla: el componente que realiza la comprobación sencillamente no está presente en el dispositivo. Si necesitas detección de integridad o de root en un parque AOSP, tiene que venir de una solución **Mobile Threat Defense (MTD)** de terceros. ### Actuar ante un dispositivo comprometido La postura de seguridad informa de un riesgo, pero no actúa sobre él. Bloquear o borrar es una decisión aparte, y tienes tres vías: - [**Comandos remotos**](https://docs.applivery.com/es/device-management/android/commands/remote-commands/), aplicados manualmente desde el panel: bloquear el dispositivo, restablecer la contraseña o borrarlo. Es la respuesta directa ante un dispositivo que acabas de ver marcado. - [**Policy Enforcement Rules**](https://docs.applivery.com/es/device-management/android/policies/enforcement-rules/), para acciones automáticas de bloqueo y borrado pasados unos días. Fíjate en a qué reaccionan: a un ajuste de la política que _no se puede aplicar_ en el dispositivo, no a la postura de seguridad. Son un complemento útil, no un consumidor de esta señal. - [**Reglas de automatización**](https://docs.applivery.com/es/device-management/general-settings/automation-rules/), para aplicar automáticamente una política restrictiva de cuarentena. Actúan sobre [audiencias de dispositivos](https://docs.applivery.com/es/device-management/general-settings/device-audiences/), que se construyen a partir de etiquetas, así que necesitas algo que etiquete antes el dispositivo. Eso es lo que aporta una integración de Mobile Threat Defense como [Check Point Harmony Mobile](https://docs.applivery.com/es/device-management/integrations/security/checkpoint-harmony-mobile-integration/): sus grupos de riesgo se corresponden con las etiquetas de Applivery, las etiquetas alimentan una audiencia de dispositivos y la regla de automatización aplica la política de cuarentena. :::warning **Una regla de automatización no puede borrar un dispositivo.** Sus únicas acciones son aplicar una política y añadir un Smart Attribute: configura dispositivos, no envía comandos. Si hay que borrar un dispositivo comprometido, hazlo manualmente con un comando remoto o haz que la política de cuarentena lleve sus propias Policy Enforcement Rules para bloquear y después borrar. No prometas un flujo de un solo paso del tipo "el MTD lo detecta y Applivery lo borra", porque no es lo que ocurre. ::: ### Postura de seguridad y estado de conformidad no son lo mismo Es fácil confundirlas, y la diferencia importa cuando tienes que explicar un dispositivo marcado:

Postura de seguridad

Estado de conformidad

Pregunta que responde

¿Se puede confiar en el sistema operativo?

¿Cumple el dispositivo las políticas que le asigné?

Quién decide

Google, mediante la Play Integrity API

La configuración de tu política

Causa típica de un problema

El dispositivo está rooteado o ejecuta un SO modificado

Un ajuste obligatorio no se aplica, o el usuario ha cambiado algo

¿Se puede configurar?

No — se reporta, no se establece

Sí — depende de las políticas que definas

Un dispositivo puede ser perfectamente conforme y estar a la vez **Potencialmente comprometido**, y esa combinación es precisamente la que conviene vigilar: todo parece correcto, pero la capa que lo garantiza ya no es de fiar. --- ## Resolución de problemas Source: https://docs.applivery.com/es/device-management/android/troubleshooting/ Description: Soluciones a problemas comunes de gestión Android en Applivery: inscripción, políticas, despliegue de apps y configuración OEM. TL;DR: Soluciones a los problemas más comunes de gestión de dispositivos Android en Applivery: inscripción, políticas y despliegue de apps. Answers: ¿Cómo resolver problemas de inscripción en Android? · ¿Cuáles son los conflictos de políticas más comunes en Android? · ¿Cómo solucionar errores de despliegue de apps en Android? · ¿Cómo configurar el modo quiosco en Android? · ¿Cómo gestionar los ajustes OEM en dispositivos Android? Key topics: Inscripción de dispositivos Android, Gestión de políticas, Despliegue de apps, Configuración del modo quiosco, Gestión de ajustes OEM, Android, Applivery, OEM Diagnostica y resuelve los problemas más comunes de gestión de dispositivos Android en Applivery, incluyendo fallos de inscripción, conflictos de políticas, errores de despliegue de apps, problemas del modo quiosco e incidencias de configuración OEM. Cada artículo explica la causa probable y los pasos para resolverlo, para que puedas solucionar el problema rápidamente sin necesidad de escalar al soporte. --- ## El agente deja de reportar Source: https://docs.applivery.com/es/device-management/android/troubleshooting/agent-not-reporting/ Description: Los dispositivos Android que se quedan callados durante horas y luego vuelven a reportar suelen estar suspendidos por la capa de batería del fabricante. TL;DR: Un dispositivo que se queda callado durante horas y luego vuelve suele estar suspendido por la capa de batería del fabricante. Excluye el agente de la optimización de batería. Answers: ¿Por qué mi dispositivo Android aparece como inactivo en Applivery? · ¿Por qué un dispositivo deja de reportar durante unas horas? · ¿Cómo excluyo una app de la optimización de batería? · ¿El modo Doze se aplica mientras el dispositivo carga? Key topics: Descartar Doze, Exclusiones de batería por fabricante, Dispositivos marcados como inactivos, Applivery, Android, Xiaomi, OPPO, Samsung Un dispositivo reporta con normalidad durante un tiempo, luego se queda callado casi un día entero y después reaparece como si no hubiera pasado nada. Nadie lo tocó, no falló nada, y muchas veces estuvo todo el rato en el cargador. Eso casi siempre es la **capa de batería** del fabricante suspendiendo el agente de Applivery para ahorrar energía. Muchos fabricantes de Android añaden su propia gestión de energía por encima de la de Android, y es bastante más agresiva: decide qué apps en segundo plano se suspenden, y el agente es una app más para ella. ### Descartar el ahorro de energía de Android Android tiene su propio mecanismo, Doze, y es el sospechoso obvio. Normalmente es el equivocado. :::info **Doze no se aplica mientras el dispositivo está cargando.** Así que si el dispositivo estaba enchufado y aun así dejó de reportar, el ahorro de energía propio de Android queda descartado y la causa es la capa del fabricante. Esta única comprobación separa los dos casos. ::: ### Excluir el agente de la optimización de batería La solución es decirle al dispositivo que deje en paz al agente. La ruta exacta depende del fabricante y de la versión de su capa de Android, así que tómalas como punto de partida y no como pasos exactos.

Fabricante

Ruta

Redmi / Xiaomi

Ajustes → Aplicaciones → Gestionar aplicaciones → selecciona la app → activa Inicio automático y pon el ahorro de batería en Sin restricciones.

OPPO

Ajustes → Batería → selecciona la app → permite actividad en segundo plano sin restricciones.

Samsung

Ajustes → Batería → Límites de uso en segundo plano → comprueba que la app no figura en "Aplicaciones inactivas" ni "Aplicaciones en suspensión profunda".

:::warning **Una actualización de firmware puede revertir las exclusiones.** Inclúyelas en tus revisiones periódicas de los modelos afectados en lugar de darlas por hechas de una vez para siempre. ::: Para el detalle por marca, [dontkillmyapp.com](https://dontkillmyapp.com) es una referencia comunitaria útil. No es documentación oficial, así que úsala junto a los ajustes del propio fabricante y no en su lugar. ### Dispositivos marcados como inactivos Un dispositivo se marca como inactivo tras 5 días sin reportar, así que un agente suspendido es una de las formas en que un dispositivo perfectamente sano acaba señalado. Consulta [Estados de dispositivo](https://docs.applivery.com/es/device-management/general-settings/device-states/) para saber qué significan realmente los campos de estado. Si la exclusión está puesta y el dispositivo sigue quedándose callado, contacta con el soporte de Applivery: podemos revisar la actividad del agente en ese dispositivo y confirmar si sigue siendo suspendido. --- ## Pérdida de conexión a internet Source: https://docs.applivery.com/es/device-management/android/troubleshooting/internet-connection-loss/ Description: Evita que la pérdida de conexión interrumpa los dispositivos en modo quiosco con la función Escotilla de Escape de Red Activada de Applivery. TL;DR: Escotilla de Escape de Red Activada garantiza el funcionamiento ininterrumpido del modo quiosco permitiendo conexiones de red temporales para actualizar las políticas cuando no hay conexión estable. Answers: ¿Qué es Escotilla de Escape de Red Activada? · ¿Cómo evitar la pérdida de internet en el modo quiosco? · ¿Cómo configurar Escotilla de Escape de Red Activada? · ¿Qué ocurre cuando el modo quiosco pierde la conexión? · ¿Cómo actualizar la política del dispositivo sin internet? Key topics: modo quiosco, conectividad a internet, Escotilla de Escape de Red Activada, política de dispositivo, Android Mantener una conexión a internet estable es fundamental para el funcionamiento sin interrupciones de los dispositivos en modo quiosco. Sin embargo, hay situaciones en las que estos dispositivos pueden perder la conectividad. Esta es la principal razón por la que recomendamos activar la propiedad "**Escotilla de Escape de Red Activada**" para gestionar esta situación al configurar las políticas de dispositivo. :::tip Activar la Escotilla de Escape de Red Activada garantiza el funcionamiento ininterrumpido del modo quiosco, incluso con conectividad intermitente. ::: Esta función permite garantizar el funcionamiento continuo de los dispositivos en modo quiosco. Al arrancar, si no se puede establecer conexión, el escape hatch solicita al usuario que se conecte temporalmente a una red para actualizar la política del dispositivo. Una vez aplicada la política, la información de red temporal se elimina y el dispositivo continúa el arranque. Esto evita situaciones en las que el dispositivo no puede conectarse a ninguna red por la ausencia de una red adecuada en la última política. También previene escenarios en los que el dispositivo arranca en una app en modo de tarea bloqueada o el usuario no puede acceder a los ajustes del dispositivo. Para obtener más información sobre la configuración del modo quiosco, te recomendamos consultar nuestro artículo sobre el [modo quiosco de Android](https://docs.applivery.com/es/device-management/android/policies/kiosk-mode/). --- ## Tu app privada no puede hacer llamadas con el modo quiosco activado Source: https://docs.applivery.com/es/device-management/android/troubleshooting/private-app-calls-kiosk-mode/ Description: Si una app de Android no puede llamar solo cuando el dispositivo está en modo quiosco, añade a la política las apps de Teléfono del sistema que usan tus dispositivos. TL;DR: Si una app no puede llamar solo en modo quiosco, añade a la política las apps de Teléfono del sistema (los dialers) que usan tus dispositivos. En un quiosco, las apps del sistema no se muestran ni se gestionan por defecto. Key topics: Síntomas de llamadas bloqueadas en quiosco, Diagnóstico con una política duplicada, Añadir los dialers como apps del sistema, Alternativa temporal con el modo Launcher, Applivery, Android, Launcher avanzado, Modo quiosco Si una app no puede llamar solo cuando el dispositivo está en modo quiosco, añade a la política las apps de Teléfono del sistema (los _dialers_) que usan tus dispositivos y vuelve a probar. En un quiosco, las apps del sistema no se muestran ni se gestionan por defecto, así que hay que incluirlas de forma explícita. ### Síntomas - Una app intenta iniciar una llamada y esta se interrumpe de golpe o no llega a establecerse. - La app de Teléfono del sistema sí permite llamar, o la app tampoco puede recibir llamadas. - El problema desaparece al quitar el quiosco o al pasar el Launcher avanzado a modo **Launcher**. - Cambiar la app de Teléfono predeterminada no lo soluciona. ### Qué ocurre En Applivery, el **Launcher avanzado** tiene dos modos de funcionamiento:

Modo

Qué hace

Restricciones

Launcher

Ofrece un launcher con las apps de la política

No aplica las restricciones de quiosco

Kiosk

Activa un quiosco multiaplicación completo

Sí aplica restricciones al dispositivo

El [modo quiosco](https://docs.applivery.com/es/device-management/android/policies/kiosk-mode/) restringe el dispositivo a las apps que defines en la política, y sus ajustes exclusivos solo se aplican cuando el dispositivo está realmente en modo quiosco. Este problema aparece sobre todo con apps que **hacen llamadas desde dentro de la propia app**. Esas apps suelen invocar la **app de Teléfono del dispositivo** para establecer la llamada. Si el modo Kiosk bloquea esa app de Teléfono, la llamada no se puede iniciar. ### Cómo diagnosticarlo Haz estas pruebas en un dispositivo de prueba con una copia de tu política de producción:

Prueba

Resultado

Conclusión

Llamar desde la app de Teléfono del sistema, fuera de la app afectada

Funciona

El dispositivo y la línea están bien

Llamar desde la app afectada con el quiosco activo

Falla

Posible bloqueo por el quiosco

Llamar desde la app afectada con el quiosco retirado (con el resto de políticas aplicadas)

Funciona

El problema está en el quiosco, no en las demás políticas

Cambiar el Launcher avanzado de Kiosk a Launcher

Funciona

Confirma que depende del modo Kiosk

:::warning Prueba siempre con una política duplicada y un solo dispositivo. No cambies la política de producción para diagnosticar. ::: ### Solución: añadir los dialers a la política **Abre la política** En el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a la política 1 afectada y, desde el menú lateral izquierdo, selecciona **Apps** 2 y haz click en **\+ Añadir App** 3. ![add app](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/99357efb-6f20-4548-a9c9-d0df179cd02e.png) **Elige la app de Teléfono** Selecciona la pestaña **App del sistema**. Elige la app de Teléfono que usan tus dispositivos o escribe su nombre de paquete. Si hay varios fabricantes en la flota, añade la de cada uno. ![dialer](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/7dced32d-ba08-4feb-853f-cfcebdedc628.png) :::info Para encontrar el nombre de paquete, activa **Informes de aplicación activados** en la sección **Reportes** de la política. La lista completa de apps, incluidas las del sistema, aparece después en el detalle del **Dispositivo**, en **Apps**. Tienes más detalles en [Apps del sistema](https://docs.applivery.com/es/device-management/android/app-management/system-apps/). ::: **Añádela como Available** Haz clic en **Seleccionar**, elige el tipo de instalación **Disponible** y añade la app a la lista de la política. **Guarda y prueba** Guarda la política y espera a que el dispositivo la reciba. Después, comprueba una llamada saliente y una entrante desde la app afectada. ### Qué no suele resolver el problema Estas acciones **no** corrigen el bloqueo: - Conceder permisos a la app mediante _Grant permissions_ en las propiedades gestionadas. - Establecer otra app de Teléfono como predeterminada, tanto la de Google como la del fabricante. ### Alternativa temporal Si necesitas que las llamadas funcionen mientras ajustas la política, usa el Launcher avanzado en modo **Launcher**. Ten en cuenta que no aplica las restricciones de quiosco (barra de estado, navegación, botón de encendido, acceso a Configuración), así que el dispositivo queda menos bloqueado. ### Si sigue fallando - Confirma que el dispositivo ha recibido la política más reciente. - Verifica que la app de Teléfono aparece en la lista de apps de la política y que el nombre de paquete coincide con el que usa el dispositivo. - Repite las pruebas del diagnóstico para confirmar que el fallo sigue dependiendo del modo Kiosk. - Si el problema persiste, contacta con el soporte de Applivery indicando el modelo del dispositivo, la política y el momento exacto del fallo. --- ## Mi dispositivo ya no está inscrito pero sigue con restricciones Source: https://docs.applivery.com/es/device-management/android/troubleshooting/unenrolled-device-restrictions/ Description: Causas por las que un dispositivo Android queda en un estado intermedio tras desinscribirlo o borrarlo desde Applivery, y cómo restablecerlo de fábrica y recuperarlo. TL;DR: El dispositivo nunca recibió o no pudo ejecutar la orden de baja: estaba sin red, el comando caducó o estaba en BFU. Si puedes alcanzarlo, reenvía el comando; si no, haz un restablecimiento de fábrica local. Si aparece FRP, necesitas una de las cuentas autorizadas en la política. Key topics: Estado intermedio tras desinscribir, Causas por modo de gestión, Reenvío de comandos y Duración, Estado BFU, Restablecimiento desde el modo de recuperación, Factory Reset Protection, Prevención, Applivery, Android, Android Device Policy, Android Management API, AOSP, Pushy Un dispositivo queda en un estado intermedio cuando la consola ya no lo gestiona, pero el dispositivo nunca recibió (o no pudo ejecutar) la orden de baja, y por eso conserva la política, las restricciones o los bloqueos. La causa más habitual es que el comando no llegó: dispositivo apagado o sin red, comando caducado o dispositivo bloqueado en estado BFU. Si todavía puedes alcanzar el dispositivo, reenvía el comando. Si no, la salida suele ser un restablecimiento de fábrica local, desde los ajustes o desde el modo de recuperación. Si después aparece la pantalla de FRP, necesitas una de las cuentas autorizadas en la política. ### Cómo reconocer un dispositivo en estado intermedio El dispositivo está en estado intermedio cuando coinciden dos cosas: 1. En el panel de Applivery, el dispositivo se ha desinscrito, se ha borrado o ya no responde a comandos. 2. En el dispositivo siguen activas las restricciones de la política: apps bloqueadas, ajustes inaccesibles, quiosco, bloqueo del restablecimiento de fábrica, etc. Antes de buscar la causa, recoge estos datos. Los necesitarás si escalas el caso a soporte: - **Modo de gestión** del dispositivo: totalmente gestionado, dedicado (quiosco), COPE, perfil de trabajo personal o AOSP. - **Último comando enviado**, con su fecha y su **Duración**, y el estado que muestra la pestaña **Comandos**. - Si el dispositivo está **encendido**, **tiene batería** y **tiene conexión**. - Si el dispositivo se **reinició** recientemente y está pidiendo el PIN al arrancar. - Si la política tenía configurados **Correos electrónicos del administrador Frp**. ### Causas posibles | # | Causa | Cómo identificarla | Modos afectados | |---|-------|--------------------|-----------------| | 1 | **El comando no llegó al dispositivo**: apagado, sin batería, sin red o fuera de cobertura. | El dispositivo no ha reportado desde hace tiempo y el comando sigue sin confirmarse. | Todos | | 2 | **El comando caducó.** Los comandos remotos llevan un parámetro **Duración** (en segundos) y expiran si el dispositivo no los ejecuta dentro de ese tiempo. | El comando aparece como expirado o sin ejecutar, y el dispositivo volvió a conectarse después. | Todos | | 3 | **Dispositivo en estado BFU (Before First Unlock).** Con `encryptionPolicy` en `ENABLED_WITH_PASSWORD`, tras un reinicio el dispositivo pide el PIN antes de descifrar el almacenamiento. Hasta entonces, el espacio de usuario de Android está congelado, incluido Android Device Policy, que es el componente que se comunica con Applivery. | El comando falla casi al instante aunque en el panel el dispositivo figure conectado a Wi-Fi. | Totalmente gestionado y dedicado | | 4 | **Dispositivo bloqueado con una contraseña desconocida.** El comando **Restablecer contraseña** no puede funcionar en un dispositivo ya bloqueado si no hay un token de restablecimiento activado. | Se necesita el PIN o el patrón y nadie lo conoce. | Totalmente gestionado | | 5 | **Dispositivo dedicado (quiosco) sin red al arrancar.** Sin conexión, el dispositivo no puede descargar la política ni recibir órdenes. | El dispositivo arranca en el quiosco y no consigue conectar. | Dedicado | | 6 | **Dispositivo AOSP que no recibe el comando.** En AOSP, los comandos se envían por Pushy (no por AMAPI) y los ejecuta el DPC de Applivery, que confirma la recepción y la finalización. | El comando no pasa de "enviado" y no hay confirmación de recepción. | AOSP | | 7 | **Restablecimiento de fábrica bloqueado por la política.** La política impide que el usuario restablezca el dispositivo desde los ajustes. | La opción de restablecer no está disponible o no tiene efecto. | Totalmente gestionado, dedicado y AOSP | | 8 | **Factory Reset Protection (FRP).** Si la política definía **Correos electrónicos del administrador Frp**, tras un restablecimiento forzado el dispositivo exige una de esas cuentas de Google para completar la configuración. | Aparece la pantalla de verificación de cuenta tras el reset. | Totalmente gestionado | | 9 | **Borrado por reglas de cumplimiento con Conservar Frp activado.** Si la **Acción de borrado** tiene **Conservar Frp** en `true`, los datos de FRP se conservan tras el borrado automático. | El dispositivo se borró por incumplimiento y ahora pide una cuenta de FRP. | Totalmente gestionado | :::info Un restablecimiento de fábrica no siempre se puede bloquear. En dispositivos COPE, ninguna solución EMM, incluida Applivery, puede deshabilitar el restablecimiento de fábrica, así que el usuario siempre conserva esa opción. Tienes más detalles en [Limitaciones de permisos COPE](https://docs.applivery.com/es/device-management/android/cope-permission-limits/). ::: ### Soluciones Empieza por la primera que aplique a tu caso. Van de menos a más destructiva: solo las últimas implican perder los datos del dispositivo. #### 1. Restablecer la conectividad y reenviar el comando Aplica a las causas 1, 2, 5 y 6. 1. Comprueba que el dispositivo está encendido, con batería y con conexión (Wi-Fi o datos móviles). 2. Si el dispositivo está en un quiosco sin red, usa el **Escape de red** si lo tienes habilitado en la política. Ofrece un acceso temporal de recuperación de red para actualizar la política; cuando se aplica, la red temporal se olvida y el arranque continúa con normalidad. Tienes más detalles en [Modo quiosco](https://docs.applivery.com/es/device-management/android/policies/kiosk-mode/). 3. Cuando el dispositivo vuelva a conectarse, reenvía el comando desde el botón **Acción** del dispositivo, desde su pestaña **Comandos** o desde **Ajustes → Zona de peligro**. Consulta [Comandos remotos](https://docs.applivery.com/es/device-management/android/commands/remote-commands/). 4. Pon en **Duración** un valor suficientemente largo para cubrir el tiempo que el dispositivo pueda tardar en volver a conectarse. No hay límite máximo. :::info En dispositivos [AOSP](https://docs.applivery.com/es/device-management/android/aosp/), si lo que necesitas es retirar la gestión sin borrar el dispositivo, usa el comando **Desenrolar**: elimina el DPC de Applivery como Device Owner y borra el estado almacenado del dispositivo. ::: #### 2. Dispositivos COPE: renunciar a la propiedad o restablecer desde el dispositivo Aplica a dispositivos COPE (Company-Owned, Personally Enabled). - Desde el panel, envía el comando **Renunciar a la propiedad** desde la pestaña **Comandos**. Elimina el perfil de trabajo y las políticas de gestión corporativa y conserva el contenido de los perfiles personales; el dispositivo pasa a comportarse como un Android estándar no gestionado. - Si el comando no llega, el usuario puede restablecer el dispositivo de fábrica desde sus propios ajustes. En COPE esa opción no se puede bloquear. #### 3. Dispositivo en estado BFU Aplica a la causa 3. **No existe una solución remota**, porque en BFU no hay ningún proceso capaz de recibir comandos. Hace falta acceso físico: 1. **Introducir el PIN en el dispositivo.** Si el usuario puede recordarlo, es la opción más sencilla. Al desbloquearlo, el dispositivo vuelve a recibir comandos y puedes reenviar el de baja o borrado. 2. **Restablecimiento de fábrica desde el modo de recuperación.** El dispositivo pierde todos los datos locales, pero vuelve a ser gestionable. Para que no se repita, usa `ENABLED_WITHOUT_PASSWORD` en `encryptionPolicy`: mantiene el cifrado pero no pide el PIN al arrancar. #### 4. Dispositivo bloqueado con contraseña desconocida Aplica a la causa 4. El comando **Restablecer contraseña** no puede funcionar sobre un dispositivo ya bloqueado con una contraseña desconocida. Es una limitación de la plataforma Android que afecta a cualquier MDM. 1. Comprueba si el bloqueo procede de **Find My Device** de Google, que permite establecer un PIN nuevo en remoto. 2. Si no es el caso, restablece el dispositivo de fábrica desde el modo de recuperación. #### 5. Restablecimiento de fábrica desde el modo de recuperación Es el recurso cuando el dispositivo no puede recibir comandos y nadie puede desbloquearlo. 1. Apaga el dispositivo. 2. Mantén pulsada la combinación de botones físicos del modelo para arrancar en el modo de recuperación. 3. Selecciona la opción de restablecimiento de fábrica y confirma. :::warning La combinación de botones y el aspecto del menú de recuperación dependen del fabricante y del modelo; consulta la documentación del fabricante. Este método **borra todos los datos locales** y, si la política tenía **Correos electrónicos del administrador Frp**, el dispositivo pedirá una de esas cuentas al terminar. ::: #### 6. El dispositivo pide una cuenta de Google tras el reset (FRP) Aplica a las causas 8 y 9. 1. Consulta qué cuentas estaban en **Correos electrónicos del administrador Frp** en la política que tenía asignada el dispositivo antes del reset (menú **Seguridad** de la política). 2. Pide a quien tenga una de esas cuentas que introduzca sus credenciales en la pantalla de FRP durante la configuración inicial. 3. Si ninguna de esas cuentas está disponible, la recuperación hay que gestionarla directamente con Google o con el fabricante. Applivery no dispone de un mecanismo remoto para omitir FRP una vez activada. :::warning FRP solo está activa en dispositivos gestionados vía AMAPI si la política define **Correos electrónicos del administrador Frp**. Si el campo estaba vacío o ausente, el dispositivo no ofrece protección de restablecimiento de fábrica. No aplica a perfiles de trabajo ni a COPE. Tienes más detalles en [Factory Reset Protection (FRP)](https://docs.applivery.com/es/device-management/android/policies/factory-reset-protection/). ::: #### Qué solución aplicar según el modo de gestión | Modo de gestión | Primera opción | Si no llega el comando | |-----------------|----------------|------------------------| | Totalmente gestionado | Reenviar el comando con una **Duración** mayor | PIN físico o restablecimiento desde el modo de recuperación; después, cuenta de FRP si procede | | Dedicado (quiosco) | Recuperar la red (**Escape de red**) y reenviar el comando | Restablecimiento desde el modo de recuperación; después, cuenta de FRP si procede | | COPE | **Renunciar a la propiedad** | Restablecimiento desde los ajustes del dispositivo (no se puede bloquear) | | AOSP | Comando **Desenrolar** | Restablecimiento desde el modo de recuperación | ### Prevención - **Usa `ENABLED_WITHOUT_PASSWORD` en `encryptionPolicy`.** Mantiene el cifrado completo pero no exige el PIN al arrancar, de modo que Android Device Policy arranca con normalidad tras un reinicio y los comandos remotos siguen funcionando. Consulta [Política de encriptación](https://docs.applivery.com/es/device-management/android/policies/encryption-policy/). - **Define al menos dos cuentas en Correos electrónicos del administrador Frp**, por ejemplo una cuenta de equipo y la de un responsable directo, para que un dispositivo no quede bloqueado si una cuenta deja de estar disponible. - **Revisa el proceso de baja de empleados** antes de activar FRP en dispositivos que se reasignan con frecuencia: sin él, un dispositivo puede quedar bloqueado a nombre de alguien que ya no está en la organización. - **Usa una Duración generosa** en los comandos de baja o borrado cuando el dispositivo pueda estar sin conexión. - **Antes de bloquear los cambios manuales o el restablecimiento de fábrica**, prueba la política en un grupo piloto y valida el flujo de baja completo, incluido qué ocurre si el comando no llega. - **Para borrados por incumplimiento**, comprueba el valor de **Conservar Frp** en la **Acción de borrado** antes de desplegar la regla. Consulta [Reglas de cumplimiento](https://docs.applivery.com/es/device-management/android/policies/enforcement-rules/). ### Si el problema continúa Si ninguna de las soluciones anteriores funciona, abre un caso con soporte e incluye: - Modo de gestión y versión de Android del dispositivo. - Identificador del dispositivo en Applivery y fecha del último reporte. - Último comando enviado, con su fecha, su **Duración** y el estado que muestra la pestaña **Comandos**. - Si el dispositivo se reinició y qué pantalla muestra (PIN, FRP, quiosco, ajustes). - Cuentas configuradas en **Correos electrónicos del administrador Frp**, si las había. --- ## Filtros URL Source: https://docs.applivery.com/es/device-management/android/troubleshooting/url-filtering/ Description: Referencia de sintaxis de filtros URL para las políticas URLBlocklist y URLAllowlist en Applivery: reglas de formato y ejemplos. TL;DR: Aprende a usar filtros URL con políticas URLBlocklist y URLAllowlist comprendiendo la sintaxis correcta y aplicando ejemplos prácticos. Answers: ¿Cómo funcionan los filtros URL? · ¿Qué es URLBlocklist? · ¿Qué es URLAllowlist? · ¿Cómo configurar filtros URL? · ¿Cuál es la sintaxis de los filtros URL? · ¿Cómo bloquear un sitio web con filtros URL? · ¿Cómo permitir un sitio web con filtros URL? · ¿Cuáles son las mejores prácticas para el filtrado URL? Key topics: Sintaxis de filtros URL, Políticas URLBlocklist, Políticas URLAllowlist, Control de acceso web, Aplicación de políticas de seguridad, URLBlocklist, URLAllowlist, HTTP, HTTPS, FTP Los filtros URL ofrecen a los administradores de IT herramientas eficaces para gestionar y controlar el acceso web de los dispositivos de su organización. Aplicando estas reglas, los administradores pueden garantizar el cumplimiento de las políticas de seguridad y los requisitos normativos, a la vez que permiten un uso de internet productivo y seguro. El formato para definir filtros en las políticas URLBlocklist y URLAllowlist sigue un patrón específico: `[scheme://][.]host[:port][/path][@query]` ### Componentes de un filtro URL 1. **Esquema (opcional)**: Especifica el protocolo usado en la URL. Puede ser `http`, `https`, `ftp`, `chrome`, etc., y debe ir seguido de '**://**'. 2. **Prefijo punto (opcional)**: Un '.' (punto) opcional puede preceder al campo host para desactivar la coincidencia con subdominios. 3. **Host (obligatorio)**: El campo host es obligatorio y representa un nombre de host válido o una dirección IP. También puede ser '**\***'. Los subdominios coinciden a menos que se deshabiliten con el prefijo punto. 4. **Puerto (opcional)**: Se puede especificar un puerto opcional tras el host. Debe ser un valor válido entre 1 y 65535. 5. **Ruta (opcional)**: Puede seguir al puerto opcionalmente, indicando una ubicación específica dentro del host. Se puede usar cualquier cadena en este campo. 6. **Consulta (opcional)**: Va al final del filtro URL, compuesta por pares clave-valor y tokens de solo clave delimitados por '&'. - Los tokens clave-valor se separan con '='. - Un token de consulta puede terminar con '\*' para indicar coincidencia de prefijo. - El orden de los tokens no se tiene en cuenta durante la coincidencia. ### Reglas y consideraciones especiales - La ruta y la consulta distinguen mayúsculas de minúsculas. - Los esquemas personalizados se admiten con patrones restringidos (`scheme:*` y `scheme://*`). - Si hay un separador de referencia '#', todo lo que va después se ignora. - Los filtros se seleccionan por la coincidencia más específica: - Se prefiere el host más largo. - Los filtros con esquema o puerto no coincidente se descartan. - Se selecciona la ruta más larga que coincida. - Se selecciona el conjunto de tokens de consulta más largo. - Si no se encuentra ningún filtro válido, se elimina el subdominio más a la izquierda del host y se intenta el filtrado de nuevo. - El host especial '\*' coincide con todos los hosts y se busca en último lugar. - Cuando se aplican filtros de bloqueo y de permitidos, la lista de permitidos tiene precedencia. - Los filtros con prefijo '.' solo coinciden con hosts exactos. ### Ejemplos - **\["example.com"\]**: Bloquea todas las solicitudes al dominio "example.com" y cualquier subdominio. - **\["http://example.com"\]**: Bloquea todas las solicitudes HTTP al dominio "example.com" y sus subdominios; otros esquemas (p. ej., HTTPS, FTP) siguen permitidos. - **\["mail.example.com"\]**: Bloquea las solicitudes al dominio "mail.example.com" pero no a "www.example.com" ni a "example.com". - **\[".example.com"\]**: Bloquea exactamente "example.com" sin bloquear subdominios. - **\["\*"\]**: Bloquea todas las solicitudes; solo se permitirán las URL de la lista de permitidos. - **\["\*:8080"\]**: Bloquea todas las solicitudes al puerto 8080. - **\["192.168.1.2"\]**: Bloquea las solicitudes a esta dirección IP exacta. :::tip Prueba siempre los filtros URL en un entorno de pruebas antes de desplegarlos en producción. ::: --- ## Apple Source: https://docs.applivery.com/es/device-management/apple/ Description: Gestión de dispositivos Apple con Applivery — inscribe, configura y protege dispositivos iOS, iPadOS y macOS a escala desde un panel centralizado. TL;DR: Applivery simplifica la gestión de dispositivos Apple proporcionando una plataforma centralizada para inscribir, configurar y proteger dispositivos iOS, iPadOS y macOS. Answers: ¿Qué es la Gestión de dispositivos Apple en Applivery? · ¿Qué dispositivos Apple puedo gestionar con Applivery? · ¿Qué puedo hacer con la Gestión de dispositivos Apple en Applivery? · ¿Cómo gestiono los dispositivos Apple en Applivery? · ¿Puedo aplicar políticas de seguridad en dispositivos Apple con Applivery? · ¿Puedo desplegar apps en dispositivos Apple con el MDM de Applivery? Key topics: Gestión de dispositivos Apple, Applivery, Inscripción de dispositivos, Políticas de seguridad, Apple, iOS, iPadOS, macOS Applivery es compatible con el MDM de Apple completo para iOS, iPadOS y macOS, lo que te permite inscribir, configurar y gestionar dispositivos Apple a escala. Puedes desplegar apps, aplicar políticas de seguridad, gestionar la supervisión, distribuir contenido y ejecutar comandos remotos — todo a través de las APIs MDM oficiales de Apple. La Gestión de dispositivos Apple en Applivery incluye configuración de la plataforma, métodos de inscripción, gestión de apps y políticas, comandos de dispositivo y resolución de problemas — organizado por plataforma (iOS/iPadOS y macOS). --- ## Gestión de apps Source: https://docs.applivery.com/es/device-management/apple/app-management/ Description: Applivery permite gestionar apps de Apple en dispositivos iOS, iPadOS y macOS. Implementa, configura, asigna licencias y aplica políticas desde un panel centralizado. TL;DR: Applivery centraliza la gestión de apps de Apple en iOS, iPadOS y macOS, simplificando la implementación y la aplicación de políticas. Answers: ¿Qué es la gestión de apps de Apple en Applivery? · ¿Qué pueden hacer los administradores con la gestión de apps de Apple de Applivery? · ¿Qué sistemas operativos Apple son compatibles con Applivery? · ¿Cuál es el principal beneficio de usar Applivery para la gestión de apps de Apple? · ¿Permite Applivery aplicar políticas de apps en dispositivos Apple? · ¿Cómo implementar apps en dispositivos iOS con Applivery? · ¿Cómo gestionar licencias VPP en Applivery? · ¿Cómo aplicar políticas de apps en macOS con Applivery? Key topics: Gestión de apps de Apple, Applivery, Licencias VPP, Implementación de apps, Políticas de apps, Apple, iOS, iPadOS, macOS, VPP La gestión de apps de Apple en Applivery te permite implementar, configurar y mantener apps en dispositivos iOS, iPadOS y macOS a escala. Puedes distribuir apps de forma silenciosa, asignar licencias VPP, gestionar configuraciones de apps y controlar el comportamiento de las apps mediante políticas. Los métodos de distribución de apps para plataformas Apple incluyen apps adquiridas a través de Apple Business (VPP), web clips, configuraciones de apps gestionadas y el bloqueo/permiso de apps. --- ## Bloquear y permitir apps Source: https://docs.applivery.com/es/device-management/apple/app-management/block-allow-apps/ Description: Bloquea o permite apps en dispositivos iOS y macOS a través de las políticas de Applivery — controla a qué apps pueden acceder los usuarios. TL;DR: Usa Applivery para controlar el acceso a apps en dispositivos iOS y macOS bloqueando apps no deseadas y permitiendo solo las aplicaciones aprobadas. Answers: ¿Qué es el bloqueo de apps en Applivery? · ¿Qué es el permiso de apps (lista blanca) en Applivery? · ¿Cómo permito una lista de apps para dispositivos iOS en Applivery? · ¿Cómo bloqueo una lista de apps para dispositivos iOS en Applivery? · ¿Cómo bloqueo una lista de apps para dispositivos macOS en Applivery? · ¿Por qué debo tener cuidado al bloquear apps del sistema en macOS? · ¿Puedo eliminar apps preinstaladas en macOS con Applivery? · ¿Dónde puedo encontrar el panel de Applivery? Key topics: Bloqueo de apps en iOS y macOS, Permiso de apps en iOS y macOS, Configuración del MDM de Applivery, Seguridad de dispositivos móviles, Políticas de gestión de aplicaciones, Applivery, iOS, macOS, Apple, Finder, Siri, VPP, App Store Tanto si quieres mejorar la seguridad como optimizar la productividad, la capacidad de gestionar qué aplicaciones pueden o no ejecutarse en los dispositivos inscritos es fundamental. Applivery admite dos enfoques: el bloqueo y el permiso de apps. - El **bloqueo de apps** consiste en la restricción selectiva de ciertas aplicaciones para que no se ejecuten en los dispositivos gestionados. Esto puede ser especialmente útil para mitigar riesgos de seguridad. Al crear una lista de bloqueo, los administradores pueden impedir que las apps especificadas se inicien, protegiendo así los datos sensibles. - Por otro lado, el permiso de apps, a menudo denominado **lista blanca**, se centra en permitir que solo un conjunto predefinido de aplicaciones funcione en los dispositivos inscritos. Este método se emplea cuando las organizaciones buscan optimizar la productividad asegurándose de que los usuarios solo tengan acceso a las herramientas esenciales. Al crear una lista blanca de apps, los administradores pueden garantizar que solo estén disponibles las aplicaciones aprobadas, minimizando las posibles vulnerabilidades de seguridad. ### Permitir una lista de apps para dispositivos iOS **Navegar a Políticas** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a cualquiera de tus **Políticas** 1. En el menú lateral izquierdo dirígete a **Apps** 2 y haz clic en el botón **\+ Añadir App** 3. ![add app](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/60758bac-26a3-4146-8d5a-7a02a4159e10.png) A través de cualquiera de las pestañas disponibles (App Store, Applivery), puedes buscar y añadir las aplicaciones que formarán parte de tu lista blanca de aplicaciones. Es necesario especificar si la aplicación está destinada a iOS o macOS. Además, deberás indicar si la app tiene una licencia VPP (más detalles disponibles [aquí](https://docs.applivery.com/es/device-management/apple/app-management/vpp/)). ![](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/730a96c8-fe28-4d49-9985-2f165114cfd0.png) **Configurar la lista de permiso** Deberás configurar el ajuste **Lista de permitidos / bloqueados**. En el menú lateral izquierdo, selecciona **\+ Añadir configuración** 4, elige **Restricciones** 5 y navega a la sección **Lista de permitidos / bloqueados** 6. ![allow list](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/a813ebcb-44ab-457a-8952-267fcb446afc.png) A continuación, selecciona **Permitir sólo algunas apps** 7 y añade las aplicaciones que se incluirán en esta lista. ![Apps in allow list](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/da8197f4-323a-496c-859d-4b081274ecd4.png) ### Bloquear una lista de apps para dispositivos iOS **Configurar la lista de bloqueo** Al igual que si estuvieras configurando una lista blanca de apps, ahora deberás seleccionar la opción **Apps no permitidas** 8. La app quedará bloqueada y los usuarios no podrán instalarla. ![block list of Apps](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/f1f5cf01-fa59-4f4c-a728-cff4ce0871ef.png) ### Bloquear una lista de apps para dispositivos macOS :::warning Ciertas apps del sistema, como Finder y Siri, se reinician automáticamente y permanecen abiertas en macOS. Como estas apps intentan abrirse continuamente, bloquearlas genera interminables ventanas emergentes de acceso bloqueado en el dispositivo. ::: :::warning Para bloquear aplicaciones en dispositivos macOS, el MDM de Applivery debe estar habilitado a nivel de política. ::: **Navegar a Políticas y Configuración del agente** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a cualquiera de tus **Políticas** 1. En el menú lateral izquierdo, dirígete a la sección **Agente** 2 y **actívalo** 3. ![enable agent](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/934274ea-4f07-4b42-8bbd-25d397a785fc.png) A continuación, podrás crear una lista de apps haciendo clic en el botón **\+ Añadir**. ![block list macos](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ad30d0cf-be80-4326-8864-10baea8d3b05.png) :::warning Muchas apps preinstaladas se encuentran en el [volumen del sistema firmado](https://support.apple.com/en-gb/guide/security/secd698747c9/web), lo que hace imposible eliminarlas. Sin embargo, puedes eliminarlas del Dock mediante una política, y si un usuario intenta abrir una, una alerta le notificará que la app no se puede iniciar. ::: :::info Bloquear una app y bloquear su sitio web son controles distintos, y un servicio solo queda realmente fuera de alcance cuando haces las dos cosas. Para la parte web, consulta [Bloquear o permitir URLs en Safari](https://docs.applivery.com/es/device-management/apple/ios-ipados/policies/web-content-filter/) en iPhone y iPad, y [Bloquear o permitir URLs en Chrome y Safari](https://docs.applivery.com/es/device-management/apple/macos/policies/block-allow-urls-chrome-safari/) en Mac. ::: --- ## Gestión de apps Source: https://docs.applivery.com/es/device-management/apple/app-management/manage-apps/ Description: Gestiona apps de la App Store de Apple, VPP y apps internas en iOS/macOS con Applivery. Aprende sobre despliegue, configuración y actualizaciones remotas. TL;DR: Aprende a gestionar apps de Apple (App Store, VPP, internas) en iOS/macOS con Applivery MDM, incluyendo despliegue, configuración y scripts. Answers: ¿Qué tipos de apps se pueden gestionar en Applivery para dispositivos Apple? · ¿Cómo instalar apps internas en dispositivos Apple con Applivery? · ¿Qué son las apps personalizadas en el ecosistema Apple? · ¿Qué es el Programa de compras por volumen Apple (VPP)? · ¿Cuáles son las opciones de presentación de una app tras la instalación? · ¿Qué son los scripts de pre- y post-instalación para apps internas en Applivery? · ¿Para qué sirve el catálogo de apps de Applivery para macOS? · ¿Qué funciones de gestión de apps requieren el modo supervisado en dispositivos Apple? Key topics: Gestión de apps de la App Store de Apple, Integración del Programa de compras por volumen Apple (VPP), Distribución de apps internas con Applivery, Gestión de apps macOS y scripts, Gestión de dispositivos Apple supervisados y no supervisados, Apple, Applivery, iOS, macOS, App Store de Apple, Programa de compras por volumen Apple (VPP), MDM, archivos .ipa, Apple Business Antes de empezar, describamos todos los tipos de apps que puedes encontrar en el ecosistema Apple: ### Apps de la App Store de Apple Los administradores de Applivery pueden enviar remotamente apps de la App Store de Apple a dispositivos Apple gestionados. Requiere que la app esté disponible en la App Store y que el usuario inicie sesión con su cuenta de Apple ID para aceptar la instalación. En [dispositivos supervisados](https://docs.applivery.com/es/device-management/apple/supervision/), las apps se pueden instalar silenciosamente en segundo plano sin la aceptación del usuario. Hay 4 tipos principales de apps que se pueden desplegar en dispositivos Apple: - **Apps gratuitas:** Disponibles públicamente en la App Store y gratuitas para descargar. - **Apps de pago:** Disponibles públicamente en la App Store pero no gratuitas; requieren compra. - **Apps personalizadas:** Creadas por empresas para uso interno o distribución privada. Estas apps deben subirse a la App Store de Apple como **apps personalizadas** y gestionarse a través de Apple Business. - **Apps aún no disponibles en la App Store** (principalmente para dispositivos macOS). Hay tres tipos de instalación disponibles para las aplicaciones: - **Instalación forzada**: La app se instalará de forma forzada. - **Requerida para la configuración**: La app se instalará automáticamente y el usuario no podrá eliminarla. Impedirá que se complete la configuración hasta que la instalación esté terminada. - **Disponible**: La app estará disponible para instalarse bajo demanda, ya sea desde el panel o usando la app de Self-Service en dispositivos macOS. Además, podrás crear un diccionario de configuración para la app. ### Apps adquiridas a través del Programa de compras por volumen Apple (VPP) Adicionalmente, Apple ofrece el Programa de compras por volumen para comprar licencias de apps y libros, e instalar apps privadas de empresa en dispositivos Apple gestionados con iOS y macOS. Puedes obtener más información sobre el VPP de Apple [aquí.](https://docs.applivery.com/es/device-management/apple/app-management/vpp/) ### Distribución interna (archivos .ipa) - **Apps Enterprise:** Estas apps están firmadas con un certificado de desarrollador empresarial de Apple, diseñado para uso interno y distribución interna. Típicamente, se distribuyen a través de métodos alternativos como la Distribución de Apps de Applivery o se despliegan en dispositivos mediante un MDM como la Gestión de Dispositivos de Applivery para dispositivos Apple. Vale la pena señalar que Apple está eliminando gradualmente este método de distribución en favor de las apps personalizadas. - **Apps AdHoc:** Este tipo menos común de app se suele crear para pruebas y distribución interna únicamente. Están restringidas a un conjunto definido de dispositivos mediante la inclusión de sus UDIDs en el perfil de aprovisionamiento. #### Cómo instalar apps internas **Instalar a nivel de dispositivo** La app se instalará en los dispositivos de destino individuales. - **Asignar una build de una app** haciendo clic en el botón **\+ Asignar App** 1. - **Instalar un archivo** `.ipa`: Haciendo clic en el botón **Instalar desde archivo** 2, puedes seleccionar un archivo `.ipa` subido previamente a la sección **Recursos** o instalarlo directamente desde tu dispositivo con el botón **Cargar nuevo recurso**. ![app device level](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ce886419-4da9-47c5-bd94-fdf39f82b5cb.png) :::info Si quieres saber cómo instalar archivos `.pkg` en tus dispositivos macOS, consulta nuestra [documentación](https://docs.applivery.com/es/device-management/apple/macos/app-management/pkg-deployment/) detallada. ::: **Instalar a nivel de política** La app o apps se instalarán en todos los dispositivos asociados a una política específica. Una vez en el [**panel de Applivery**](https://dashboard.applivery.io), te a cualquiera de tus políticas 1. En el menú lateral izquierdo, dirígete a **Apps** 2 y haz clic en el botón **\+ Añadir App** 3. ![add app](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/0d4412fb-9016-44f9-9854-5cd4dd5216bb.png) Localiza la pestaña **Applivery** 4, luego selecciona **Tu Workspace** 5 como origen de la app. ![app from your Workspace](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/aee672dc-77c5-4edb-a15e-b6beb9334d10.png) **Instalar desde el catálogo de apps de Applivery para macOS** Diseñado para apps no disponibles en la Mac App Store, estas se pueden añadir seleccionando **App Catalog** como origen de la app. Para más detalles, consulta nuestra documentación detallada [aquí](https://docs.applivery.com/es/device-management/apple/macos/app-management/app-catalog/). ![Apps from app catalog](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/f2f51598-a224-42db-90aa-a0dc2bae972e.png) #### Scripts de pre- y post-instalación para apps internas ![scripts-in-house-Apps](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/cf079682-79de-485f-b204-a04fe89585a0.png) Para dispositivos macOS, puedes incluir scripts de pre- y post-instalación para apps internas específicas (disponibles en la pestaña Applivery, ya sea desde **Tu Workspace** o el [**App Catalog**](https://docs.applivery.com/es/device-management/apple/macos/app-management/app-catalog/)). Estos scripts se pueden cargar al añadir la app, ya sea a nivel de política o de dispositivo. Sin embargo, no serán visibles en la sección Recursos y solo serán accesibles dentro de la app específica asociada al script. - Si la app se ha asignado a un dispositivo específico, navega al dispositivo, dirígete a la sección **Apps**, localiza la app, haz clic en el botón de tres puntos verticales **(⋮)** y selecciona **Editar**. - Si la app se instaló a través de una política, navega a la política y selecciona la sección **Apps** en el menú lateral izquierdo. Localiza la app y haz clic en el icono de Configuración en la sección **Origen** de la app. ![app install scripts](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/8a42de87-749e-46ca-9512-0b6893c1d765.png) Se pueden añadir los siguientes tipos de scripts a una app: - **Script de verificación**: Comprueba si la app debe instalarse de nuevo. - **Script de auditoría**: Comprueba si la app puede instalarse. - **Pre-script**: Ejecuta acciones antes de la instalación de la app. - **Post-script**: Ejecuta acciones después de la instalación de la app. ### Gestión de apps Ahora que tenemos una visión más clara de los diferentes tipos de apps, veamos las principales capacidades de gestión de apps que encontrarás en Applivery y algunos requisitos que debes tener en cuenta según si los dispositivos de destino están [supervisados](https://docs.applivery.com/es/device-management/apple/supervision/) o no: | Función | Modo supervisado ACTIVADO | Modo supervisado DESACTIVADO | | --- | --- | --- | | Desplegar apps | ✅ | ✅ | | Desplegar apps de pago | ✅ | ✅ | | Desplegar apps silenciosamente | ✅ | ❌ Requiere inicio de sesión con Apple ID | | Configurar apps de forma remota | ✅ | ✅ | | Actualizar apps de forma remota | ✅ | ✅ | | Desinstalar apps de forma remota | ✅ | ✅ | --- ## VPP Source: https://docs.applivery.com/es/device-management/apple/app-management/vpp/ Description: Applivery permite gestionar licencias de apps y libros con el programa de compras por volumen (VPP) de Apple, simplificando el despliegue en dispositivos iOS y macOS. TL;DR: El programa de compras por volumen (VPP) de Apple simplifica la gestión de licencias de apps y libros para dispositivos iOS y macOS, y Applivery agiliza el proceso de configuración y despliegue. Key topics: Programa de compras por volumen (VPP) de Apple, Integración con Applivery, Métodos de asignación de apps, Apple Business, Gestión de licencias, Apple, Applivery, iOS, macOS, VPP La gestión de apps y libros con licencia en nombre de tus usuarios y dispositivos gestionados implica a Apple para el proceso de compra a través de [Apple Business](https://business.apple.com/) (incluso para apps y libros gratuitos si deseas controlar el número de unidades distribuidas a tus usuarios). Una vez compradas, estas apps y libros pueden gestionarse desde el panel de Applivery y asignarse a usuarios y dispositivos registrados por su número de serie de dispositivo o a la lista completa de dispositivos registrados para un usuario determinado. Después de que se hayan asignado las licencias, los administradores pueden desplegar apps y libros en un dispositivo o en un conjunto de dispositivos. :::info Una vez que la empresa posee las licencias de apps VPP, estas pueden asignarse, revocarse y reasignarse a usuarios o dispositivos en cualquier momento. Esto elimina la necesidad de una cuenta de Apple ID compartida y, si se desea, la necesidad de que un empleado utilice un Apple ID en el dispositivo. ::: ### Cuando una licencia no se asigna Un error `ASDServerErrorDomain` con código **9610** viene del lado de Apple y significa que la licencia de VPP no se ha encontrado. La causa habitual es un **token de VPP compartido entre varios MDM**. Cada uno mantiene su propia visión de qué licencias están asignadas, las dos se desincronizan, y Apple acaba rechazando una asignación que Applivery cree seguir teniendo. Usa un token por MDM. ### VPP no requiere que el dispositivo esté en Apple Business Es fácil leer Apple Business como una sola cosa. Son dos funciones independientes que comparten portal, y solo a una le importa tu inventario de dispositivos.

Función

Qué gestiona

¿El dispositivo tiene que estar en Apple Business?

Automated Device Enrollment

Inventario de dispositivos e inscripción automática

Sí

Apps and Books (VPP)

Licencias compradas por la organización

No

El token de VPP está vinculado a una **ubicación de la organización**, no a un conjunto de dispositivos. En la asignación por dispositivo, el MDM envía el número de serie al servicio de VPP y Apple registra la licencia contra él sin comprobar el inventario de Automated Device Enrollment. Así que un iPad preparado con Apple Configurator, supervisado e inscrito, recibe apps de VPP aunque nunca se haya añadido a Apple Business. :::info **La supervisión tampoco habilita VPP.** Lo que aporta la supervisión es que la instalación sea silenciosa, sin intervención del usuario. ::: ### Métodos de asignación Existen 3 formas principales de asignar apps o libros: - **Asignación basada en dispositivos**: Con la asignación basada en dispositivos, las licencias de apps se asignan a un dispositivo por número de serie en lugar de a un Apple ID. Se asignará una licencia por cada dispositivo en el que se instale la app. Con este método, las apps permanecerán en los dispositivos independientemente del Apple ID en uso, si lo hubiera. En dispositivos iOS supervisados, este método permite que las apps se instalen sin solicitar ni notificar al usuario. Las empresas que buscan un proceso de despliegue Zero-Touch encontrarán esto particularmente beneficioso. - **Asignación basada en usuarios**: Cuando las apps VPP se despliegan con asignación basada en usuarios, se pedirá a los usuarios del dispositivo que introduzcan un Apple ID si aún no hay uno presente en el dispositivo y se les invitará a unirse al programa VPP de la empresa. Aunque esto requiere más interacción del usuario que el licenciamiento basado en dispositivos, es útil en situaciones en las que un único usuario utilizará múltiples dispositivos. La licencia de la app se habilita automáticamente en todos los dispositivos que utilizan el mismo Apple ID. Como resultado de este proceso, solo se utilizará una única licencia del número total disponible en la cuenta VPP. - **Códigos de canje**: Las licencias de apps pueden distribuirse a Apple ID utilizando códigos de canje, donde un código puede canjearse una vez por un Apple ID para una licencia de app específica. Se pedirá a los usuarios que introduzcan un código para canjear la compra y completar la instalación de la app. Después de introducir el código de canje, la propiedad de la licencia de la app se transfiere permanentemente al ID de ese usuario. Estos códigos se entregan en formato de hoja de cálculo y pueden distribuirse a los usuarios a través de varios métodos, incluyendo: asignarlos a través de Applivery, enviar una URL por correo electrónico, asignarlos a dispositivos a través de Apple Configurator o proporcionar los códigos a los usuarios manualmente. Cuando se utilizan con Applivery, Applivery canjeará automáticamente los códigos para los usuarios cuando se instalen las apps. ### Cómo configurar el programa de compras por volumen (VPP) de Apple en Applivery Applivery proporciona una integración perfecta con el programa de compras por volumen (VPP) de Apple para la compra de licencias de apps y libros y la instalación de apps privadas de la empresa en dispositivos Apple gestionados con iOS y macOS. 1. Ya tienes una cuenta aprobada de [Apple Business](https://business.apple.com/) para tu organización. 2. Tienes una licencia activa de gestión de dispositivos Apple de Applivery. Si ese es el caso, los siguientes pasos son: **Obtén tu token de Apple Business** Inicia sesión en [Apple Business](https://business.apple.com/) como un usuario con el rol de Administrador o Gestor de Contenido. Abre el **menú desplegable de tu organización**, selecciona **Ajustes** 1 y, en el menú de la izquierda, haz clic en **Unidades organizativas** 2. Luego haz clic en **Añadir** 3 para empezar a crear tu ubicación VPP. ![create organisational units](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/33ddd1cd-11a7-43d9-a921-46cb52245550.png) Una vez creada, navega a la sección **Pagos y facturación** 4. En **Tokens de contenido**, descarga el token 5 para la Unidad organizativa que acabas de crear. ![content tokens](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/cd331e67-5688-4de2-8790-229a377e8325.png) :::info Apple proporciona un sistema de tokens basado en ubicaciones. Si necesitas configurar una nueva ubicación, dirígete a **Ubicaciones** y haz clic en **Añadir nueva ubicación**. ::: **Configura VPP en Applivery** Desde el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a la sección **Configuración** 1 y localiza **Apple VPP** 2 en el menú de la izquierda. Haz clic en el botón **Gestionar ubicaciones** y luego en **\+ Asociar ubicación** y sube el token descargado del paso anterior (`.vpptoken`). ![vpp location](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ab95c84c-f295-47e5-9844-3f1efb00ae82.png) Finalmente, haz clic en **Guardar** para terminar. Se creará el nuevo token. **Obtén o compra licencias de apps o libros en Apple Business** Compra las licencias necesarias a través del portal de Apple Business. **Sincroniza las licencias compradas en Applivery** Sincroniza las licencias dentro del panel de Applivery para reflejar las compras realizadas en Apple Business. **Despliega apps con licencia en dispositivos** Despliega las licencias compradas y sincronizadas en los dispositivos gestionados a través del panel de Applivery. --- ## Web Clips Source: https://docs.applivery.com/es/device-management/apple/app-management/web-clips/ Description: Crea y configura Web Clips en dispositivos iOS y macOS con Applivery. Agiliza el acceso a sitios web, personaliza el diseño de la pantalla de inicio y gestiona el acceso. TL;DR: Crea y configura Web Clips en iOS y macOS con Applivery para acceso rápido a sitios web y diseños de pantalla de inicio personalizados, incluyendo opciones de listas blancas. Answers: ¿Qué es un Web Clip en Applivery? · ¿Cómo crear un Web Clip en Applivery? · ¿Qué campos obligatorios se requieren al crear un Web Clip? · ¿Cómo personalizar la posición de un Web Clip en la pantalla de inicio? · ¿Qué sucede si no personalizo el diseño de la pantalla de inicio? · ¿Puedo reorganizar Web Clips y apps en la pantalla de inicio? · ¿Cuál es la diferencia entre una lista blanca y una lista de bloqueo para Web Clips? · ¿Cómo añadir Web Clips a una lista blanca o lista de bloqueo? Key topics: Creación de Web Clips, Personalización del diseño de la pantalla de inicio, Gestión de Web Clips, Configuración de Applivery, Applivery, Web Clips, iOS, macOS, iPhone, iPad, Apple Applivery agiliza y automatiza la creación de Web Clips, accesos directos a sitios web en dispositivos Apple. Los Web Clips se pueden añadir a la pantalla de inicio de dispositivos iPhone y iPad, así como a ordenadores Mac para usuarios individuales, ofreciendo un acceso rápido a páginas web o enlaces favoritos. Para obtener más información sobre este tema, puedes encontrar información adicional [aquí](https://support.apple.com/en-gb/guide/deployment/depbc7c7808/web). ### Crear y configurar Web Clips **Navegar a políticas** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io), navega a cualquiera de tus **Políticas** 1. Desde el menú lateral izquierdo, selecciona la sección **\+ Añadir configuración** y elige **Web Clip** 2. ![web clip](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/0cfe08aa-7d6b-42c6-8a83-f9beb9edd88f.png) **Añadir configuración de Web Clip** Deberás definir campos obligatorios como la **etiqueta** y la **URL del enlace web**. Además, puedes personalizar la imagen que aparecerá en los dispositivos y aplicar configuraciones adicionales. ![web clip configuration](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/865da68e-207e-436e-b4ef-f803df792b29.png) ### Personalizar el diseño de la pantalla de inicio **Acceder a la configuración del diseño de la pantalla de inicio** Si no personalizas el diseño de la pantalla de inicio de tu dispositivo, los Web Clips se colocarán en la última pantalla, utilizando los espacios disponibles después de todas las apps instaladas. Alternativamente, tienes la opción de personalizar el diseño de la pantalla de inicio de tu dispositivo accediendo de nuevo a **\+ Añadir configuración** y seleccionando **Diseño de la pantalla de inicio** 3 para una disposición más personalizada de Web Clips y apps. ![home screen layout](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/26012923-48a8-4c72-935a-f26041dc4804.png) **Configurar la posición del Web Clip** Dentro de esta sección, puedes determinar la posición en la pantalla para mostrar tu Web Clip. Haz clic en el área **+** 4, selecciona la sección **WebClip** 5 y elige un Web Clip configurado de la lista o crea uno nuevo. ![web clips in home screen layout](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/a1417944-3047-42ef-981c-c9bb39685f53.png) **Reorganizar y editar propiedades del Web Clip** Si quieres crear una disposición personalizada, puedes reorganizar fácilmente las posiciones de apps, Web Clips o carpetas haciendo clic y arrastrando un elemento a la ubicación deseada. Las apps restantes se alinearán automáticamente después de estos ajustes. Una vez que hayas añadido el Web Clip deseado, tendrás la opción de editar sus propiedades dentro de esta sección. Si necesitas configurar Web Clips adicionales, puedes generar fácilmente nuevos seleccionando **crear uno nuevo**. ### Añadir Web Clips a la lista blanca o lista de bloqueo Habilitar una **lista blanca** implica permitir solo apps o Web Clips específicos mientras se restringe el acceso a todos los demás. Al crear una lista blanca, estableces un conjunto predefinido de fuentes confiables y aprobadas a las que los usuarios pueden acceder sin restricciones. De manera similar, habilitar una **lista de bloqueo** impide el acceso a apps o Web Clips específicos mientras permite todos los demás, ayudándote a restringir contenido no deseado sin limitar la funcionalidad general del dispositivo. Para configurar cualquiera de las listas, sigue los pasos descritos en nuestra documentación [aquí](https://docs.applivery.com/es/device-management/apple/app-management/block-allow-apps/). --- ## Comandos Source: https://docs.applivery.com/es/device-management/apple/apple-commands/ Description: Comandos de gestión de dispositivos Apple en Applivery: envía acciones en tiempo real a dispositivos iOS, iPadOS y macOS desde un panel centralizado. TL;DR: Envía acciones puntuales y en tiempo real a dispositivos Apple inscritos desde el panel de Applivery. Answers: ¿Qué son los comandos de Apple en Applivery? · ¿Cómo envío un comando a un dispositivo Apple? · ¿Cuál es la diferencia entre un comando y una política? · ¿Qué comandos de Apple admite Applivery? Key topics: Comandos de Apple, Acciones remotas sobre dispositivos, Gestión de dispositivos, Applivery, Apple, iOS, iPadOS, macOS Los comandos de Apple en Applivery te permiten actuar sobre un dispositivo inscrito en el momento, sin esperar a que sincronice una política. Desde la pestaña **Comandos** de la ficha de cualquier dispositivo puedes enviar una acción puntual y ver su resultado en el panel. Estos comandos funcionan en todas las plataformas Apple. Los comandos exclusivos de una plataforma están en las secciones de iOS/iPadOS y macOS. --- ## Aplicaciones predeterminadas Source: https://docs.applivery.com/es/device-management/apple/apple-commands/default-applications/ Description: Envía un comando a dispositivos Apple para fijar qué app usa el sistema por defecto para llamadas, mensajería y navegación web. TL;DR: Envía el comando Configuraciones desde la ficha de un dispositivo Apple para fijar las apps predeterminadas de llamadas, mensajería y navegador por bundle identifier. Calling y Messaging requieren iOS/iPadOS 26.0+; Web Browser llega a versiones anteriores. Answers: ¿Se puede establecer un navegador predeterminado distinto de Safari en dispositivos Apple mediante Applivery? · ¿Cómo se configura la app de llamadas o mensajería predeterminada en dispositivos Apple? · ¿Qué versiones de iOS, iPadOS y macOS soportan esta configuración? · ¿Se puede impedir que el usuario cambie la app predeterminada después de aplicar el comando? Key topics: Comando Default Applications, Bundle identifiers, Restricciones en dispositivos supervisados, Requisitos y resolución de problemas, Applivery, Apple, iOS, iPadOS, macOS, APNs En las plataformas de Apple, qué app responde una llamada, abre un mensaje o gestiona un enlace ha sido siempre decisión del usuario. Applivery te permite tomar esa decisión por él: desde la ficha del dispositivo puedes enviar un comando que fija la app predeterminada para **llamadas**, **mensajería** y **navegación web**, indicando el bundle identifier de cada app. Es un comando puntual, no una política persistente. Fija las predeterminadas en el momento en que lo envías. ### Enviar el comando **Abre el dispositivo** En el [**panel de Applivery**](https://dashboard.applivery.io), ve a **Dispositivos** 1 y abre la ficha del dispositivo Apple que quieres configurar. **Crea un comando nuevo** Selecciona la pestaña **Comandos** 2 y haz clic en **\+ Nuevo comando** 3. ![commands](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/f26dea33-bb93-4dd1-aa6a-397ab70404b2.png) **Elige Configuraciones** En el listado de comandos disponibles, selecciona **Configuración** y, posteriormente, selecciona **Aplicaciones por defecto**. **Revisa los campos disponibles** El panel que se abre muestra tres campos, cada uno con las plataformas y versiones mínimas que admite. ![default apps](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/2ec7b83c-119a-4590-8cbc-2ac1e5b2ca28.png)

Campo

Qué hace

Compatibilidad mínima mostrada

Llamando a

Bundle identifier de la app que el sistema usa como app de llamadas por defecto. Tiene que ser una app elegible para llamadas.

iOS/iPadOS 26.0

Mensajería

Bundle identifier de la app que el sistema usa como app de mensajería por defecto. Tiene que ser una app elegible para mensajería.

iOS/iPadOS 26.0

Navegador web

Bundle identifier de la app que el sistema usa como navegador web por defecto. Tiene que ser una app de navegador elegible para la región del dispositivo.

iOS/iPadOS, macOS (10.12 Sierra+), tvOS, watchOS, visionOS

:::info Solo necesitas rellenar el campo que quieras configurar. Los tres son independientes entre sí. ::: **Introduce el bundle identifier** Escribe el **bundle identifier** de la app de destino en el campo correspondiente. Algunos valores habituales para el campo Web Browser:

Navegador

Bundle ID (iOS/iPadOS)

Safari

com.apple.mobilesafari

Google Chrome

com.google.chrome.ios

Microsoft Edge

com.microsoft.msedge

Firefox

org.mozilla.ios.Firefox

**Envíalo** Haz clic en **Enviar** para enviar el comando al dispositivo. :::warning La app de destino tiene que estar **instalada** en el dispositivo antes de enviar el comando, y tiene que ser capaz de manejar el tipo de contenido correspondiente: llamadas, mensajería o esquemas `http` y `https`, según el campo. Esa validación la aplica el propio sistema operativo, no Applivery. Lo más seguro es añadir la app a la política como instalación forzada. ::: ### Cómo funciona a nivel de Apple Este comando se corresponde con el comando MDM nativo de Apple `Settings` con el ítem `DefaultApplications`, que Apple introdujo en su protocolo MDM para poder fijar apps predeterminadas de forma remota. A diferencia de las configuraciones que se despliegan como perfiles (un `.mobileconfig` con su `PayloadType`), este es un **comando puntual** enviado vía APNs. No queda nada instalado en el dispositivo como perfil persistente. #### Impedir que el usuario vuelva a cambiar el navegador El comando fija el navegador predeterminado en el momento de enviarlo, pero el usuario puede volver a cambiarlo desde **Ajustes > Apps > Apps predeterminadas**. Para impedirlo, Apple expone una restricción adicional dentro de la carga útil `com.apple.applicationaccess`: ```xml allowDefaultBrowserModification ``` ![allow browser modification](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/fce0ac31-1ad6-41ce-92c0-06a317206060.png) :::warning Esta restricción solo tiene efecto en **dispositivos supervisados**. En dispositivos no supervisados el comando para fijar el navegador funciona igualmente, pero el usuario siempre podrá cambiarlo después. ::: ### Requisitos

Requisito

Detalle

Versión mínima de SO — Llamando a y Mensajería

iOS/iPadOS 26.0 o superior

Versión mínima de SO — Navegador web

iOS/iPadOS, macOS 10.12 Sierra o superior, tvOS, watchOS, visionOS. Consulta el panel del comando para el detalle exacto por plataforma.

App instalada

La app de destino tiene que estar instalada en el dispositivo antes de enviar el comando

Mecanismo

Un comando enviado desde la ficha del dispositivo, no un perfil de configuración persistente

Conectividad

El dispositivo tiene que estar en línea y responder para recibir el comando

### Resolución de problemas

Situación

Causa probable

El comando se envía pero la app predeterminada no cambia

La app de destino no está instalada, o su bundle ID no coincide exactamente con el registrado en la App Store

El campo Calling o Messaging no tiene efecto

El dispositivo tiene una versión de iOS/iPadOS anterior a la 26.0

El comando no llega al dispositivo

El dispositivo está offline o no responde al MDM en el momento del envío

--- ## Apple MDM Source: https://docs.applivery.com/es/device-management/apple/apple-mdm/ Description: Apple MDM con Applivery — visión general de Apple Business, DEP, VPP, supervisión y fundamentos de la gestión de dispositivos iOS/macOS. TL;DR: Esta guía introduce los conceptos de gestión de dispositivos Apple como Apple Business, DEP y VPP, explicando cómo funcionan con Applivery para simplificar el despliegue de dispositivos Apple. Answers: ¿Qué es Apple Business? · ¿Cómo funciona el DEP? · ¿Qué es el Programa de Compra por Volumen? · ¿Qué es el modo de supervisión en el MDM de Apple? · ¿Cómo inscribir dispositivos con Apple Configurator? · ¿Cómo se integra Applivery con el MDM de Apple? · ¿Cuáles son los beneficios de usar Apple Business? Key topics: Apple Business, Programa de inscripción de dispositivos (DEP), Programa de compra por volumen (VPP), Modo de supervisión, Apple Configurator, Apple, Applivery, Programa de inscripción de dispositivos, Programa de compra por volumen, iOS, tvOS, macOS ### Visión general de la gestión de dispositivos Apple Apple dispone de un conjunto de programas y soluciones creados para simplificar y agilizar la configuración de los dispositivos, así como el despliegue de aplicaciones y contenido. ### Dispositivos compatibles La gestión de dispositivos Apple en Applivery cubre todos los tipos de dispositivos Apple: - iPhones. - iPads. - MacBooks e iMacs. - Apple TV. - Apple Watch. ### Apple Business [Apple Business](https://business.apple.com/) es un portal web para administradores de TI que permite desplegar iPhone, iPad, iPod touch, Apple TV y Mac desde un único lugar. Trabajando a la perfección con otras soluciones MDM como Applivery, Apple Business facilita la automatización del despliegue de dispositivos, la compra de apps y la distribución de contenido, así como la creación de Apple IDs gestionados para los empleados. El [Programa de inscripción de dispositivos (DEP)](https://docs.applivery.com/es/device-management/apple/enrollment/dep/) y el [Programa de compra por volumen (VPP)](https://docs.applivery.com/es/device-management/apple/app-management/vpp/) están completamente integrados en Apple Business, por lo que las organizaciones pueden reunir todo lo necesario para desplegar dispositivos Apple. ![apple mdm](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/5e4fe867-0824-4dd5-888e-b4a2c656b0c0.png) :::warning **Las cuentas gestionadas de Apple no admiten añadir tarjetas de pago a Wallet.** Activar Wallet en Apple Business permite que la aplicación se abra, pero no habilita añadir tarjetas, ni manualmente ni mediante la interfaz de "añadir a Wallet". Las credenciales de empleado y las identificaciones sí funcionan. ::: #### Programa de inscripción de dispositivos (DEP) El Programa de inscripción de dispositivos Apple (también conocido como **DEP**) es una herramienta integrada en Apple Business que permite a las organizaciones automatizar completamente el proceso de inscripción de dispositivos Apple en soluciones MDM como Applivery. En sus inicios, se centraba en los nuevos dispositivos, pero a partir de iOS 11, también admite la inscripción de dispositivos ya adquiridos. El DEP ayuda a las organizaciones a activar la supervisión, la inscripción en MDM, omitir pasos de configuración y muchas otras funciones. Puedes obtener más información sobre Apple DEP [aquí](https://docs.applivery.com/es/device-management/apple/enrollment/dep/). #### Programa de compra por volumen (VPP) El Programa de compra por volumen Apple (también conocido como **VPP**) es otra herramienta integrada en Apple Business que permite a las organizaciones automatizar la compra de licencias de apps y libros. Una vez adquiridas, estas apps y libros pueden gestionarse desde el panel de Applivery y asignarse a usuarios y dispositivos registrados por el número de serie del dispositivo o a toda la lista de dispositivos registrados para un usuario determinado. Tras asignar las licencias, los administradores pueden desplegar apps y libros en un dispositivo o en un conjunto de dispositivos. Puedes obtener más información sobre Apple VPP [aquí](https://docs.applivery.com/es/device-management/apple/app-management/vpp/). ### Otros conceptos importantes #### Modo de supervisión Algunos dispositivos Apple (iOS y tvOS) pueden configurarse en un modo especial llamado **modo supervisado** que otorga a los MDM un control adicional sobre los dispositivos con privilegios avanzados sobre apps, modo de bloqueo, contenido web y muchas otras funciones. El modo de supervisión requiere un restablecimiento de fábrica o dispositivos nuevos configurados mediante Apple Configurator o el Programa de inscripción de dispositivos Apple (DEP). Puedes obtener más información sobre qué es la supervisión y cómo activar el modo de supervisión [aquí](https://docs.applivery.com/es/device-management/apple/supervision/). #### App Apple Configurator Apple proporciona dos apps que te ayudarán a aprovechar el Programa de inscripción de dispositivos Apple registrando tus dispositivos en tu cuenta de Apple Business. - [**Apple Configurator (para Mac)**](https://apps.apple.com/app/id1037126344) es una app de macOS que facilita el despliegue de dispositivos iPad, iPhone, iPod touch y Apple TV en tu colegio o empresa. Registra automáticamente tus dispositivos en Applivery y en tu cuenta de Apple Business. - [**Apple Configurator (para iPhone)**](https://apps.apple.com/us/app/apple-configurator/id1588794674) es una app que facilita la asignación de cualquier Mac con chip de seguridad T2 o Apple Silicon a tu organización de Apple Business y su gestión a través de Applivery. Puedes obtener más información sobre ambas apps [aquí](https://docs.applivery.com/es/device-management/apple/enrollment/apple-configurator/). ### Pasos siguientes Ahora que los principales conceptos están algo más claros, te sugerimos seguir estos pasos: **Determinar las necesidades de supervisión** Determina si necesitarás [privilegios de supervisión](https://docs.applivery.com/es/device-management/apple/supervision/) para los dispositivos. **Seleccionar el método de inscripción** Selecciona el [método de inscripción](https://docs.applivery.com/es/device-management/apple/enrollment/enrollment-methods/) que mejor se adapte a tus requisitos de funciones y flujo de trabajo de despliegue. **Planificar el despliegue de apps** Planifica la estrategia de despliegue de apps de tu organización. **Decidir sobre el uso de Apple IDs** Decide si utilizarás Apple IDs en tu despliegue. --- ## Políticas Source: https://docs.applivery.com/es/device-management/apple/apple-policies/ Description: Políticas de Gestión de dispositivos Apple en Applivery — crea y aplica políticas en dispositivos iOS, iPadOS y macOS desde un panel centralizado. TL;DR: Applivery simplifica la gestión de dispositivos Apple proporcionando un panel centralizado para crear y aplicar políticas en dispositivos iOS, iPadOS y macOS. Answers: ¿Qué es la Gestión de dispositivos Apple en Applivery? · ¿Qué ajustes del dispositivo pueden configurar los administradores? · ¿Qué plataformas admite la Gestión de dispositivos Apple de Applivery? · ¿Qué pueden garantizar los administradores con la Gestión de dispositivos Apple? · ¿Dónde se pueden gestionar las políticas en Applivery? · ¿Qué reglas de seguridad se pueden aplicar? Key topics: Gestión de dispositivos Apple, Políticas iOS, Políticas iPadOS, Políticas macOS, Applivery, Apple, iOS, iPadOS, macOS Las políticas de Apple en Applivery te permiten definir y aplicar configuraciones en dispositivos iOS, iPadOS y macOS. Desde los requisitos de contraseña y perfiles de restricción hasta certificados, VPN y ajustes Wi-Fi, las políticas te dan un control granular sobre cada dispositivo inscrito. Los ajustes de políticas para plataformas Apple incluyen tanto opciones compartidas como específicas de cada plataforma. --- ## Bloqueo de activación Source: https://docs.applivery.com/es/device-management/apple/apple-policies/activation-lock/ Description: Controla de forma centralizada el Bloqueo de activación en dispositivos Apple supervisados con Applivery — activa una protección sólida y simplifica la recuperación de dispositivos. TL;DR: Applivery permite a los administradores de TI controlar de forma centralizada el Bloqueo de activación en dispositivos Apple supervisados, garantizando seguridad y fácil recuperación. Answers: ¿Qué es el Bloqueo de activación de Apple? · ¿Cómo gestiona Applivery el Bloqueo de activación en dispositivos supervisados? · ¿Cómo activo el Bloqueo de activación en Applivery? · ¿Cómo puedo omitir el Bloqueo de activación con Applivery? · ¿Cómo desactivo el Bloqueo de activación con Apple Business? · ¿Qué ocurre si el dispositivo muestra la pantalla de Bloqueo de activación al desactivarlo en Apple Business? · ¿Qué se necesita para desactivar el Bloqueo de activación basado en la organización en Applivery? · ¿Se puede desactivar el Bloqueo de activación en Applivery si lo activó el usuario? Key topics: Bloqueo de activación, Apple MDM, Gestión de dispositivos, Applivery, Apple, Apple Business El **Bloqueo de activación** es una función de seguridad integrada de Apple diseñada para impedir el uso no autorizado de dispositivos Apple en caso de pérdida, robo o borrado. Cuando está activado, vincula el dispositivo a un Apple ID y requiere esas credenciales para reactivarlo tras un restablecimiento. En entornos corporativos, el Bloqueo de activación puede ser tanto un potente mecanismo de seguridad como un posible reto operativo si no se gestiona correctamente. Applivery permite a los administradores de TI controlar de forma centralizada el Bloqueo de activación en dispositivos Apple supervisados, garantizando una protección sólida y manteniendo la propiedad administrativa y la capacidad de recuperación. ### ¿Qué es el Bloqueo de activación? El Bloqueo de activación forma parte del framework **Buscar** de Apple y se activa automáticamente cuando Buscar está activo en un dispositivo. Una vez activado: - El dispositivo no se puede reactivar sin las credenciales del Apple ID asociado. - Borrar el dispositivo no elimina el bloqueo. - La función protege contra la reventa o reutilización no autorizada. En dispositivos no gestionados, el Bloqueo de activación está vinculado al Apple ID personal del usuario. En entornos gestionados, este comportamiento puede controlarse a través del MDM. ### Bloqueo de activación en dispositivos Apple gestionados Cuando los dispositivos están [supervisados](https://docs.applivery.com/es/device-management/apple/supervision/) e [inscritos a través de Apple Business](https://docs.applivery.com/es/device-management/apple/enrollment/dep/), el Bloqueo de activación puede ser gestionado por la organización en lugar del usuario final. Con Applivery, los administradores pueden: - Activar el Bloqueo de activación con control institucional. - Omitir el Bloqueo de activación al recuperar o redistribuir dispositivos. - Impedir que los usuarios activen el Bloqueo de activación personal. - Obtener o custodiar códigos de bypass de forma segura. Esto garantiza que los dispositivos permanezcan protegidos sin riesgo de bloqueo permanente. ### Cómo funciona el Bloqueo de activación con Applivery Applivery usa los comandos MDM oficiales de Apple para gestionar el comportamiento del Bloqueo de activación en dispositivos supervisados. Cuando está activado, el Bloqueo de activación puede ser propiedad de la organización y controlado por ella, se genera automáticamente un código de bypass que se almacena de forma segura, y los administradores pueden eliminar el Bloqueo de activación de forma remota siempre que sea necesario. Para permitir la activación del Bloqueo de activación en Applivery, navega a **Dispositivos** en el [**panel de Applivery**](https://dashboard.applivery.io/) y selecciona el dispositivo de destino. A continuación, abre la sección **Configuración** 1 y selecciona la pestaña **Bloqueo de activación** 2. En la sección **Estado**, haz clic en **Permitir** 4 para habilitar la activación de la función. ![activation lock](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/7e5bf9e9-80e7-440e-aa29-ddd42366a810.png) Una vez activado, la sección Bypass proporciona las opciones de recuperación disponibles. Los administradores pueden **borrar el Bloqueo de activación manualmente usando el código de bypass almacenado** o **eliminarlo de forma remota a través de la API de Applivery**. ![bypass](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/19e75c82-394b-4f82-8f93-95821ce60009.png) :::info El Bloqueo de activación también puede permitirse de forma masiva usando las [Inscripciones inteligentes de Apple](https://docs.applivery.com/es/device-management/apple/enrollment/smart-enrollment/), lo que permite a las organizaciones aplicar este ajuste automáticamente durante inscripciones de dispositivos a gran escala. ::: ### Cómo desactivar el Bloqueo de activación con Apple Business Apple ha introducido una nueva capacidad en Apple Business y Apple School Manager (ASM) que permite a los administradores desactivar el Bloqueo de activación en dispositivos gestionados directamente desde el portal, sin necesidad de introducir un código de bypass en el dispositivo. Esto ofrece una alternativa práctica a la introducción manual de códigos y es especialmente útil si un usuario ha activado el Bloqueo de activación mediante iCloud o Buscar. Para usar esta función, [inicia sesión en tu portal de Apple Business](https://business.apple.com/) o ASM y localiza el dispositivo para el que quieres eliminar el Bloqueo de activación. Selecciona el dispositivo y elige **Desactivar Bloqueo de activación**. ![activation lock ab](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/1ad503e1-129b-4f8e-97cf-439663dffa2a.png) :::info Si el dispositivo está mostrando la pantalla de Bloqueo de activación, el comando eliminará el bloqueo, pero **puede ser necesario un reinicio** para que el cambio surta efecto. ::: ### Consideraciones importantes El Bloqueo de activación debe usarse como parte de una estrategia más amplia del ciclo de vida del dispositivo: - Los dispositivos inscritos sin Apple Business pueden seguir bloqueados con los Apple IDs de los usuarios. - Si se permite el Bloqueo de activación personal, la recuperación puede requerir la cooperación del usuario. - El Bloqueo de activación institucional garantiza la recuperabilidad sin intervención de Apple. - La inscripción y supervisión correctas son fundamentales para una gestión exitosa. ### Estado del dispositivo compatible para desactivar el Bloqueo de activación Los siguientes estados del dispositivo determinan si puedes desactivar el Bloqueo de activación. | Estado del dispositivo | Interfaz de usuario | ¿Se puede desactivar el Bloqueo de activación en Apple Business? | ¿Se puede desactivar en Applivery? | | --- | --- | --- | --- | | Bloqueo de activación basado en usuario activado | Bloqueo de activación activado (Usuario) | ✅ | ❌ | | Bloqueo de activación basado en organización activado | Bloqueo de activación activado (Organización) | ✅ | ✅ | | Modo perdido gestionado activado por el servicio de gestión de dispositivos | Bloqueo de activación activado (Organización) | ✅ | ✅ | | Modo perdido activado por el usuario | Bloqueo de activación activado (Usuario) | ✅ | ❌ | El Bloqueo de activación es una función de seguridad clave para los dispositivos Apple, pero en entornos empresariales debe gestionarse cuidadosamente para evitar bloqueos de dispositivos e interrupciones operativas. Con Applivery, los equipos de TI pueden controlar de forma centralizada el Bloqueo de activación usando el framework MDM oficial de Apple, garantizando que los dispositivos permanezcan seguros, recuperables y bajo control organizativo total durante todo su ciclo de vida. --- ## Agente Source: https://docs.applivery.com/es/device-management/apple/apple-policies/agent/ Description: El agente Apple de Applivery para macOS e iOS — funciones MDM avanzadas, opciones de Self-Service, informes de geolocalización y gestión de apps. TL;DR: El Agente Apple de Applivery amplía las capacidades MDM en macOS e iOS con funciones como Self-Service, geolocalización y gestión de apps. Key topics: Self-Service del Agente macOS, Geolocalización del Agente iOS, Lista de bloqueo de apps, Configuración del agente, Apple, Applivery, macOS, iOS, App Store, Apple Business, VPP (Programa de compras por volumen) ![agent overview](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/7eb7f04e-c298-4cbb-9be3-f55eb014aa6b.png) El Agente Apple es un software que se puede instalar en los dispositivos de una organización. Su propósito es potenciar Applivery para ampliar sus capacidades, yendo más allá del protocolo MDM de Apple y desbloqueando funcionalidades de gestión avanzadas. Antes de desplegar el Agente de Applivery, es fundamental comprender las directrices y requisitos establecidos por Apple para garantizar el cumplimiento y el funcionamiento óptimo. ### App Agente para dispositivos macOS El uso del Agente macOS proporciona funcionalidades adicionales y capacidades de gestión avanzadas que no están disponibles mediante las APIs de Apple. Esto permite una personalización más profunda y una gestión más completa de los dispositivos macOS en un entorno empresarial. Proporciona una serie de funcionalidades adicionales tanto para el usuario, propietario del dispositivo, como para el administrador de TI, que gestiona la flota de dispositivos corporativos. **Self-Service** El Self-Service para macOS es una aplicación nativa de Swift diseñada para ofrecer la experiencia Apple que esperan tus usuarios. Su funcionalidad principal gira en torno a mejorar la eficiencia operativa de TI, dotando a los usuarios de las herramientas necesarias para atender de forma independiente las solicitudes habituales, descargando así tareas de los administradores. Mediante la integración perfecta en los dispositivos gestionados, el Self-Service facilita el despliegue automático, estableciendo una plataforma dedicada para los usuarios. En este entorno, los usuarios acceden a un repositorio organizado de recursos, lo que les permite satisfacer sus necesidades de forma eficiente. ![self-service-app-store | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/438ddb02-c535-4042-a2d4-1f6db2248655.png "self-service-app-store | Applivery") ##### 1.1 Catálogo de apps Los administradores pueden designar aplicaciones para que los usuarios finales las instalen bajo demanda. Para obtener orientación detallada sobre la gestión de aplicaciones y licencias, consulta nuestra [documentación](https://docs.applivery.com/es/device-management/apple/macos/app-management/app-catalog/). ##### 1.2 Acciones Otorga a tus usuarios finales la capacidad de ejecutar scripts para asistencia en tareas o resolución de problemas del dispositivo. Los resultados de estas ejecuciones se reportarán automáticamente al panel de Applivery. Puedes descubrir cómo asignar un Script al Self-Service [aquí](https://docs.applivery.com/es/device-management/apple/macos/scripts/). ##### 1.3 Marcadores Puedes usar marcadores para proporcionar a tus usuarios acceso directo fácil a páginas web específicas. Cuando pones un marcador disponible en el Self-Service, puedes personalizar cómo se muestra a los usuarios. Esto incluye personalizar la etiqueta del marcador, subir un icono personalizado y añadir una descripción. Para configurar marcadores, navega a cualquiera de tus **Políticas** 1 en el [**panel de Applivery**](https://dashboard.applivery.io/). En el menú lateral izquierdo, haz clic en **Marcadores** 2 y luego en el botón **\+ Añadir marcador** 3 para empezar a añadir marcadores a tu Self-Service. ![bookmarks](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/65cd1cf0-2e0c-43bc-8aa1-fb5fd1a449fc.png) ##### 1.4 Informes de estado El Agente ofrece informes detallados sobre el estado y el rendimiento de los dispositivos macOS, permitiendo a los administradores de TI tomar decisiones de gestión informadas. Esta función de informes opcional se puede activar directamente a través del Agente, proporcionando a los administradores información adicional. Sigue los informes enviados al panel de Applivery sobre el estado de la batería, la actividad Bluetooth y la información del sistema. ![agent](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/9cba3a77-1d5e-4b34-bdcd-a4861a8debc2.png) **Activar el Agente macOS** La función de lista de bloqueo de apps del Agente macOS de Applivery ofrece la ventaja de gestionar tanto las apps instaladas por el usuario como las apps preinstaladas en el dispositivo. La lista de bloqueo de apps permite seleccionar apps no conformes, garantizando su eliminación si están instaladas o impidiendo su instalación en el futuro. Las apps no conformes son aquellas no distribuidas a través de Applivery, mientras que las apps corporativas distribuidas a través del producto se clasifican como apps gestionadas. En este contexto, los administradores de TI deben impedir que las apps no conformes accedan o compartan datos corporativos. Para configurar una lista de bloqueo de apps, sigue los pasos descritos en el [siguiente artículo](https://docs.applivery.com/es/device-management/apple/app-management/block-allow-apps/#bloquear-una-lista-de-apps-para-dispositivos-macos) de nuestra documentación. Navega a cualquiera de tus **Políticas** 1 en el [**panel de Applivery**](https://dashboard.applivery.io/). En el menú lateral izquierdo, haz clic en **Agente** 2 y **activa** 3 el Agente macOS. ![agent](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/793c8271-4dca-4f29-8c52-2fe31367fe98.png) ### App Agente para dispositivos iOS **Self-Service** ![self service portal](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/5f1f41e8-ba5f-44c0-9f60-a26be65ee659.png) Tras la configuración, el usuario llega al portal Self-Service, la interfaz principal del Agente orientada al usuario. ##### Diseño El portal tiene tres elementos principales: - **Barra superior**: Muestra el nombre de la sección actual. A la izquierda, un icono de menú abre el cajón de navegación. Dentro de las pantallas de detalles (como la página de detalles de una app), el icono de menú se reemplaza por una flecha hacia atrás. - **Área de contenido**: Muestra la sección activa (Aplicaciones, Marcadores, Estado, etc.). - **Cajón de navegación**: Un panel lateral que se desliza desde la izquierda. Enumera todas las secciones habilitadas y permite cambiar entre ellas. ##### ¿Qué secciones son visibles? Las secciones que se muestran en el cajón de navegación dependen de lo que el administrador haya habilitado mediante la configuración gestionada. Solo las secciones activas aparecen en el menú. Si no se configuran funciones, el portal muestra por defecto la sección **Estado** para que el usuario siempre tenga visibilidad sobre el estado de gestión del dispositivo. ![status](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/233e6e30-075f-4080-8973-51d037ff43fa.png) #### Aplicaciones La sección Aplicaciones es la función principal del portal Self-Service. Permite a los usuarios buscar, instalar, actualizar y desinstalar aplicaciones corporativas asignadas a sus dispositivos. La sección se organiza en tres pestañas. ![home screen](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/a6091cb8-fe3a-4ebb-9921-8a93c1e72b91.png) ##### Pestaña Inicio La pestaña Inicio es la vista de aterrizaje de la sección Aplicaciones, que proporciona una visión general rápida: - **Vista previa de aplicaciones**: Muestra hasta cuatro apps del usuario, priorizando las no instaladas. Cada app muestra su icono, nombre, categoría y un botón de acción (Abrir, Instalar o Actualizar). Toca **Ver todo** para navegar a la pestaña Mis apps. - **Accesos directos a funciones**: Una cuadrícula de tarjetas que enlazan a otras secciones habilitadas del Self-Service (Marcadores, Estado, etc.) para acceso rápido sin abrir el cajón de navegación. - **Tirar para actualizar**: Tira hacia abajo en la pantalla para actualizar la lista de aplicaciones desde el servidor. ##### Pestaña Mis apps Muestra una lista completa de todas las aplicaciones gestionadas instaladas actualmente en el dispositivo, además de las que se están instalando. Cada app muestra: - Icono, nombre y categoría. - Un botón de acción: **Abrir** (instalada y actualizada), **Actualizar** (nueva versión disponible) o un indicador de progreso animado (instalándose actualmente). Si no hay apps gestionadas instaladas, la pantalla muestra: _"No hay aplicaciones instaladas."_ ##### Página de detalles de la app Al tocar cualquier aplicación se abre su página de detalles completa, que incluye: - **Encabezado**: Icono grande de la app, nombre de la aplicación y nombre del editor. - **Advertencia de compatibilidad**: Si la app requiere una versión de iOS más reciente que la del dispositivo, aparece una advertencia _"No compatible con este dispositivo"_ y el botón Instalar se deshabilita. - **Botones de acción**: Varían según el estado actual de la app: | Estado de la app | Acciones disponibles | | --- | --- | | No instalada | **Instalar** | | No instalada (incompatible) | **Instalar** (deshabilitado) | | Instalada | **Desinstalar** y **Abrir** | | Actualización disponible | **Desinstalar** y **Actualizar** | | Instalación en curso | Indicador de carga animado (sin botones) | #### Marcadores La sección Marcadores muestra URLs y enlaces web que la organización ha compartido con el usuario, como enlaces a herramientas internas, documentación o portales de la empresa. ##### Organización Los marcadores se agrupan en dos categorías: - **Personalizados**: Enlaces configurados específicamente por el administrador de la organización. - **Applivery**: Enlaces proporcionados por el panel de Applivery. Los usuarios pueden filtrar entre Personalizados y Applivery, pero no hay opción para eliminar el filtro y mostrar todos los marcadores a la vez. Cada marcador muestra un icono (si está configurado), nombre, descripción y un botón **Abrir** que abre la URL en el navegador predeterminado del dispositivo. #### Estado La sección Estado proporciona al usuario visibilidad sobre los agentes de gestión (servicios en segundo plano) que se ejecutan en su dispositivo. Cada agente es responsable de recopilar e informar un tipo específico de información del dispositivo al panel de Applivery. #### Agentes | Agente | Qué hace | | --- | --- | | **Seguimiento de ubicación** | Informa la ubicación geográfica del dispositivo. | | **Información del sistema** | Proporciona información detallada del dispositivo, incluyendo datos de hardware y SO. | | **Batería** | Informa el estado de la batería. | | **Bluetooth** | Informa el estado del Bluetooth. | | **Descargar recursos** | Los archivos y recursos requieren interacción del usuario en la sección Archivos. | ##### Indicadores de estado Cada agente se muestra como una tarjeta con su icono, nombre, última hora de ejecución exitosa y un estado codificado por colores: | Indicador | Color | Significado | | --- | --- | --- | | **Habilitado** | Verde | Ejecutándose normalmente e informando según lo programado | | **Deshabilitado** | Gris | Desactivado por el administrador para este dispositivo | | **Error** | Naranja | Ocurrió un problema (p. ej., se denegó un permiso requerido) | #### Navegación y menú ##### Menú lateral Abre el menú lateral tocando el icono de menú (☰) en la esquina superior izquierda. El menú contiene: - Un botón para cerrarlo (✕). - El logotipo de Applivery. - Todas las secciones habilitadas con sus iconos: Aplicaciones, Archivos, Marcadores, Estado, Notificaciones. Al tocar cualquier sección se cambia a esa vista y se cierra el menú. ##### Navegación hacia atrás Cuando estás dentro de una pantalla de detalle (detalle de app, búsqueda), el icono de menú se sustituye por una flecha de retroceso. Cada sección principal mantiene su propio historial de navegación: al volver a una sección, se retoma donde el usuario la dejó. #### Configuración de administrador Los administradores controlan el comportamiento del portal Self-Service a través de la política de configuración gestionada en el panel de Applivery, que se envía a los dispositivos automáticamente. ![apple self service configuration](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/9f220cb1-f43a-4b10-8bf0-97c83ad94bc7.png) ##### Conmutadores de funciones Cada sección del portal Self-Service se puede habilitar o deshabilitar de forma independiente: | Clave de función | Sección | | --- | --- | | `APPLICATIONS` | Catálogo de aplicaciones con instalación/actualización/desinstalación | | `BOOKMARKS` | Marcadores y enlaces web de la organización | | `STATUS` | Panel de monitorización del estado del agente | | `FILES` | Gestión de archivos | #### Compatibilidad del dispositivo El Agente MDM Apple de Applivery v2.0.0 es compatible con: - **iOS 16.0** y versiones superiores. - iPhone y iPad. :::warning La versión 2.0.0 es una actualización unidireccional. Una vez que un dispositivo se actualiza a la v2.0.0, no se puede degradar a la v1.x sin perder los datos locales de aplicaciones y certificados. ::: **Informes de geolocalización** Apple pone un gran énfasis en la privacidad del usuario e impone restricciones estrictas a las capacidades de la aplicación del Agente. Como resultado, solo se permiten informes de geolocalización a través de la App del Agente. ![location](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ceebda46-c03e-4436-a78e-0d95135a889f.png) **Condiciones de informe** El Agente solo informará cuando el dispositivo detecte un cambio sustancial de ubicación, superior a 500 metros. **Configuración inicial y permisos** Tras la instalación, los usuarios deben abrir la aplicación por primera vez y otorgar explícitamente los permisos de geolocalización. Para mejorar la funcionalidad y evitar que el sistema operativo deprioritice su ejecución, se recomienda encarecidamente otorgar permisos de ejecución permanentes a través de **Configuración › Applivery MDM › Ubicación › Siempre**. **Detalles de despliegue** El Agente iOS de Applivery está disponible en la **App Store**, y nuestra plataforma facilita su instalación a través del [**VPP (Programa de compras por volumen)**](https://docs.applivery.com/es/device-management/apple/app-management/vpp/). Es fundamental asignar licencias en **Apple Business** para poner el Agente a disposición. El Agente es exclusivamente compatible con dispositivos con **iOS/iPadOS 16.0 o superior**. **Activar el Agente iOS** Navega a cualquiera de tus **Políticas** 1 en el [**panel de Applivery**](https://dashboard.applivery.io/). En el menú lateral izquierdo, haz clic en **Agente** 2 y **activa** 2 el Agente iOS, elige rastrear la ubicación del dispositivo y decide si el Agente debe instalarse con licencia VPP. ![agent](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/2569a0f6-2434-4270-8d92-7cec329607fa.png) --- ## Bloqueo automático Source: https://docs.applivery.com/es/device-management/apple/apple-policies/auto-lock/ Description: Protege los dispositivos Apple con Applivery configurando el Bloqueo automático. Aprende a aplicar tiempos de espera por inactividad y gestionar las políticas de seguridad del dispositivo. TL;DR: Aprende a configurar el Bloqueo automático en dispositivos Apple con Applivery MDM para aplicar políticas de seguridad y gestionar la inactividad, equilibrando seguridad y experiencia de usuario. Key topics: Configuración de Apple MDM, Políticas de seguridad del dispositivo, Applivery MDM, Applivery, Apple, iPad, Apple Business, DEP En entornos corporativos, definir el tiempo de bloqueo automático correcto en dispositivos Apple — como los iPads — es esencial para equilibrar la seguridad y la usabilidad. Un valor de Bloqueo automático demasiado corto puede interrumpir los flujos de trabajo diarios, mientras que un valor excesivamente largo puede aumentar los riesgos de seguridad. Con Applivery, los administradores pueden aplicar de forma centralizada el tiempo máximo de inactividad antes de que un dispositivo se bloquee automáticamente y requiera un código de acceso, garantizando el cumplimiento de las políticas de seguridad de la organización en todos los dispositivos Apple gestionados. ### Requisitos previos Antes de aplicar esta configuración, asegúrate de que: - El dispositivo Apple esté inscrito en Applivery. - La política esté correctamente asignada a los dispositivos de destino. :::info **No hace falta supervisión.** La configuración de Código de Apple — donde vive el ajuste de Bloqueo automático — está catalogada por Apple como `Requires supervision: N/A`, así que el Bloqueo automático se aplica igual en dispositivos [supervisados](https://docs.applivery.com/es/device-management/apple/supervision/) y no supervisados. La excepción es **User Enrollment** (BYOD). Apple acepta la configuración en dispositivos inscritos por usuario, pero ignora la mayoría de sus claves: fuerza un código de 6 dígitos no simple y elimina la opción **Nunca** de los Ajustes, mientras **ignora el valor de Bloqueo automático que configures**. Para aplicar un tiempo concreto, usa Device Enrollment o Automated Device Enrollment (DEP). ::: El Bloqueo automático es uno de los ajustes de la configuración de Código. Para el resto — longitud, complejidad, caducidad, intentos fallidos — consulta [Política de código de acceso](https://docs.applivery.com/es/device-management/apple/apple-policies/passcode/). ### Configuración **Navegar a Políticas** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io), dirígete a cualquiera de tus **Políticas** 1. En el menú lateral izquierdo, selecciona la opción **\+ Añadir configuración** y elige **Código** 2. ![passcode](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/8fa3efe6-caa7-4975-8881-4e68801a5837.png) **Configurar el Bloqueo automático** Dentro de la configuración del Código, localiza el campo **Bloqueo automático** e introduce el valor deseado en minutos. Este valor representa el tiempo máximo que el dispositivo puede permanecer inactivo antes de bloquearse automáticamente y solicitar al usuario el código de acceso. ![auto lock](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/dd6312f2-fc60-49cd-9d58-b940aaea21b9.png) ### Valores permitidos y comportamiento El parámetro de Bloqueo automático define **un tiempo máximo de inactividad** más que una sugerencia opcional. Apple aplica límites estrictos a este ajuste a través del MDM. El valor mínimo admitido es el bloqueo inmediato (0 minutos), que generalmente se desaconseja excepto en entornos de alta seguridad. El valor máximo admitido es de 15 minutos. :::info Apple no ofrece la opción **Nunca** para el Bloqueo automático vía MDM, y no es posible deshabilitar completamente este comportamiento en dispositivos gestionados, estén supervisados o no. ::: ### Efectos de aplicar esta configuración Una vez aplicada esta configuración, los usuarios ya no podrán aumentar el tiempo de Bloqueo automático desde la configuración local del dispositivo. El sistema siempre se bloqueará tras el periodo de inactividad definido, incluso cuando se configure el valor máximo. Esto garantiza que los dispositivos desatendidos no permanezcan desbloqueados indefinidamente. ### Consideraciones importantes Ninguna solución MDM, incluida Applivery, puede mantener la pantalla encendida de forma permanente mediante los ajustes de Bloqueo automático. El valor máximo realista y recomendado sigue siendo de 15 minutos, lo que proporciona un equilibrio razonable entre seguridad y usabilidad. Para escenarios donde la pantalla deba permanecer activa continuamente — como quioscos, señalización digital o sistemas de punto de venta — el Bloqueo automático no es el mecanismo adecuado. En estos casos, se recomienda encarecidamente usar el [Modo quiosco](https://docs.applivery.com/es/device-management/apple/ios-ipados/policies/kiosk-mode/#app-lock) (Modo App Lock) o una aplicación dedicada diseñada para operación siempre activa. ### Casos de uso recomendados | Escenario | Recomendación | | --- | --- | | Uso corporativo estándar | Bloqueo automático a 10-15 minutos. | | Dispositivo compartido | Bloqueo automático corto (5-10 minutos). | | Quiosco / recepción | Modo App Lock. | Applivery permite a los administradores gestionar de forma centralizada el comportamiento del Bloqueo automático en dispositivos Apple, ayudando a las organizaciones a mantener el cumplimiento de las políticas de seguridad minimizando la fricción con el usuario. Aunque iPadOS no permite deshabilitar el Bloqueo automático completamente vía MDM, configurar el valor máximo admitido ofrece un equilibrio efectivo entre protección y experiencia de usuario. --- ## Bloquear capturas y grabaciones de pantalla Source: https://docs.applivery.com/es/device-management/apple/apple-policies/block-screenshots/ Description: Impide que los usuarios guarden capturas y grabaciones de pantalla en dispositivos iOS, iPadOS y macOS gestionados, mediante la carga útil nativa de Restricciones de Apple. TL;DR: Bloquea las capturas y grabaciones de pantalla en dispositivos iOS, iPadOS y macOS gestionados desde la sección Restricciones de una política Apple. No requiere supervisión. Answers: ¿Se pueden bloquear las capturas de pantalla en iPhone y iPad con Applivery? · ¿Se pueden bloquear las capturas de pantalla en Mac con Applivery? · ¿Es necesario que el dispositivo esté supervisado? · ¿Qué versión mínima de iOS, iPadOS o macOS se necesita? · ¿Esta restricción también bloquea la grabación de pantalla? · ¿Afecta a las apps de terceros como Zoom o Teams? · ¿Por qué sigue apareciendo un aviso de captura en macOS con la restricción activa? Key topics: Restricciones de Apple, Capturas y grabaciones de pantalla, Prevención de fuga de datos, Políticas Apple, Applivery, Apple, iOS, iPadOS, macOS Las capturas de pantalla son una de las vías más sencillas para que la información sensible salga de un dispositivo gestionado. Una ficha de cliente, un panel interno, una pantalla de nóminas: un solo toque y ya está en el carrete, lista para compartirse en cualquier parte. Applivery te permite cortar eso a nivel de sistema operativo en iOS, iPadOS y macOS, mediante la carga útil nativa de Restricciones de Apple. Y a diferencia de muchas restricciones de Apple, esta **no** requiere que el dispositivo esté supervisado. ### Qué hace esta restricción La carga útil de Restricciones de Apple (`com.apple.applicationaccess`) incluye un ajuste que impide al usuario **guardar** una captura o una grabación de pantalla. Cuando lo activas, el usuario sigue pudiendo pulsar la combinación de teclas o botones habitual, pero el sistema no genera ni guarda el archivo resultante. La restricción se comporta igual en iOS, iPadOS y macOS, aunque cada plataforma tiene su propia versión mínima de sistema operativo. :::info Esta restricción actúa a nivel de sistema operativo, no por app. No sustituye a los controles de protección de contenido que algunas apps implementan de forma nativa (por ejemplo, apps de videollamada o de correo corporativo) y **no puede impedir que alguien fotografíe la pantalla con otro dispositivo**. ::: ### Requisitos

Plataforma

Versión mínima de SO

¿Requiere supervisión?

iOS / iPadOS

iOS 5 / iPadOS 13.1

No

macOS

macOS 10.14.4

No

Al no requerir supervisión, puedes aplicar esta restricción tanto en dispositivos de propiedad corporativa como, en determinados escenarios de inscripción de usuario, en dispositivos BYOD, sujeto a las limitaciones generales de cada método de inscripción. ### Cómo funciona a nivel técnico La restricción forma parte de la carga útil `com.apple.applicationaccess` (Restrictions) del perfil de configuración MDM. Es la misma carga útil que usan otras restricciones del sistema, como el bloqueo de AirDrop o de la instalación de apps, por lo que puedes combinarla con ellas dentro del mismo perfil. ```xml allowScreenShot ``` Al establecer esta clave en `false` se impide guardar capturas y grabaciones de pantalla. El valor por defecto de Apple es `true`, es decir, permitido. :::warning Un dispositivo puede tener más de una carga útil de Restricciones, pero Apple advierte expresamente de que **no debes gestionar la misma restricción desde dos perfiles distintos**. Si lo haces, el comportamiento resultante no está garantizado. ::: ### Configuración **Ve a Políticas** Accede al [**panel de Applivery**](https://dashboard.applivery.io) y abre **Políticas** 1. **Selecciona o crea una política Apple** Elige una política **Apple** existente o [crea una nueva](https://docs.applivery.com/es/device-management/general-settings/create-policies/) para la plataforma que necesites: iOS/iPadOS o macOS. :::info Una política solo puede asociarse a una plataforma. Si gestionas iPhone/iPad y Mac, necesitarás una política por plataforma. ::: **Abre Restricciones** En el menú lateral izquierdo, dirígete a la sección **Restricciones** 2 dentro de **\+ Añadir configuración**. ![restrictions](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/e88cb095-e78c-438b-b89c-3c3367f0efa1.png) **Desactiva el ajuste** Localiza **Allow Screenshots and Screen Recording** y desactívalo para bloquear la funcionalidad. ![allow screenshots and screen recording setting](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/73a6e996-7b06-4cd7-ba01-25a0177f3f2f.png) **Guarda y asigna** Guarda la configuración y asigna la política al dispositivo o grupo de dispositivos que quieras cubrir. :::warning La leyenda de disponibilidad del panel solo indica compatibilidad con macOS Mojave 10.14.4 o superior y visionOS 2.0, pero este ajuste también es compatible con **iOS y iPadOS**, y les afecta exactamente igual. ::: ### Consideraciones importantes - **No hay distinción entre captura y grabación de pantalla.** Apple cubre ambas funciones con la misma clave, así que no puedes permitir una y bloquear la otra. - **Esta restricción no controla el acceso de apps de terceros a la observación de la pantalla de otros dispositivos**, por ejemplo funciones de visualización remota tipo Aula/Classroom. Apple gestiona ese acceso mediante una sub-restricción anidada bajo la misma clave. - **Sigue siendo posible fotografiar la pantalla con otro dispositivo.** Entiende esta restricción como una capa más de tu estrategia de prevención de fuga de datos, no como una garantía absoluta. ### Resolución de problemas **El usuario sigue pudiendo guardar capturas de pantalla después de aplicar la política** - Confirma que el perfil se ha instalado correctamente en el dispositivo. En iOS/iPadOS, comprueba **Ajustes > General > VPN y gestión de dispositivos**. En macOS, comprueba **Configuración del Sistema > Perfiles**. - Verifica que no exista otro perfil de configuración en el dispositivo gestionando la misma restricción con un valor distinto. Como indica Apple, si hay más de una carga útil de Restricciones actuando sobre la misma clave, el comportamiento no está garantizado. - En macOS, si el perfil se elimina y se vuelve a aplicar, algunos ajustes de Restricciones pueden requerir un reinicio del sistema para aplicarse o revertirse por completo. Es un comportamiento observado en otras restricciones de macOS gestionadas por la misma carga útil, aunque no está confirmado específicamente para `allowScreenShot`. --- ## Check Point VPN Source: https://docs.applivery.com/es/device-management/apple/apple-policies/checkpoint-vpn/ Description: Integra Check Point Harmony Mobile VPN con Applivery para una configuración VPN sin intervención del usuario en dispositivos iOS gestionados. TL;DR: Integra Check Point Harmony Mobile VPN con Applivery para proporcionar una protección móvil segura y siempre activa con configuración VPN sin intervención del usuario. Answers: ¿Qué es la integración de Check Point Harmony Mobile VPN en Applivery? · ¿Cómo mejora la seguridad Harmony Mobile VPN? · ¿Cómo genero un certificado de política de red en Check Point? · ¿Qué configuraciones VPN se necesitan en Applivery? · ¿Cuál es el valor del Subtipo VPN para Check Point en Applivery? · ¿Qué Configuración de proveedor debo usar para Check Point en Applivery? · ¿Dónde subo el certificado de Check Point en Applivery? · ¿Qué nombre de usuario debo usar para la cuenta VPN en Applivery? Key topics: Check Point Harmony Mobile VPN, Integración con Applivery, Seguridad móvil, Despliegue sin intervención, Configuración VPN, Check Point Harmony Mobile, Applivery, VPN, HTTPS Integrar **Check Point Harmony Mobile VPN** en tu espacio de trabajo de Applivery refuerza la protección del dispositivo garantizando que todo el tráfico de red se enruta de forma segura a través de la infraestructura de confianza de Check Point. La **función VPN** añade una capa de seguridad crítica a las capacidades de prevención de amenazas de Harmony Mobile, ayudando a proteger a los usuarios de conexiones maliciosas o no seguras incluso cuando están fuera de las redes corporativas. Al combinar el **despliegue sin intervención de Harmony Mobile** con la configuración VPN automatizada, las organizaciones pueden ofrecer una protección consistente y siempre activa para los dispositivos móviles sin requerir ninguna configuración manual por parte de los usuarios finales. ### Pasos de implementación **Generar el certificado de política en Check Point** Para empezar, accede al [portal de Check Point](https://portal.checkpoint.com/) y abre la sección **Política** 1. Expande la **Política global** 2 (o la política del espacio de trabajo relevante para tu entorno) y navega a los ajustes de **Protección de red** 3. ![policy-checkpoint](https://www.applivery.com/wp-content/uploads/2025/11/policy-checkpoint-1024x611.png "policy-checkpoint | Applivery") Dentro de esta sección, localiza el panel de **Configuración HTTPS** 4 y genera un nuevo **certificado de política de red** 5. Asegúrate de guardar este certificado de forma segura, ya que será necesario más adelante al configurar la Política en Applivery. Antes de salir de esta página, también se recomienda habilitar la opción **Usar ONP de próxima generación** 6 para garantizar que se apliquen las funciones de protección más actualizadas. ![https-settings](https://www.applivery.com/wp-content/uploads/2025/11/https-settings-1024x643.png "https-settings | Applivery") **Configurar la política en Applivery** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io), dirígete a cualquiera de tus **Políticas** 7. Elige la política donde quieres configurar la VPN. En el menú lateral izquierdo, navega a la opción **\+ Añadir configuración** y elige **VPN** 8. :::info Si aún no has integrado Check Point Harmony Mobile en tu espacio de trabajo, o no has añadido la app a tu Política, puedes aprender cómo hacerlo siguiendo este [enlace](https://docs.applivery.com/es/device-management/integrations/security/checkpoint-harmony-mobile-integration/). ::: ![vpn](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/1400b15f-2657-4175-b3c3-6d118a8c3092.png) Deberás realizar las siguientes configuraciones: - **Método de autenticación**: Contraseña. - **Tipo de proveedor**: Packet-tunnel. - **Habilitar HTTPS**: 0. - **Nombre definido por el usuario**: Check Point Local Tunnel. - **Subtipo VPN**: `com.checkpoint.capsuleprotect`. - **Tipo**: VPN. - **Configuración de proveedor**: `{ "zero_touch": "true" }`. - **Dirección remota**: [www.checkpoint.com](http://www.checkpoint.com) - **Habilitar VPN bajo demanda**: 1. Dentro de la sección **Reglas bajo demanda**: - Añade reglas para **Conectar + Wi-Fi** y **Conectar + Móvil**. - Opcionalmente, puedes incluir **Conectar + Ethernet** para conexiones por cable seleccionando Conectar en el campo **Acción bajo demanda** y Ethernet en el campo **Coincidencia de tipo de interfaz**. Dentro de la sección **VPN**: - **Nombre de usuario de la cuenta**: `{{device.serialNumber}}`. - **Método de autenticación**: Certificado. **Configuración del certificado** En el menú lateral izquierdo, navega a la opción **\+ Añadir configuración** y elige **Certificado (CA de confianza)** 9. ![certificate ca](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/db596520-b782-4c75-b0ae-a2ba42947c1e.png) En el campo **Contenido del payload**, sube el certificado que descargaste previamente del portal de Check Point. Una vez subido, el certificado aparecerá en la lista de la Política, listo para su despliegue. Por último, **guarda** la Política y **despliégala**. --- ## Configurar y restringir redes Wi-Fi Source: https://docs.applivery.com/es/device-management/apple/apple-policies/configure-wifi-networks/ Description: Envía redes Wi-Fi corporativas a dispositivos Apple con Applivery y restringe a qué redes se pueden conectar los usuarios. Incluye WPA3, 802.1X y los requisitos de supervisión. TL;DR: Envía el Wi-Fi corporativo a dispositivos Apple desde Políticas > Añadir configuración > Wi-Fi. No hace falta supervisión. Restringir a qué redes puede conectarse el usuario es un ajuste aparte que sí la requiere. Answers: ¿Enviar una red Wi-Fi a dispositivos Apple requiere supervisión? · ¿Puedo impedir que los usuarios se conecten a cualquier red Wi-Fi que no sea la nuestra? · ¿La restricción de Wi-Fi funciona por nombre de SSID? · ¿Puedo enviar más de una red Wi-Fi al mismo dispositivo? · ¿Applivery admite Wi-Fi empresarial con certificados? · ¿Qué ocurre si bloqueo otras redes y la corporativa está mal configurada? · ¿Puedo impedir que los usuarios apaguen el Wi-Fi? · ¿Qué tipo de cifrado debo elegir para una red WPA3? Key topics: Configuración de Wi-Fi en Apple, Restricciones de Wi-Fi, Redes empresariales 802.1X, Requisitos de supervisión, Applivery, Apple, iOS, macOS Hay dos cosas distintas que puedes querer de la gestión del Wi-Fi, y conviene tener claro cuál necesitas, porque sus requisitos son muy diferentes: - **Entregar una red**, para que los dispositivos se conecten al Wi-Fi corporativo por su cuenta sin que nadie teclee una contraseña. Esto **no requiere supervisión** y funciona incluso en dispositivos personales. - **Restringir a qué redes pueden conectarse**, para que un dispositivo no pueda unirse a ninguna otra. Esto **sí requiere supervisión**. Puedes hacer lo primero sin lo segundo. No puedes hacer lo segundo sin lo primero: la restricción funciona permitiendo únicamente las redes que hayas entregado. ### Entregar una red Wi-Fi #### Requisitos previos - El dispositivo Apple está inscrito en Applivery. - La política está correctamente asignada a los dispositivos de destino. :::info **No hace falta supervisión.** Apple cataloga la configuración de Wi-Fi como `Requires supervision: N/A`, y está permitida explícitamente en **User Enrollment** en iOS, macOS y visionOS, así que el Wi-Fi corporativo también llega a los dispositivos personales. ::: #### Configuración Una vez en el [**panel de Applivery**](https://dashboard.applivery.io), dirígete a cualquiera de tus **Políticas** 1. En el menú lateral izquierdo, selecciona **\+ Añadir configuración** y elige **Wi-Fi** 2. ![wifi](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/aeff9f7a-2a3b-44c5-ade6-e5f09da8f1ba.png) Los ajustes esenciales son:

Ajuste

Qué hace

SSID

El nombre de la red a la que conectarse.

Red oculta

Marca la red como oculta, para que el dispositivo la encuentre aunque no difunda su nombre.

Conexión automática

Al activarlo, el dispositivo se conecta solo. Al desactivarlo, el usuario tiene que pulsar el nombre de la red.

Tipo de cifrado

La seguridad de la red. Ver la tabla siguiente.

Contraseña

La contraseña del punto de acceso, para cualquier red que no sea abierta.

:::info **Puedes declarar varias redes en la misma política.** Apple admite múltiples configuraciones de Wi-Fi, así que un dispositivo puede llevar a la vez la red de la oficina, la del almacén y una de invitados. Esto importa si piensas restringir las redes después: **toda** red que el dispositivo necesite legítimamente tiene que estar declarada, o no podrá conectarse a ella. ::: #### Tipos de cifrado A partir de **iOS 16, tvOS 16, watchOS 9 y macOS 13**, los valores dejaron de ser intercambiables y ahora significan exactamente lo que dicen:

Valor

Redes a las que puede unirse el dispositivo

WPA

WPA o WPA2

WPA2

WPA2 o WPA3

WPA3

Solo WPA3

Any

WPA, WPA2, WPA3 y WEP

None

Redes abiertas

:::warning Antes de iOS 16, WPA, WPA2 y WPA3 eran equivalentes y todos permitían unirse a cualquier red WPA. Si escribiste un perfil entonces y tus puntos de acceso han pasado a WPA3, un valor que antes funcionaba puede haberse quedado demasiado estrecho — o demasiado amplio. **WPA2** es la opción segura en un entorno mixto, porque cubre tanto WPA2 como WPA3. ::: #### Redes empresariales (802.1X) Para **WPA/WPA2 Enterprise**, la configuración admite una configuración de red empresarial con los ajustes EAP y un **certificado de cliente** referenciado desde la misma política. El certificado se distribuye como recurso y la configuración de Wi-Fi apunta a él, de modo que el dispositivo se autentica sin que el usuario introduzca nada. #### Proxy La configuración admite además un proxy para la red: manual, con la dirección del servidor, el puerto y credenciales opcionales, o automático mediante la URL de un fichero PAC. Con la opción automática puedes permitir que el dispositivo conecte directamente si el fichero PAC no está accesible, lo que evita dejar dispositivos incomunicados cuando el servidor PAC tiene un mal día. ### Restringir a qué redes pueden conectarse Una vez entregada la red corporativa, puedes impedir que el dispositivo se una a cualquier otra.

Restricción

Qué hace

Requisitos

Forzar solo redes Wi-Fi permitidas

Limita el dispositivo a unirse únicamente a redes Wi-Fi configuradas mediante un perfil de configuración.

iOS 14.5+ · iPadOS 14.5+ · visionOS 2+ · supervisado

Forzar Wi-Fi encendido

Impide apagar el Wi-Fi desde Ajustes, el Centro de Control o activando el Modo Avión. No controla a qué red se une el dispositivo.

iOS 13+ · iPadOS 13+ · supervisado

Estas viven en la configuración de **Restricciones**, no en la de Wi-Fi. :::info **La restricción funciona por origen, no por nombre.** No mantiene una lista de SSIDs permitidos: permite cualquier red que haya llegado mediante un perfil de configuración y bloquea todo lo demás. Si esperas escribir los nombres de las redes que quieres permitir, no funciona así. La consecuencia práctica: para permitir una red, la entregas. No hay forma de autorizar una red que el dispositivo conozca pero que no se haya instalado por perfil. ::: :::warning **Valida el perfil Wi-Fi antes de activar la restricción.** Si la red declarada está mal configurada — contraseña incorrecta, tipo de cifrado equivocado, una errata en el SSID — el dispositivo se queda sin poder unirse a nada, incluida la red que le entregaría una política corregida. Recuperarlo exige acceso físico. Pruébalo en un dispositivo, confirma que conecta y solo entonces aplica la restricción al parque. ::: Las dos restricciones son complementarias y responden a preguntas distintas. _Forzar solo redes Wi-Fi permitidas_ controla **a qué** red se conecta; _Forzar Wi-Fi encendido_ impide que el usuario esquive todo el mecanismo simplemente apagando el Wi-Fi. En un dispositivo compartido o de uso único, normalmente quieres las dos. :::info Existe una restricción anterior, **Forzar lista blanca de Wi-Fi** (iOS 10.3+), que Apple **dejó obsoleta en iOS 14.5** en favor de _Forzar solo redes Wi-Fi permitidas_. Usa la actual. ::: ### Dispositivos personales (User Enrollment) Entregar el Wi-Fi funciona en BYOD: Apple permite explícitamente esta configuración en User Enrollment para iOS, macOS y visionOS. Las restricciones no. Requieren supervisión, y un dispositivo personal inscrito mediante User Enrollment nunca está supervisado. Eso es el resultado esperado más que una limitación a sortear: en un dispositivo que es propiedad del empleado, entregas la red corporativa y dejas su uso personal en paz. --- ## Renombrar dispositivos Source: https://docs.applivery.com/es/device-management/apple/apple-policies/device-renaming/ Description: Renombra dispositivos iOS y macOS en Applivery usando Inscripciones inteligentes, Comandos y Scripts para una Gestión de dispositivos coherente en toda tu flota. TL;DR: Renombra dispositivos iOS y macOS con Applivery usando inscripciones inteligentes, comandos y scripts para una mejor gestión de dispositivos. Answers: ¿Cómo puedo renombrar automáticamente dispositivos iOS en Applivery? · ¿Cómo renombro un único dispositivo iOS en Applivery? · ¿Puedo renombrar varios dispositivos iOS a la vez en Applivery? · ¿Qué se necesita para sincronizar el nombre del dispositivo en iOS? · ¿Cómo renombro dispositivos macOS en Applivery? · ¿Qué información puedo usar en los scripts de nombres de dispositivos macOS? · ¿Dónde encuentro las Inscripciones inteligentes en Applivery? · ¿Cuál es el propósito de la casilla 'Aplicar al nombre del dispositivo' en las Inscripciones inteligentes? Key topics: Gestión de dispositivos, iOS, macOS, Renombrado de dispositivos, Applivery, Apple Business, Programa de inscripción de dispositivos Esta función está diseñada para ayudar a los administradores de TI a aplicar convenciones de nombres coherentes en todos los dispositivos Apple. Ofrece flexibilidad y control total sobre los Nombres de dispositivos, simplificando la gestión de dispositivos. Los administradores pueden crear esquemas de nombres estandarizados usando patrones personalizables, incorporando variables como nombres de usuario, números de serie y texto personalizado para un enfoque más personalizado en el nombre de los dispositivos. ### Renombrado de dispositivos iOS con Inscripciones inteligentes Este método es ideal para inscribir automáticamente todos los dispositivos integrados a través de **Apple Business** y el [**Programa de inscripción de dispositivos**](https://docs.applivery.com/es/device-management/apple/enrollment/dep/) (DEP) en el sistema MDM. **Acceder a las Inscripciones inteligentes** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io), dirígete a **Automatización** y sigue los pasos para [crear una Inscripción inteligente](https://docs.applivery.com/es/device-management/apple/enrollment/smart-enrollment/). **Configurar los Campos auxiliares y el Patrón de nombre de visualización** Configura los **Campos auxiliares** para personalizar los Nombres de dispositivos creando etiquetas útiles que ayuden a organizar y nombrar los dispositivos en el campo **Patrón de nombre de visualización**. ![display name](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/64196a76-901e-4285-b879-2cb8591b6426.png) **Aplicar al Nombre del dispositivo** Para garantizar que el Nombre de visualización configurado también se sincroniza con el Nombre del dispositivo, simplemente marca la casilla **Aplicar también al nombre del dispositivo (solo para iOS)**. ### Renombrado de dispositivos iOS con comandos También puedes usar **comandos** para cambios específicos en el Nombre del dispositivo. Este método es flexible y permite tanto modificaciones individuales como masivas. **Navegar a Dispositivos** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io), dirígete a cualquiera de tus **Dispositivos** para sincronizar el Nombre de visualización con el Nombre del dispositivo. **Sincronizar nombre del dispositivo (Individual)** En el resumen lateral izquierdo, haz clic en el botón **Acción** y elige **Sincronizar nombre del dispositivo**. ![sync device name](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/cf48e083-a93e-4ff1-b444-d53f5b8a2576.png) **Sincronizar nombre del dispositivo (Masivo)** Además, puedes sincronizar el Nombre de visualización con el Nombre del dispositivo de forma masiva desde la lista de Dispositivos haciendo clic en el botón **Acción**, seleccionando **Apple** como plataforma y eligiendo el comando **Sincronizar nombre del dispositivo**. ![sync in bulk](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/c906946c-19d7-4727-a62c-55b884a7808a.png) :::info El comando **Sincronizar nombre del dispositivo** requiere que el dispositivo esté en línea y sea receptivo. ::: ### Renombrado de dispositivos macOS con scripts Para los dispositivos **macOS**, Applivery ofrece la opción de crear scripts con argumentos específicos para configurar nombres personalizados para cada dispositivo. Estos scripts permiten a los administradores de TI aprovechar eficazmente la información de su flota, garantizando el establecimiento de nombres únicos y descriptivos. **Navegar a Scripts** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io), dirígete a **Recursos** 1, selecciona **Scripts** 2 en el menú lateral izquierdo y haz clic en el botón **\+ Crear Script** 3. ![scripts](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/fd376c0b-bce9-4d08-ae11-215d7ce7f070.png) **Configurar el Script** El script debe incluir argumentos que extraigan información específica de cada dispositivo según tus necesidades, como el número de serie o el nombre del empleado asignado. **Crear Nombres de dispositivo únicos** Usa esta información extraída para crear Nombres de dispositivo únicos y descriptivos. ![script change device name](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/8336d61d-967c-496f-bcd1-4fe3f109ea72.png) --- ## Gestionar actualizaciones del OS Source: https://docs.applivery.com/es/device-management/apple/apple-policies/manage-os-updates/ Description: Controla las actualizaciones de iOS, iPadOS y macOS con Applivery. Programa, retrasa y aplica versiones del OS para mayor seguridad y cumplimiento. TL;DR: Applivery simplifica la gestión de actualizaciones de software de Apple, permitiendo a los administradores de TI programar, retrasar y aplicar actualizaciones para dispositivos iOS, iPadOS y macOS. Answers: ¿Qué tipos de actualizaciones de software de Apple se pueden gestionar con Applivery? · ¿Qué son las Respuestas de seguridad rápidas (RSR) en las actualizaciones de Apple? · ¿Cómo puedo retrasar las actualizaciones principales del OS en dispositivos Apple con Applivery? · ¿Cuáles son los modos de comando de actualización de software disponibles en Applivery? · ¿Qué modos de actualización específicos de macOS están disponibles en Applivery? · ¿Cómo programo una actualización de software individual en Applivery? · ¿Cómo programo actualizaciones de software masivas en Applivery? · ¿Dónde puedo configurar los ajustes de actualización dentro de una política en Applivery? Key topics: Gestión de actualizaciones de software de Apple, Políticas de actualización MDM, Programación de actualizaciones iOS, Programación de actualizaciones macOS, Apple, iOS, iPadOS, macOS, Applivery, XProtectPlistConfigData, MRTConfigData, XProtectPayloads Mantener tus dispositivos Apple actualizados es fundamental para la seguridad, el rendimiento y el acceso a las últimas funciones. Con Applivery, puedes controlar cómo y cuándo se entregan las actualizaciones a los iPhones, iPads y Macs de tu organización, garantizando que las actualizaciones no interrumpan los flujos de trabajo y que los dispositivos cumplan con tus políticas. Ya sea que quieras automatizar las actualizaciones, retrasarlas para pruebas de compatibilidad o aplicar una versión mínima del OS en toda tu flota, Applivery te ofrece la flexibilidad y el control que necesitas. ### Requisitos :::warning **En iPhone y iPad, los comandos de actualización de software requieren un dispositivo supervisado.** Los ingenieros de Device Management de Apple indican que todos los comandos MDM de actualización de software son exclusivos de dispositivos supervisados en iOS, y el comportamiento es fácil de comprobar: un dispositivo no supervisado no ignora el comando en silencio, sino que lo **rechaza** con el error `12021` — *"not a valid request type"*. Si las actualizaciones no llegan a tus iPhone o iPad, comprueba la supervisión antes que ninguna otra cosa. ::: Dos aclaraciones que importan al planificar un despliegue: - **La condición es la supervisión, no el método de inscripción.** Automated Device Enrollment no es obligatorio como tal: lo obligatorio es que el dispositivo acabe supervisado, algo que en la práctica se consigue mediante [Automated Device Enrollment](https://docs.applivery.com/es/device-management/apple/enrollment/dep/) o [Apple Configurator](https://docs.applivery.com/es/device-management/apple/enrollment/apple-configurator/). - **Los dispositivos BYOD quedan fuera.** Un dispositivo inscrito mediante User Enrollment nunca está supervisado, así que no puede recibir comandos de actualización de software. En dispositivos personales, las actualizaciones del sistema quedan en manos del usuario. Esto aplica a los **comandos de actualización**. Los ajustes de aplazamiento a nivel de política que se describen más abajo son un mecanismo distinto y se comportan de forma independiente. ### Tipos y modos de actualización de Apple Apple proporciona múltiples mecanismos de actualización para garantizar que sus dispositivos — en **iOS, iPadOS y macOS** — permanezcan seguros, con buen rendimiento y con las últimas funciones. La forma en que se gestionan las actualizaciones puede variar según la plataforma, y algunos modos de actualización son exclusivos de **macOS**. Al planificar tu estrategia de actualizaciones, es fundamental distinguir entre **cómo se entregan las actualizaciones** (modos de actualización) y **qué tipo de actualizaciones se aplican** (tipos de actualización). #### Tipos de actualización Las actualizaciones de software de Apple se pueden categorizar en tres tipos principales: - **Actualizaciones principales del OS**: Se publican anualmente y traen nuevas funciones, cambios significativos en la interfaz y amplias mejoras del sistema. Ejemplos: iOS 17 o macOS Sonoma. - **Actualizaciones menores del OS**: Se publican con más frecuencia y se centran en mejoras incrementales, como mejoras de rendimiento, correcciones de errores y mejoras menores de usabilidad. - **Actualizaciones de seguridad y configuración en segundo plano**: Estas actualizaciones están diseñadas para mejorar la seguridad del sistema sin requerir actualizaciones completas del OS. Incluyen: - **XProtectPlistConfigData**: Actualizaciones de definiciones de malware para el antivirus integrado de Apple. - **MRTConfigData**: Actualizaciones para la Herramienta de eliminación de malware. - **XProtectPayloads**: Mejoras en los payloads de detección de amenazas usados por XProtect. #### Modos de actualización comunes en todos los dispositivos Apple Apple proporciona varios modos de actualización que se aplican en dispositivos iOS, iPadOS y macOS. Estos se pueden gestionar de dos formas principales: mediante **configuraciones de política** o enviando **comandos de actualización** directamente a los dispositivos. ##### Actualizaciones a nivel de política Estas configuraciones permiten a los administradores definir cómo y cuándo se aplican las actualizaciones: - **Actualizaciones de seguridad**: Parches críticos publicados de forma independiente para abordar vulnerabilidades. - **Respuestas de seguridad rápidas (RSR)**: Correcciones de seguridad urgentes que se entregan rápidamente y, en algunos casos, sin necesidad de reiniciar. Además, puedes configurar comportamientos avanzados de actualización como **Forzar retraso de actualizaciones de software** y **Retraso de actualización de software aplicado**, ofreciendo aún más control sobre cuándo y cómo se ponen las actualizaciones a disposición de los usuarios finales. **Navegar a Políticas** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a cualquiera de tus **Políticas** 1. En el menú lateral izquierdo, haz clic en **\+ Añadir configuración** y elige **Restricciones** 2. ![restrictions](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/e88cb095-e78c-438b-b89c-3c3367f0efa1.png) **Configurar los ajustes de actualización** Una vez añadida, navega a la pestaña **Actualizaciones** para configurar los ajustes requeridos dentro de tu Política. **Restricciones generales** Además, bajo la pestaña **General** dentro de **Restricciones**, encontrarás opciones para definir cómo se aplazan las actualizaciones del OS: - **Retraso de instalación diferida de actualización de software del OS principal aplicado**: Establece un retraso (en días) antes de que se puedan instalar las actualizaciones principales del OS. - **Forzar retraso de actualizaciones de software principales**: Aplica el retraso para las actualizaciones principales del OS. - **Retraso de instalación diferida de actualización de software del OS menor aplicado**: Establece un retraso (en días) antes de que se puedan instalar las actualizaciones menores del OS. ##### Actualizaciones basadas en comandos Applivery también permite enviar **comandos de actualización** a dispositivos Apple, dando a los equipos de TI un control más inmediato. Los modos de comando de actualización de software son: 1. **Predeterminado**: Descarga o instala automáticamente la actualización disponible según el estado actual del dispositivo y las preferencias del sistema. 2. **Solo descargar**: Descarga el paquete de actualización sin iniciar la instalación. Útil para preparar los dispositivos de antemano. 3. **Instalar lo antes posible**: Instala una actualización previamente descargada lo antes posible, incluso anulando la configuración de aplazamiento del usuario. ![schedule update](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/3c9bc516-f46f-4ab6-92b0-3934a3fb5093.png) #### Modos de actualización específicos de macOS Además de los modos de actualización comunes, macOS admite algunos modos de comando de actualización de software exclusivos del entorno de escritorio: 1. **Solo notificar**: Descarga la actualización de software en segundo plano y notifica al usuario a través de la App Store. El usuario puede elegir cuándo instalarla. 2. **Instalar más tarde**: Descarga la actualización y programa la instalación para más tarde, normalmente durante un periodo inactivo o fuera del horario de trabajo. 3. **Instalar con reinicio forzado**: Realiza la acción de actualización predeterminada (descargar e instalar) y luego fuerza un reinicio del sistema si es necesario para completar la actualización. Esto garantiza que la actualización se aplique sin esperar la intervención del usuario. #### Opciones adicionales del comando Según el modo y la plataforma, el diálogo de programación muestra dos campos más: - **Aplazamientos máximos**: cuántas veces puede posponer el usuario la actualización antes de que se aplique. Solo está disponible cuando el modo es **Instalar más tarde**. :::warning El valor **`0` significa ilimitado**, no "sin aplazamientos permitidos". Si quieres limitar las veces que se puede posponer, indica el número que realmente quieras permitir. ::: - **Alta prioridad** (solo macOS): trata la actualización como si la hubiera programado el propio usuario, lo que la adelanta respecto a la cola normal. :::info Estos comandos se corresponden con el comando MDM **`ScheduleOSUpdate`** de Apple. Conviene saberlo por dos motivos: en iOS y iPadOS descargar e instalar es un **proceso en dos pasos** — por eso **Instalar lo antes posible** actúa sobre una actualización ya descargada — y el comando programa una actualización, en lugar de declarar una fecha límite que el dispositivo deba cumplir por su cuenta. ::: ![schedule update macos](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/816f0a49-055e-4c7c-9460-e3dedec8bf4d.png) ### Programación de actualizaciones de software Con Applivery, puedes programar todos los tipos de actualizaciones del sistema operativo — ya sean principales, menores, de seguridad o de configuración — y aplicarlas de forma individual a dispositivos específicos o de forma masiva en toda tu flota. #### Programar una actualización individualmente Para programar una actualización de software para un dispositivo específico, dirígete al [**panel de Applivery**](https://dashboard.applivery.io/) y navega a cualquiera de tus **Dispositivos**. En la pestaña **Resumen**, ubicada en la esquina inferior derecha, encontrarás toda la información relevante sobre las actualizaciones de software. Si el dispositivo tiene una actualización pendiente, se mostrará aquí. Simplemente haz clic en el botón **Programar** junto a la actualización disponible. Aparecerá un modal donde puedes configurar los detalles de la actualización — como el tipo de instalación y, para dispositivos macOS, el nivel de prioridad — antes de confirmar la programación. ![schedule](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/4b703f9a-868a-440b-93bb-d3612631caa9.png) #### Programar actualizaciones de forma masiva Para programar actualizaciones para varios dispositivos a la vez, empieza por ir a la sección **Dispositivos**. Usa el botón **Acción** para abrir el menú de acciones masivas. Desde allí, selecciona la plataforma **Apple**, elige tus **dispositivos de destino**, filtra la lista por **Actualizaciones disponibles** y haz clic en **Programar actualización** para definir los ajustes de actualización, igual que harías para un dispositivo individual. ![available update](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/a30e7cdb-a246-4753-9db2-5028a4bd9b60.png) --- ## Política de código de acceso Source: https://docs.applivery.com/es/device-management/apple/apple-policies/passcode/ Description: Configura la política de Código de acceso en dispositivos Apple con Applivery. Define longitud mínima, complejidad, caducidad, intentos fallidos y bloqueo automático, con los límites exactos que aplica Apple. TL;DR: Define los requisitos de código en dispositivos Apple desde Políticas > Añadir configuración > Código. No hace falta supervisión. Ojo con los intentos fallidos: en iOS borran el dispositivo. Answers: ¿La configuración de Código de acceso requiere supervisión? · ¿Cuál es la longitud máxima de código que puedo exigir en dispositivos Apple? · ¿Cuánto tiempo puede ser válido un código antes de que el usuario deba cambiarlo? · ¿Puedo obligar a los usuarios a registrar Face ID o Touch ID? · ¿Qué ocurre tras demasiados intentos fallidos de código? · ¿Funciona la política de código en dispositivos personales BYOD? · ¿Puedo impedir que los usuarios cambien su código? · ¿Cuál es el tiempo mínimo de bloqueo automático en un dispositivo Apple? Key topics: Requisitos de código en Apple, Caducidad e historial de códigos, Intentos fallidos y borrado de datos, Limitaciones de User Enrollment, Applivery, Apple, iOS, macOS El código de acceso es el control del que depende todo lo demás en un dispositivo Apple. Data Protection cifra el almacenamiento del dispositivo, pero ese cifrado solo tiene sentido si hay un código protegiéndolo: sin él, los datos quedan desprotegidos por mucho que configures el resto. Puedes verificar ambas condiciones en un dispositivo desde [Información de seguridad](https://docs.applivery.com/es/device-management/apple/security-info/). La configuración de **Código de acceso** es donde defines cómo tiene que ser ese código: de qué longitud, con cuánta complejidad, cada cuánto cambia y qué ocurre cuando alguien se equivoca demasiadas veces. ### Requisitos previos - El dispositivo Apple está inscrito en Applivery. - La política está correctamente asignada a los dispositivos de destino. :::info **No hace falta supervisión.** Apple cataloga esta configuración como `Requires supervision: N/A`, así que se aplica igual en dispositivos [supervisados](https://docs.applivery.com/es/device-management/apple/supervision/) y no supervisados. ::: ### Configuración Una vez en el [**panel de Applivery**](https://dashboard.applivery.io), dirígete a cualquiera de tus **Políticas** 1. En el menú lateral izquierdo, selecciona **\+ Añadir configuración** y elige **Código** 2. ![passcode](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/8fa3efe6-caa7-4975-8881-4e68801a5837.png) ### Qué puedes definir #### Exigir un código **Force PIN** es el ajuste que hace obligatorio el código. Viene **desactivado por defecto**, y merece la pena detenerse aquí: sin él, ninguno de los demás ajustes obliga al usuario a tener código, solo describen cómo debe ser el código _si_ decide ponerlo. Activa primero Force PIN y configura el resto después. #### Longitud y complejidad

Ajuste

Qué hace

Rango

Longitud mínima

Longitud mínima total del código.

0–16 · por defecto 0

Permitir códigos simples

Al desactivarlo, bloquea caracteres repetidos y secuencias como 1111, 123 o CBA.

Por defecto: permitidos

Exigir alfanumérico

Exige letras, no solo dígitos.

Por defecto: desactivado

Mínimo de caracteres complejos

Número mínimo de caracteres que no son ni letras ni dígitos: &, %, $, #.

0–4 · por defecto 0

Dos detalles con los que se tropieza a menudo: - **La longitud mínima tiene un techo de 16.** Si un requisito de seguridad pide más, no es alcanzable con esta configuración. - **La longitud mínima y los caracteres complejos son independientes.** Exigir 2 caracteres complejos no implica ninguna longitud total: hay que definir ambos. Para el requisito habitual de _"un PIN de 6 dígitos que no sea trivial"_: longitud mínima `6` y **desactivar** los códigos simples, dejando el alfanumérico sin activar. #### Rotación y reutilización

Ajuste

Qué hace

Rango

Antigüedad máxima del código (días)

Días que el código puede permanecer sin cambiar. Cumplido el plazo, el sistema obliga a cambiarlo antes de desbloquear.

1–730

Historial de códigos

El nuevo código debe ser distinto de los últimos N utilizados.

1–50

Para una rotación de 12 meses, indica 365. Combínalo con el historial, o los usuarios alternarán entre dos códigos indefinidamente. #### Bloqueo por inactividad

Ajuste

Qué hace

Rango

Bloqueo automático

Minutos máximos de inactividad antes de que el dispositivo se bloquee y pida el código.

0–15 (macOS: hasta 60)

Periodo de gracia máximo

Minutos durante los que se puede volver a desbloquear sin reintroducir el código.

Por defecto 0 — sin gracia

:::warning **El bloqueo automático se expresa en minutos enteros.** No hay granularidad por debajo del minuto, así que un requisito del tipo _"que se bloquee a los 90 segundos"_ no es representable: hay que elegir 1 minuto (más estricto) o 2 (más laxo). Definir el valor elimina además la opción **Nunca** de los Ajustes del usuario. ::: El bloqueo automático es un **techo**, no un valor fijo: el usuario puede elegir un tiempo menor, pero nunca mayor. Se trata en detalle en [Bloqueo automático](https://docs.applivery.com/es/device-management/apple/apple-policies/auto-lock/). #### Intentos fallidos

Ajuste

Qué hace

Rango

Intentos fallidos máximos

Intentos de código erróneos permitidos antes de que el dispositivo se borre o se bloquee.

2–11 · por defecto 11

:::warning **En iOS, iPadOS, visionOS y watchOS, superar este límite borra de forma segura todos los datos y ajustes del dispositivo.** No lo bloquea: lo borra. Solo macOS se bloquea en su lugar. No es un ajuste para endurecer a la ligera. Un valor bajo en un dispositivo cuyo usuario se equivoque unas cuantas veces al teclear su PIN significa pérdida real de datos, y no hay marcha atrás. ::: A partir del sexto intento fallido, el dispositivo impone un retardo creciente entre intentos. Eso significa que los valores de 6 o menos se comportan distinto que los más altos: no hay retardo previo al borrado o bloqueo, ocurre en cuanto se supera el límite. #### Ajustes exclusivos de macOS

Ajuste

Qué hace

Cambiar en la próxima autenticación

Fuerza un restablecimiento de contraseña la próxima vez que el usuario se autentique. En un perfil de dispositivo afecta a todos los usuarios, y las autenticaciones de administrador pueden fallar hasta que también se restablezca la contraseña de administrador.

Minutos hasta restablecer el inicio de sesión fallido

Minutos antes de que el inicio de sesión se restablezca tras alcanzar el máximo de intentos fallidos. Requiere tener definido el límite de intentos.

Expresión regular personalizada

Una expresión regular que la contraseña debe cumplir, con una descripción localizada de la regla. macOS 14+.

:::warning Usa la **expresión regular personalizada** solo cuando los ajustes estándar realmente no puedan expresar tu requisito. Un error produce o bien una política de código imposible de satisfacer, o bien una descripción que no coincide con lo que se aplica de verdad — y quien lo descubre es el usuario, en el peor momento. La expresión usa sintaxis ICU y está limitada a 2048 caracteres. ::: ### Qué no puede hacer esta configuración Hay tres cosas que se piden a menudo y que no están aquí: - **Exigir biometría.** Apple no tiene ninguna clave que obligue al usuario a dar de alta Face ID o Touch ID. Puedes restringir la biometría, nunca imponerla. El control verificable es el propio código. - **Fijar un código concreto.** La configuración define _mínimos_. El usuario elige su código y puede cambiarlo por cualquier otro que los cumpla. - **Impedir el cambio de código.** Eso es un ajuste de **Restricciones** y, a diferencia de esta configuración, **sí requiere un dispositivo supervisado**. ### Dispositivos personales (User Enrollment) En dispositivos BYOD inscritos mediante User Enrollment, Apple acepta la configuración pero **ignora la mayoría de sus ajustes**. En su lugar, su mera presencia fuerza un conjunto fijo de reglas:

Ajuste

Qué aplica Apple

Force PIN

Siempre activado

Longitud mínima

Siempre 6

Permitir códigos simples

Siempre desactivado

Bloqueo automático

Valor ignorado — solo desaparece la opción Nunca de los Ajustes

Mínimo de caracteres complejos

Ignorado

Todo lo demás — caducidad, historial, intentos fallidos — **no se aplica**. Si tu requisito incluye rotación del código o un tiempo de bloqueo concreto, User Enrollment no puede cumplirlo: necesitas Device Enrollment o [inscripción mediante DEP](https://docs.applivery.com/es/device-management/apple/enrollment/dep/). Esta es, con diferencia, la causa más habitual del _"lo he configurado y no ha pasado nada"_ en dispositivos Apple. Antes de investigar la política, comprueba cómo se inscribió el dispositivo. --- ## Políticas de cuentas de usuario Source: https://docs.applivery.com/es/device-management/apple/apple-policies/user-account-policy/ Description: Políticas de cuentas de usuario en Applivery para iPads compartidos y Macs — gestiona las cuentas de usuario, aplica la seguridad y mantén operaciones eficientes. TL;DR: Applivery simplifica la gestión de cuentas de usuario en iPads y Macs compartidos permitiéndote crear y asignar políticas específicas por usuario. Answers: ¿Por qué es importante gestionar múltiples cuentas de usuario en un único dispositivo? · ¿Qué dispositivos admiten políticas de cuentas de usuario en Applivery? · ¿Cómo creo una política de cuentas de usuario en Applivery? · ¿Cómo añado configuraciones a una política de cuentas de usuario en Applivery? · ¿Cómo asigno una política de cuentas de usuario a un usuario en Applivery? · ¿Qué es la función iPad compartido? · ¿Qué ofrece Applivery para gestionar cuentas de usuario? Key topics: Gestión de dispositivos, Gestión de cuentas de usuario, Gestión de dispositivos Apple, Applivery, iPad compartido, Apple Gestionar eficazmente múltiples cuentas de usuario en un único dispositivo es fundamental para mantener las políticas de seguridad de una empresa. Aunque usar un dispositivo para varios usuarios puede optimizar la asignación de recursos, una mala gestión puede llevar a accesos no autorizados y brechas de datos. Por ejemplo, la función iPad compartido permite a las organizaciones gestionar fácilmente los dispositivos iOS utilizados por varios usuarios. Applivery ofrece una solución fluida para gestionar cuentas de usuario en iPads y Macs compartidos, garantizando tanto la seguridad como las operaciones eficientes. ### Crear una política de cuentas de usuario **Navegar a Políticas** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io), sigue los pasos para [crear una nueva política](https://docs.applivery.com/es/device-management/general-settings/create-policies/). Marca la casilla **Aplicar a las cuentas de usuario del dispositivo**. ![user account policy](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/2b210af0-18be-4588-8e40-00c2dbbe55a6.png) **Acceder a la página de resumen de la política** Serás redirigido a su página de resumen. Desde el botón **\+ Añadir configuración**, puedes aplicar todos los ajustes necesarios para tus usuarios específicos. **Asignar la política a los usuarios** Después de realizar estos cambios, encontrarás una lista de dispositivos asociados a los usuarios que tienen esta política aplicada en la parte inferior de la página. También puedes añadir nuevos usuarios haciendo clic en el botón **\+ Asignar a usuario del dispositivo**. ![assign policy](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/390d2577-1485-434a-a9ba-e0e1ff637692.png) :::warning Las políticas de cuentas de usuario solo se pueden asignar a iPads compartidos y dispositivos macOS. ::: --- ## Inscripción de dispositivos Source: https://docs.applivery.com/es/device-management/apple/enrollment/ Description: Inscripción Apple en Applivery — inscribe, configura y gestiona dispositivos iOS, iPadOS y macOS a escala desde un panel centralizado. TL;DR: Applivery simplifica la gestión de dispositivos Apple proporcionando un panel centralizado para inscribir, configurar y gestionar dispositivos iOS, iPadOS y macOS a escala. Answers: ¿Qué es la Gestión de dispositivos Apple en Applivery? · ¿Qué tipos de dispositivos Apple se pueden gestionar con Applivery? · ¿Qué pueden hacer los administradores con la Gestión de dispositivos Apple en Applivery? · ¿Dónde gestionan los administradores los dispositivos Apple en Applivery? · ¿Cuál es la principal ventaja de usar la Gestión de dispositivos Apple en Applivery? Key topics: Gestión de dispositivos Apple, Applivery, Inscripción iOS, Inscripción iPadOS, Inscripción macOS, Apple, iOS, iPadOS, macOS Inscribir un dispositivo Apple en Applivery lo registra en la plataforma MDM y aplica automáticamente las políticas, apps y ajustes de tu organización. Applivery admite todos los métodos de inscripción estándar de Apple, desde la instalación manual de perfiles hasta el despliegue sin intervención del usuario mediante Apple Business. Elige el método de inscripción para iOS, iPadOS y macOS adecuado para tu despliegue: DEP, Apple Configurator, inscripción por cuenta o inscripción manual. --- ## Inscripción de dispositivos basada en cuentas Source: https://docs.applivery.com/es/device-management/apple/enrollment/account-driven-device-enrollment/ Description: Inscripción de dispositivos basada en cuentas para dispositivos Apple corporativos sin Apple Business — cómo funciona y sus capacidades MDM. TL;DR: La Inscripción de dispositivos basada en cuentas ofrece una forma moderna de gestionar dispositivos Apple corporativos sin Apple Business, con un equilibrio entre los despliegues BYOD y los totalmente supervisados. Answers: ¿Qué es la Inscripción de dispositivos basada en cuentas? · ¿Qué dispositivos Apple son compatibles con la Inscripción de dispositivos basada en cuentas? · ¿Cómo se inscribe un dispositivo mediante la Inscripción de dispositivos basada en cuentas? · ¿Qué capacidades de gestión ofrece la Inscripción de dispositivos basada en cuentas? · ¿La Inscripción de dispositivos basada en cuentas activa la supervisión del dispositivo? · ¿Cómo separa los datos laborales y personales la Inscripción de dispositivos basada en cuentas? · ¿Cuándo debo usar la Inscripción de dispositivos basada en cuentas? · ¿Cuándo NO debo usar la Inscripción de dispositivos basada en cuentas? Key topics: Proceso de Inscripción de dispositivos basada en cuentas, Dispositivos compatibles y requisitos mínimos del SO, Capacidades de gestión, Separación de datos, Casos de uso y limitaciones, Apple, iOS 17, iPadOS 17, macOS 14 Sonoma, visionOS 1.1, MDM, Apple Business, Apple ID gestionado La Inscripción de dispositivos basada en cuentas es un método de inscripción introducido con iOS 17, iPadOS 17, macOS 14 y visionOS 1.1, diseñado para **dispositivos corporativos que no están registrados en Apple Business**. Permite a las organizaciones gestionar dispositivos con un amplio conjunto de capacidades MDM usando una cuenta Apple gestionada para autenticarse — sin necesidad de una configuración DEP ni de compartir un enlace de inscripción. Se sitúa entre la Inscripción de usuarios por cuenta (BYOD, capacidades MDM limitadas) y la Inscripción de dispositivos automatizada (zero-touch, totalmente supervisada) en términos de alcance de gestión y complejidad de despliegue. :::info Una cuenta Apple gestionada y una cuenta Apple personal pueden estar activas en el mismo dispositivo de forma simultánea, con separación total de los datos laborales y personales. ::: ### Dispositivos compatibles y requisitos mínimos del SO | Dispositivo | SO mínimo | | --- | --- | | iPhone | iOS 17 | | iPad | iPadOS 17 | | Mac | macOS 14 Sonoma | | Apple Vision Pro | visionOS 1.1 | ### ¿Cómo funciona la inscripción? Para inscribir un dispositivo, el usuario va a **Ajustes > General > VPN y gestión de dispositivos** (en iPhone/iPad) o **Configuración del sistema > General > Gestión de dispositivos** (en Mac) y selecciona el botón **Iniciar sesión en cuenta de trabajo o escuela**. Esto inicia un proceso de cuatro etapas: **Descubrimiento del servicio** El dispositivo usa el identificador organizativo del usuario (p. ej., `eliza@empresa.com`) para localizar automáticamente la URL de inscripción MDM de la organización consultando un recurso conocido en el dominio: ``` https:///.well-known/com.apple.remotemanagement ``` El servidor MDM responde con un documento JSON que indica el tipo de inscripción (`mdm-adde` para la Inscripción de dispositivos basada en cuentas) y la URL de inscripción. **Autenticación y token de acceso** El usuario se autentica en el servicio MDM con sus credenciales organizativas. Tras la autenticación correcta, el servicio MDM emite un **token de acceso seguro** que se almacena en el dispositivo y se usa en todas las solicitudes posteriores. Este token también permite verificar de forma continua la autorización del usuario durante todo el ciclo de vida de la inscripción. En iPhone, iPad y Apple Vision Pro, este proceso se puede agilizar con el **SSO de inscripción (inicio de sesión único)**, que reduce las solicitudes de autenticación repetidas y permite que la renovación del token se produzca automáticamente a través del proveedor de identidad de la organización. **Inscripción MDM** Con el token de acceso, el dispositivo recupera el perfil de inscripción del servicio MDM. Para completar la inscripción, el usuario debe **iniciar sesión con su cuenta Apple gestionada**. Una vez inscrito, la cuenta Apple gestionada aparece de forma destacada en Ajustes y en Configuración del sistema. **Autenticación continua** El token de acceso permanece activo después de la inscripción y se incluye en todas las solicitudes al servicio MDM. Esto permite al servicio verificar continuamente que el usuario inscrito sigue estando autorizado. Cuando el token caduca, es posible que se solicite al usuario que vuelva a autenticarse — o, si el SSO de inscripción está configurado, esto ocurre de forma transparente en segundo plano. ### ¿Qué pueden gestionar los administradores de TI? La Inscripción de dispositivos basada en cuentas ofrece un **conjunto más amplio de capacidades de gestión** que la Inscripción de usuarios por cuenta, lo que la hace adecuada para dispositivos corporativos. Las capacidades principales incluyen: | Capacidad | Disponible | | --- | --- | | Consultar número de serie e identificadores del dispositivo (UDID, IMEI) | ✅ | | Consultar lista de apps instaladas | ✅ | | Consultar zona horaria, número de teléfono y estado de itinerancia del dispositivo | ✅ | | Configurar VPN (todo el dispositivo) | ✅ | | Configurar VPN por app | ✅ | | Exigir y aplicar contraseña compleja | ✅ | | Borrar de forma remota todo el contenido y los ajustes | ✅ | | Aplicar actualizaciones de software | ✅ | | Gestionar FileVault (macOS) | ✅ | | Establecer nombre del dispositivo (macOS) | ✅ | | Gestionar Bloqueo de activación (macOS) | ✅ | | Instalación silenciosa de apps | ✅ | | Instalar y gestionar certificados | ✅ | | Configurar perfiles de Wi-Fi y correo electrónico | ✅ | | Gestionar Bloqueo de activación (iOS/iPadOS) | ❌ (requiere Inscripción de dispositivos automatizada) | | Configurar VPN siempre activa | ❌ (requiere Inscripción de dispositivos automatizada) | | Configurar proxy HTTP global | ❌ (requiere Inscripción de dispositivos automatizada) | | Establecer nombre del dispositivo (iOS/iPadOS) | ❌ (requiere Inscripción de dispositivos automatizada) | | Activar Modo Perdido | ❌ (requiere Inscripción de dispositivos automatizada) | ### Supervisión La Inscripción de dispositivos basada en cuentas **no activa la supervisión** en iPhone, iPad ni Apple Vision Pro. Sin embargo, en **ordenadores Mac con macOS 11 o posterior**, la inscripción de dispositivos — incluida la variante por cuenta — **sí aplica la supervisión automáticamente**. Esto significa que los dispositivos Mac inscritos de esta forma tienen acceso a capacidades de gestión exclusivas de supervisión que no están disponibles en dispositivos iOS/iPadOS inscritos por el mismo método. ### ¿Cómo se separan los datos laborales y personales? Cuando se completa la inscripción, el sistema operativo crea automáticamente claves de cifrado separadas en el dispositivo. Si el usuario da de baja el dispositivo, o si el servicio MDM lo da de baja de forma remota, el sistema operativo destruye esas claves y elimina criptográficamente todos los datos gestionados. El siguiente contenido se mantiene separado entre el contexto laboral y el personal: | Contenido | SO mínimo | | --- | --- | | Contenedores de datos de apps gestionadas | iOS 15, iPadOS 15, macOS 14, visionOS 1.1 | | Elementos del llavero | iOS 15, iPadOS 15, macOS 14, visionOS 1.1 | | App Correo (archivos adjuntos y cuerpo) | iOS 15, iPadOS 15, macOS 14, visionOS 1.1 | | App Notas | iOS 15, iPadOS 15, macOS 14, visionOS 1.1 | | App Calendario | iOS 16, iPadOS 16.1, macOS 13, visionOS 1.1 | | App Recordatorios | iOS 17, iPadOS 17, macOS 14, visionOS 1.1 | Además, si el usuario ha iniciado sesión con una cuenta Apple personal y una cuenta Apple gestionada, **Iniciar sesión con Apple** usa automáticamente la cuenta Apple gestionada para las apps gestionadas y la cuenta Apple personal para las no gestionadas — sin necesidad de selección manual. ### ¿Cuándo debo usar la Inscripción de dispositivos basada en cuentas? Este método es una buena opción cuando: - Los dispositivos son **propiedad de la empresa** pero no se adquirieron a través de Apple ni de un revendedor autorizado (y por tanto no son elegibles para la asignación automática DEP de Apple Business). - Necesitas **más control de gestión que con BYOD** (Inscripción de usuarios por cuenta), pero no tienes una configuración completa de Apple Business (DEP). - Quieres una **experiencia de inscripción moderna y sin fricciones** que no requiere compartir un enlace ni un código QR — solo iniciar sesión con una cuenta Apple gestionada. - Gestionas **ordenadores Mac** y quieres que la supervisión se aplique automáticamente sin un proceso de configuración física. **No se recomienda** cuando: - Necesitas que el dispositivo esté supervisado en iPhone o iPad (usa la Inscripción de dispositivos automatizada en su lugar). - Necesitas funciones como Modo Perdido, VPN siempre activa o proxy HTTP global en iOS/iPadOS. - El escenario de despliegue es BYOD (usa la Inscripción de usuarios por cuenta en su lugar). --- ## Inscripción de usuarios controlada por cuentas Source: https://docs.applivery.com/es/device-management/apple/enrollment/account-driven-user-enrollment/ Description: Inscripción de usuarios controlada por cuentas de Apple (UEMDM) — un método de inscripción BYOD que equilibra la seguridad corporativa con la privacidad del usuario, sus funciones y limitaciones. TL;DR: La Inscripción de usuarios de Apple ofrece una forma segura y centrada en la privacidad de gestionar dispositivos BYOD aislando los datos laborales y personales. Answers: ¿Qué es la Inscripción de usuarios controlada por cuentas? · ¿Qué problema resuelve la Inscripción de usuarios controlada por cuentas? · ¿Qué información del dispositivo está oculta para los MDM con la Inscripción de usuarios controlada por cuentas? · ¿Qué limitaciones de gestión de apps existen con la Inscripción de usuarios controlada por cuentas? · ¿Qué perfiles y configuraciones están disponibles con la Inscripción de usuarios controlada por cuentas? · ¿Qué comandos están restringidos con la Inscripción de usuarios controlada por cuentas? · ¿Por qué son importantes los Apple IDs gestionados para la Inscripción de usuarios controlada por cuentas? · ¿Cómo gestiona la separación de datos la Inscripción de usuarios controlada por cuentas? Key topics: Funciones de la Inscripción de usuarios, Separación de datos en la Inscripción de usuarios, Apple IDs gestionados, Limitaciones de la Inscripción de usuarios, Apple, iOS 13, macOS Catalina, MDM, Apple Business, VPP, APFS A partir de iOS 13 y macOS 10.15 Catalina, Apple introdujo un nuevo método de inscripción llamado Inscripción de usuarios. Con iOS 15 y macOS 14, Apple refinó este enfoque en lo que ahora se llama oficialmente **Inscripción de usuarios controlada por cuentas** — el método recomendado actualmente para escenarios BYOD. Este es un modo de inscripción notablemente diferente a los disponibles anteriormente mediante DEP, enlace de inscripción o modo supervisado de Apple. Aunque estos modos siguen existiendo, **la Inscripción de usuarios controlada por cuentas está pensada específicamente para escenarios de dispositivo personal (BYOD)** y requiere que el usuario se autentique con un Apple ID gestionado para completar el proceso de inscripción. :::warning La Inscripción de usuarios está aún en versión beta privada para un número limitado de clientes. Si quieres saber más, contacta con nosotros en [support@applivery.com](mailto:support@applivery.com). ::: ### ¿Por qué otro método de inscripción? Los métodos de inscripción y supervisión existentes son muy potentes. Los administradores pueden borrar, bloquear y restringir ampliamente el acceso en un dispositivo inscrito por DEP y supervisado. En macOS, los administradores pueden ejecutar cualquier tipo de comandos a nivel de root o scripts, y aplicar configuraciones muy intrusivas a nivel de dispositivo y de app. Además, pueden listar y obtener información detallada sobre los dispositivos, incluso sobre apps que no se han desplegado mediante una solución MDM. En otras palabras, los administradores tienen casi un control total sobre los dispositivos gestionados. **La Inscripción de usuarios controlada por cuentas busca resolver este caso de uso restringiendo lo que pueden hacer los MDM**. En lugar de tener acceso total a los dispositivos, **los espacios laboral y personal están aislados**. Los comandos y operaciones realizados por el MDM están limitados y restringidos al lado corporativo del dispositivo, ofreciendo un escenario más cómodo para los usuarios finales, que pueden acceder a los servicios corporativos sin sacrificar su privacidad. Esto proporciona **un escenario más equilibrado entre seguridad y privacidad, permitiendo a los usuarios pasar fácilmente de su vida laboral a la personal**. ### ¿Qué diferencia a este método de los demás? **Información del dispositivo:** El MDM ya no puede obtener información de identificación del dispositivo, como el número de serie, el identificador universal del dispositivo (UDID), el IMEI ni las direcciones Mac. En su lugar, el dispositivo proporciona un identificador anonimizado creado específicamente para la inscripción MDM. Si el dispositivo se da de baja del MDM y luego se vuelve a inscribir, se genera un nuevo identificador, manteniendo el anonimato del usuario final y del hardware. **Gestión de apps:** Los MDM pueden seguir instalando y eliminando apps, pero solo pueden ver información sobre las apps gestionadas. El resto de las apps instaladas por el usuario permanecen privadas y no serán visibles para el MDM, y no se pueden configurar como apps gestionadas. Además, algunas apps nativas son compatibles con los escenarios de Inscripción de usuarios controlada por cuentas, permitiendo aislar la información a nivel de app. **Perfiles y configuraciones:** Solo hay un conjunto limitado de perfiles y configuraciones disponibles que se pueden aplicar al dispositivo: - Wi-Fi. - VPN por app. - Perfiles de cuenta, como correo, calendario, contactos y Exchange/ActiveSync. **Comandos:** La Inscripción de usuarios controlada por cuentas también impide a los administradores establecer o borrar contraseñas, borrar el dispositivo y realizar otras configuraciones a nivel de dispositivo. ### Apple IDs gestionados e Inscripción de usuarios controlada por cuentas El método de Inscripción de usuarios controlada por cuentas se basa en los **Apple IDs gestionados** para la identificación y autenticación del usuario. Esto es lo que lo diferencia de la variante antigua basada en perfiles — el usuario inicia sesión activamente con su Apple ID gestionado organizativo para iniciar y completar la inscripción, sin necesidad de abrir un enlace ni instalar un perfil manualmente. Este enfoque también habilita dos funciones importantes: - **Licencias de apps y medios**: Las apps deben gestionarse a través de Apple Business y VPP para que se provean las licencias necesarias. - **Acceso a iCloud**: Apple proporciona servicios iCloud corporativos, como almacenamiento compartido para una organización. El Apple ID gestionado actúa como credencial para acceder a estos recursos. Recomendamos encarecidamente leer la documentación relacionada con los [Apple IDs gestionados](https://support.apple.com/en-gb/guide/deployment/depdc4ba8d82/web) para entender completamente las ventajas y funciones. ### ¿Cómo se gestiona la separación de datos? Como parte del proceso de Inscripción de usuarios controlada por cuentas, **se crea un nuevo volumen APFS separado en el dispositivo**. Este nuevo volumen funciona como un disco duro virtual con su propio cifrado y está **aislado de los demás volúmenes de datos del dispositivo**. Este volumen almacena todos los datos gestionados relacionados con la inscripción. **Cuando el dispositivo se da de baja, el volumen se borra**, eliminando todas las apps y datos gestionados y devolviendo el dispositivo a su estado original antes de la inscripción. --- ## Apple Configurator Source: https://docs.applivery.com/es/device-management/apple/enrollment/apple-configurator/ Description: Inscribe iPhones, iPads y Apple TVs en MDM usando Apple Configurator — supervisa dispositivos y añádelos a Apple Business. TL;DR: Inscribe dispositivos iOS en MDM y Apple Business usando Apple Configurator para Mac o iPhone, habilitando la supervisión de dispositivos y una gestión optimizada. Answers: ¿Para qué se usa Apple Configurator? · ¿Qué dispositivos puede inscribir Apple Configurator para Mac? · ¿Qué dispositivos puede inscribir Apple Configurator para iPhone? · ¿Requiere Apple Configurator para Mac un restablecimiento de fábrica? · ¿Qué es el periodo provisional de 30 días en Apple Configurator? · ¿Para qué se usa la URL de inscripción en Apple Configurator para Mac? · ¿Qué se requiere antes de inscribir con Apple Configurator para iPhone? · ¿Cómo emparejo dispositivos con Apple Configurator para iPhone? Key topics: Apple Configurator para Mac, Apple Configurator para iPhone, Inscripción MDM, Apple Business, Supervisión de dispositivos, Apple, Apple Configurator, MDM, Applivery, iPhone, iPad, Apple TV Apple Configurator es una herramienta creada por Apple que permite a los administradores añadir dispositivos a Apple Business e inscribirlos en una solución MDM como Applivery. Los dispositivos inscritos de esta manera están **supervisados** y se comportan de forma idéntica a los dispositivos adquiridos directamente a través de Apple Business — incluyendo la inscripción MDM obligatoria. :::warning La inscripción de dispositivos con Apple Configurator con supervisión habilitada requiere un **restablecimiento de fábrica**. Todos los datos existentes en el dispositivo se borrarán. ::: Apple Configurator está disponible en dos versiones: - **Apple Configurator para Mac**: Una app de macOS que inscribe **iPhone, iPad y Apple TV** (solo modelos con Ethernet) conectándolos mediante USB a un Mac. Añade dispositivos directamente a Apple Business y los prepara con supervisión e inscripción MDM en un único flujo de trabajo. - **Apple Configurator para iPhone**: Una app para iPhone que añade de forma inalámbrica **iPhone (iOS 16+), iPad (iPadOS 16.1+), Mac (macOS 12.0.1+, T2 o Apple Silicon) y Apple Vision Pro (visionOS 2.6+)** a Apple Business escaneando una imagen de emparejamiento durante el Asistente de configuración. No requiere cables ni hardware adicional. :::warning En ambos casos, una vez que un dispositivo se añade a Apple Business a través de Apple Configurator, existe un **periodo provisional de 30 días** durante el cual el usuario puede desvincular el dispositivo de Apple Business, la supervisión y la inscripción MDM. Después de esos 30 días, la gestión se vuelve permanente. ::: ### Inscribir un iPhone o iPad con Apple Configurator para Mac Este método es recomendable para la inscripción masiva de dispositivos **iPhone, iPad y Apple TV** que no están registrados en Apple Business. Requiere un Mac y un cable USB para cada dispositivo. #### Requisitos - Un Mac que ejecute Apple Configurator para Mac ([descarga desde la Mac App Store](https://apps.apple.com/us/app/apple-configurator-2/id1037126344)). - Una cuenta de Apple Business con el rol de Administrador o Gestor de inscripción de dispositivos. - Cable USB para cada dispositivo a inscribir. - La **URL de inscripción** de Applivery (en la sección **Configuración > Apple DEP**). **Preparar un perfil Wi-Fi** Antes de inscribir cualquier dispositivo, crea un perfil de configuración Wi-Fi para que los dispositivos inscritos puedan conectarse automáticamente a tu red: 1. En Apple Configurator para Mac, haz clic en **Archivo > Nuevo perfil**. 2. Selecciona **Wi-Fi** y haz clic en **Configurar**. 3. Introduce el SSID, la contraseña y el tipo de seguridad de tu red. 4. Guarda el perfil. ![configurator-Wi-Fi](https://www.applivery.com/wp-content/uploads/2022/06/configurator-wifi-1024x939.png "configurator-Wi-Fi | Applivery") **Conectar el dispositivo e iniciar la preparación** 1. Conecta el dispositivo al Mac mediante USB. Si se solicita en el dispositivo, toca **Confiar**. 2. Una vez que el dispositivo aparezca en Apple Configurator, selecciónalo y haz clic en **Preparar** en la barra de herramientas. ![apple-configurator-mac-prepare](https://www.applivery.com/wp-content/uploads/2022/06/apple-configurator-mac-prepare-1024x651.png "apple-configurator-mac-prepare | Applivery") **Configurar las opciones de preparación** En el Asistente de preparación, selecciona **Configuración manual** y configura las siguientes opciones: - **Añadir a Apple Business**: Actívalo si quieres que el dispositivo se añada a Apple Business y se inscriba a través de DEP. Esta es la opción recomendada para despliegues supervisados y gestionados. - **Activar y completar la inscripción**: Déjalo **desactivado** si el dispositivo requiere autenticación del usuario para completar la inscripción MDM — el dispositivo se detendrá en el Asistente de configuración y el usuario terminará el proceso. Actívalo solo si el dispositivo ya tiene un registro MDM y quieres prepararlo completamente sin interacción del usuario. - **Supervisar dispositivos:** Activa el modo supervisado del dispositivo, que desbloquea el conjunto completo de capacidades de gestión MDM. - **Permitir que los dispositivos se emparejen con otros ordenadores**: Función discontinuada desde iOS 13. - **Habilitar iPad compartido**: Si el iPad compartido estará habilitado o no. ![apple-configurator-manual](https://www.applivery.com/wp-content/uploads/2022/06/apple-configurator-manual-1024x651.png "apple-configurator-manual | Applivery") :::warning En algunos casos, puedes recibir el siguiente error inesperado: "Invalid Profile \[MCProfileErrorDomain – 0x3E8 (1000)\]". En ese caso, simplemente desmarca la opción **Activar y completar la inscripción** y prepara tu dispositivo de nuevo. ::: **Asignar a un servidor MDM** 1. Selecciona **Nuevo servidor…** para añadir Applivery como tu servidor MDM. 2. Introduce un nombre (p. ej., "Gestión de Dispositivos de Applivery") y pega tu **URL de inscripción** del panel de Applivery (**en la sección Configuración > Apple DEP**). 3. Haz clic en **Siguiente**. ![apple-configurator-new-server](https://www.applivery.com/wp-content/uploads/2022/06/apple-configurator-new-server-1024x651.png "apple-configurator-new-server | Applivery") ![enrollment url](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/498dcad4-7bc8-4a2b-abd2-9f8f5c1123bb.png) **Confiar en los certificados** Los certificados de anclaje de confianza se recuperan automáticamente. Si el proceso tarda demasiado, haz clic en **Siguiente** para omitirlo y continuar. Si seleccionaste **Añadir a Apple Business** en el Paso 3, se te pedirá que inicies sesión con tu cuenta gestionada de Apple Business. ![apple-configurator-trust-anchor](https://www.applivery.com/wp-content/uploads/2022/06/apple-configurator-trust-anchor-1024x651.png "apple-configurator-trust-anchor | Applivery") Si seleccionaste **Añadir a Apple Business** en el **Paso 3**, se te presentará una pantalla de inicio de sesión. Inicia sesión con tu cuenta de Apple Business y haz clic en **Siguiente**. **Crear o seleccionar una organización** Tras iniciar sesión en Apple Business, introduce los datos de tu organización o selecciona una existente. Esto vincula la identidad de supervisión a tu organización en Apple Configurator. ![apple-configurator-create-org](https://www.applivery.com/wp-content/uploads/2022/06/apple-configurator-create-org-1024x651.png "apple-configurator-create-org | Applivery") **Generar una identidad de supervisión** Selecciona **Generar una nueva identidad de supervisión**. ![apple-configurator-supervision-identity](https://www.applivery.com/wp-content/uploads/2022/06/apple-configurator-supervision-identity-1024x651.png "apple-configurator-supervision-identity | Applivery") También puedes configurar qué pasos del Asistente de configuración omitir para el usuario final (idioma, Wi-Fi, Apple ID, etc.). ![apple-configurator-skip-steps](https://www.applivery.com/wp-content/uploads/2022/06/apple-configurator-skip-steps-1024x651.png "apple-configurator-skip-steps | Applivery") **Seleccionar el perfil Wi-Fi** Selecciona el perfil Wi-Fi que creaste en el Paso 1 y haz clic en **Siguiente**. ![apple-configurator-network-profile](https://www.applivery.com/wp-content/uploads/2022/06/apple-configurator-network-profile-1024x651.png "apple-configurator-network-profile | Applivery") **Finalizar y preparar** Si habilitaste **Añadir a Apple Business**, introduce tus credenciales de Apple Business cuando se te solicite. Luego haz clic en **Preparar**. El proceso puede tardar unos minutos y el dispositivo puede reiniciarse varias veces — **no lo desconectes** hasta que Apple Configurator muestre una confirmación y el dispositivo esté en la pantalla de Bienvenida. ![apple-configurator-dep](https://www.applivery.com/wp-content/uploads/2022/06/apple-configurator-dep-1024x651.png "apple-configurator-dep | Applivery") :::tip Si necesitas inscribir varios dispositivos con la misma configuración, guarda tus ajustes como un **Blueprint** en Apple Configurator. Luego puedes aplicarlo directamente a nuevos dispositivos sin repetir todos los pasos. ::: ### Inscribir un iPhone o iPad con Apple Configurator para iPhone Apple Configurator para iPhone también puede añadir **iPhone (iOS 16+) y iPad (iPadOS 16.1+)** directamente a Apple Business — sin necesitar un Mac ni un cable USB. #### Requisitos - Un iPhone con iOS 16 o posterior y Apple Configurator para iPhone instalado. - Cuenta de Apple Business iniciada sesión en la App. - El iPhone o iPad de destino debe estar en el paso **Elige una red Wi-Fi** del Asistente de configuración (nuevo o restablecido de fábrica). **Iniciar sesión y configurar Apple Configurator para iPhone** 1. Abre la app Apple Configurator en tu iPhone. 2. Acepta los términos y condiciones. 3. Inicia sesión con tu **cuenta gestionada de Apple Business**. Puede ser necesaria la autenticación de dos factores. 4. En **Ajustes**, configura cómo el Mac se conectará a internet: - **Compartir Wi-Fi (predeterminado):** El Mac usa las mismas credenciales Wi-Fi que el iPhone. - **Perfil de configuración:** Usa un perfil Wi-Fi o 802.1X creado previamente almacenado en la app Archivos. - **Ethernet:** Conecta el Mac a internet mediante Ethernet antes de continuar. 5. Configura la **asignación del servicio de gestión de dispositivos** — puedes asignar dispositivos automáticamente al servicio MDM predeterminado o a uno específico en Apple Business, o dejarlo sin asignar para asignarlo manualmente más adelante. ![apple configurator for iphone](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/0d9b177e-473c-4f4a-be5a-d9b1dbed2ce2.png) **Preparar el iPhone o iPad de destino** Enciende el iPhone o iPad que quieres inscribir. Pasa por el Asistente de configuración y detente en la pantalla **Elige una red Wi-Fi**. :::warning Si pasas esta pantalla, necesitarás reiniciar el dispositivo. ::: **Emparejar los dispositivos** Acerca tu iPhone (con Apple Configurator abierto) al dispositivo de destino. Hay dos opciones de emparejamiento disponibles: - **Escanear la imagen:** Usa Apple Configurator para escanear la imagen de emparejamiento que se muestra en el Asistente de configuración en el dispositivo de destino. - **Emparejamiento manual:** Toca **Emparejar manualmente** en Apple Configurator en el dispositivo de destino, luego toca **Emparejamiento manual** en la App e introduce el código de 6 dígitos. El número de serie del dispositivo y la información se suben a Apple Business. ![apple configurator for iphone](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ede5b16e-ecc2-4efe-acb0-e3e484256f04.png) **Completar la asignación** Espera a que el proceso se complete, luego toca **Borrar y apagar**. El dispositivo ya está registrado en Apple Business. Si no se asignó automáticamente, dirígete a Apple Business y asigna manualmente el dispositivo a Applivery como su servicio MDM. **Inscribirse en Applivery a través de DEP** Enciende el dispositivo y pasa por el Asistente de configuración. Se inscribirá automáticamente en Applivery siguiendo el [proceso de inscripción DEP](https://docs.applivery.com/es/device-management/apple/enrollment/dep/) estándar. ### Inscribir un Mac con Apple Configurator para iPhone Este método te permite añadir un **Mac con Apple Silicon o chip T2** a Apple Business usando solo un iPhone — sin necesitar un Mac o cable USB. Una vez añadido a Apple Business, el Mac puede inscribirse en Applivery a través de DEP. #### Requisitos - Un iPhone con iOS 16 o posterior y [Apple Configurator para iPhone](https://apps.apple.com/us/app/apple-configurator/id1588794674) instalado. - Una cuenta de Apple Business con el rol de Administrador o Gestor de inscripción de dispositivos iniciada sesión en la App. - Un Mac con Apple Silicon o chip de seguridad T2 con macOS 12.0.1 o posterior. - El Mac debe estar en el paso **Selecciona tu país o región** del Asistente de configuración (nuevo o restablecido de fábrica). **Iniciar sesión en Apple Configurator para iPhone** 1. Abre la app Apple Configurator en tu iPhone. 2. Acepta los términos y condiciones. 3. Inicia sesión con tu **cuenta gestionada de Apple Business**. Puede ser necesaria la autenticación de dos factores. 4. En **Ajustes**, configura cómo el Mac se conectará a internet: - **Compartir Wi-Fi (predeterminado):** El Mac usa las mismas credenciales Wi-Fi que el iPhone. - **Perfil de configuración:** Usa un perfil Wi-Fi o 802.1X creado previamente almacenado en la app Archivos. - **Ethernet:** Conecta el Mac a internet mediante Ethernet antes de continuar. 5. Configura la **asignación del servicio de gestión de dispositivos**. ![apple configurator for iphone](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/48dead5d-b4c9-443a-b91d-9b2d35e1f808.png) **Preparar el Mac** Si el Mac es **nuevo**, enciéndelo, selecciona el idioma, haz clic en **Continuar** y detente en la pantalla **Selecciona tu país o región**. Si el Mac **ya ha sido configurado**, primero debes borrarlo: 1. Ve a **Menú Apple > Ajustes del sistema > General > Transferir o restablecer**. 2. Haz clic en **Borrar todo el contenido y ajustes** y sigue las instrucciones. 3. Una vez que el Mac se reinicie y llegue al Asistente de configuración, detente en **Selecciona tu país o región**. :::warning Borrar un Mac elimina permanentemente todos los datos. Asegúrate de tener una copia de seguridad actualizada antes de continuar. ::: **Emparejar el iPhone con el Mac** Acerca tu iPhone con Apple Configurator al Mac. Tienes dos opciones de emparejamiento: - **Escanear la imagen**: Usa la cámara de la app Apple Configurator para escanear la imagen de emparejamiento que se muestra en la pantalla del Asistente de configuración del Mac. - **Emparejamiento manual**: Haz clic en **Emparejar manualmente** en el Mac, luego toca **Emparejamiento manual** en Apple Configurator e introduce el código de 6 dígitos que se muestra en pantalla. Una vez emparejado, el número de serie del Mac y la información del dispositivo se suben automáticamente a Apple Business. ![pair mac](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/a711f1e6-9139-4d13-9201-498169ff0ba5.png) **Completar la asignación** Espera a que el proceso se complete. Cuando termine, toca **Apagar** en el iPhone (el Mac se apagará). El Mac ya está registrado en Apple Business. Si no configuraste la asignación MDM automática en el Paso 1, dirígete a tu portal de Apple Business, encuentra el dispositivo en el grupo **Apple Configurator** en Dispositivos y asígnalo manualmente a Applivery como su servicio MDM. ![pair success](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/485c4817-2a96-42ed-91bc-bcfbf61f1d02.png) **Inscribirse en Applivery a través de DEP** Con el Mac ahora registrado en Apple Business y asignado a Applivery, sigue el [proceso de inscripción DEP](https://docs.applivery.com/es/device-management/apple/enrollment/dep/) estándar para completar la inscripción. Cuando el Mac se encienda y pase por el Asistente de configuración, se inscribirá automáticamente en Applivery. --- ## Asignaciones por defecto Source: https://docs.applivery.com/es/device-management/apple/enrollment/default-assignments/ Description: Configura perfiles DEP y asignaciones de inscripción inteligente predeterminados para distintos tipos de dispositivos en Applivery usando Apple Business. TL;DR: Configura perfiles DEP y asignaciones de inscripción inteligente predeterminados para distintos tipos de dispositivos en Applivery usando Apple Business, para agilizar la inscripción de dispositivos. Answers: ¿Qué ventaja tiene vincular Apple Business con Applivery? · ¿Cómo accedo a la sección de configuración de Apple en Applivery? · ¿Dónde configuro las asignaciones por defecto de dispositivos en Applivery? · ¿Qué ocurre si elijo "ninguno" para un tipo de dispositivo en las asignaciones por defecto? · ¿Dónde introduzco los números de cliente o de revendedor de Apple? · ¿Cuánto tiempo tarda la verificación de los números de cliente de Apple? · ¿Cómo elijo el servidor MDM predeterminado para un tipo de dispositivo en Apple Business? · ¿Qué hago si falta el botón "Añadir" al introducir mi número de cliente de Apple? Key topics: Integración con Apple Business, Asignación de perfiles DEP, Configuración de inscripción inteligente, Gestión por tipo de dispositivo, Apple Business, Applivery, Perfil DEP, iPhone, iPad, Mac Si vinculas Apple Business con Applivery, podrás elegir el perfil DEP o las asignaciones de inscripción inteligente predeterminadas por tipo de dispositivo. Por ejemplo, podrás asignar los iPhone de tu organización a un perfil DEP y inscripción inteligente, y los iPad o los Mac a otros diferentes. ### Asignaciones por defecto en Applivery Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a la sección **Configuración** 1 y localiza **Configuración de Apple** 2 en el menú de la izquierda. ![configuración de apple](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/b6274fc5-da49-451c-b808-025df84bdf58.png) En la sección de asignación predeterminada, haz clic en los menús desplegables de tipo de dispositivo y elige el [**perfil DEP**](https://docs.applivery.com/es/device-management/apple/enrollment/dep/) y la [**Inscripción inteligente**](https://docs.applivery.com/es/device-management/apple/enrollment/smart-enrollment/) predeterminada para ese tipo de dispositivo. Si eliges "ninguno" para un tipo de dispositivo, deberás asignar esos dispositivos manualmente más adelante. ![asignación predeterminada](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/d89354f8-eff5-4225-973c-cc7e2b635c6d.png) ### Completa la configuración con Apple Business **Introduce los números de cliente y de revendedor** Antes de gestionar las asignaciones por defecto de dispositivos, debes introducir tus **números de cliente de Apple** o los **números de revendedor** de tu revendedor autorizado de Apple o proveedor participante. Una vez que hayas iniciado sesión en Apple Business, haz clic en **Dispositivos** 1 y selecciona **Inventario** en el menú de la izquierda. A continuación, selecciona **Números de cliente** y haz clic en el botón **Añadir** 3. ![número de revendedor](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/e5e93aa4-cd4c-4286-935b-7c357168780b.png) Aparecerá un modal donde podrás elegir si añadir un número de cliente de Apple o un número de revendedor. Cuando introduzcas tus números de cliente de Apple, omite los ceros iniciales. Si el botón Añadir no aparece o está atenuado, es posible que la información ya esté guardada. :::warning El número de cliente o de revendedor de Apple que introduzcas aparecerá como pendiente. Ten en cuenta que la verificación y aprobación de los números de cliente puede tardar hasta cinco días. ::: **Elige las asignaciones por defecto de dispositivos** Ahora ve a la sección **Servicios de gestión** 4 y selecciona **Asignación predeterminada de dispositivos** 5. Haz clic en los menús desplegables de tipo de dispositivo y elige el servidor MDM predeterminado para ese tipo de dispositivo. Si eliges "Sin asignar" para un tipo de dispositivo, deberás asignar esos dispositivos manualmente más adelante. ![asignación predeterminada de dispositivos](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/39bf7fb8-9261-48fb-a9bd-03cb7145b5a1.png) --- ## DEP Source: https://docs.applivery.com/es/device-management/apple/enrollment/dep/ Description: Configura el DEP de Apple con Applivery para la inscripción automatizada de dispositivos mediante Apple Business — agiliza la gestión de dispositivos iOS y macOS. TL;DR: Configura el DEP de Apple en Applivery mediante Apple Business para automatizar y simplificar la inscripción de dispositivos Apple. Answers: ¿Qué es el Programa de inscripción de dispositivos Apple (DEP)? · ¿Cuáles son los requisitos previos para configurar el DEP de Apple en Applivery? · ¿Cómo configuro un nuevo servidor MDM en Apple Business para Applivery? · ¿Qué es un perfil DEP en Applivery? · ¿Cómo creo un perfil DEP en Applivery? · ¿Con qué frecuencia sincroniza Applivery con Apple Business? · ¿Cómo asigno un perfil DEP a un dispositivo en Applivery? · ¿Qué hago si mi dispositivo Apple se encendió antes de la inscripción DEP? Key topics: Programa de inscripción de dispositivos Apple (DEP), Configuración de Apple Business, Configuración del MDM de Applivery, Creación y asignación de perfiles DEP, Inicialización e inscripción de dispositivos, Apple, Applivery, Apple Business, DEP, MDM, iOS, macOS El Programa de inscripción de dispositivos Apple (también conocido como DEP) es una herramienta integrada en Apple Business que permite a las organizaciones automatizar completamente el proceso de inscripción de dispositivos Apple en soluciones MDM como Applivery. En sus inicios, se centraba en los nuevos dispositivos, pero a partir de iOS 11, también admite la inscripción de dispositivos ya adquiridos. El DEP ayuda a las organizaciones a activar la supervisión, la inscripción MDM, omitir pasos de configuración y muchas otras funciones. :::info **Si ves `code: 5096`**, reintenta la operación primero: lo habitual es que se resuelva solo. Si persiste, comprueba que el token DEP siga siendo válido y que el dispositivo esté asignado al servidor MDM correcto. ::: ### Cómo configurar el Programa de inscripción de dispositivos Apple (DEP) en Applivery Applivery ofrece una integración perfecta con el [Programa de compras por volumen Apple (VPP)](https://docs.applivery.com/es/device-management/apple/app-management/vpp/) para comprar licencias de apps y libros e instalar apps privadas de empresa en dispositivos Apple gestionados con iOS y macOS. Hay algunos requisitos previos que debes tener en cuenta: 1. Ya tienes una cuenta aprobada de [Apple Business](https://business.apple.com/) para tu organización. 2. Tienes una **licencia activa de Gestión de dispositivos Apple de Applivery**. **Configurar un nuevo servidor MDM en Apple Business** Inicia sesión en el [**panel de Applivery**](https://dashboard.applivery.io), navega a la sección **Configuración** 1 y localiza la sección **Apple DEP** 2 en el menú lateral izquierdo. Luego haz clic en el botón **Descargar clave pública** 3. ![mdm server](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/edc96d80-73f5-4771-a17c-1f33570ba5fd.png) Se descargará un archivo llamado `Applivery DEP PublicKey (NOMBRE ORG).cer`. **Crear un nuevo servidor MDM en Apple Business** 1. Inicia sesión en [Apple Business](https://business.apple.com/) como usuario con el rol de Administrador o Gestor de contenido. 2. Haz clic en **Dispositivos** 1 y selecciona **Servicios de gestión** 2 en el menú lateral izquierdo. 3. Haz clic en el botón **Añadir** en **Añadir servicio de gestión de dispositivos** 3. ![add device management service](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/bd475d33-9e8c-43bc-a6f5-4e105e6b68da.png) Selecciona la opción **Conectar gestión de dispositivos externa**, asigna un nombre al nuevo servidor MDM, marca **Permitir que este servicio libere dispositivos** y haz clic en **Subir certificado**. Por último, selecciona y sube el archivo _.cer_ que descargaste en el Paso 1. Luego haz clic en **Siguiente**. ![add device management service](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/577a9f6b-2aba-4f11-8521-fa0146621bec.png) En el siguiente paso, podrás **descargar el token** y se descargará un archivo `.p7m`. ![download service token](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/d43e7bb8-152b-46dd-a0fb-bc49dfa5f1b1.png) Ahora vuelve al panel de Applivery y desplázate hasta el paso 5 del proceso de configuración. Haz clic en el botón Seleccionar y sube el archivo `.p7m` que descargaste de Apple Business en el paso anterior. Luego haz clic en Finalizar configuración. ![finish setup](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/8e8754b2-8c1e-47e6-b53d-d3e7a825eb49.png) **Crear un perfil DEP** Los perfiles DEP definen cómo se inscribirán los nuevos dispositivos en el MDM de Applivery y la configuración inicial de esos dispositivos Apple. Te permiten configurar pantallas de configuración, multiusuario o modo de supervisión, además de otras funciones. ¡Empecemos! Haz clic en Perfiles DEP. ![dep profiles](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/f28d3566-4a0e-4cef-ba4f-f8d28e7c8e53.png) Se abrirá una vista modal con las siguientes opciones: 1. Ver todos los perfiles DEP existentes. 2. Crear un nuevo perfil DEP. Luego haz clic en el botón **\+ Crear perfil DEP**. Al crear el perfil, puedes asignarle un nombre para futuras referencias y seleccionar las **opciones de inscripción** deseadas. ![dep profile form](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/3abc7b6b-ff1f-4e22-a9cf-c963a693e4d4.png) Opcionalmente, también puedes especificar información adicional para el perfil, como el departamento, información de contacto de soporte, idioma o región. ![dep configuration section](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/b16bd9fc-048c-4dc7-b229-bf5770cb5067.png) Por último, puedes seleccionar los pasos de configuración que deseas omitir durante el aprovisionamiento del dispositivo. Por defecto, todos estarán deseleccionados para que se muestre el proceso de configuración estándar. Una vez listo, haz clic en el botón Guardar para finalizar. ![skip setup items](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/67b5ee77-7885-4ef2-88d2-7332220686c0.png) El nuevo perfil DEP se añadirá a la lista y estará listo para asignarse a nuevos dispositivos. **Sincronizar con Apple Business** Ahora que tu cuenta de Applivery y tu cuenta de Apple Business están conectadas, puedes sincronizarlas para recuperar todos los nuevos dispositivos que se han añadido a Apple Business y configurarlos. Simplemente haz clic en el botón Sincronizar con Apple Business para iniciar el proceso de sincronización y obtener las últimas actualizaciones de Apple Business. Los nuevos dispositivos se añadirán a la lista inferior. :::info El botón **Sincronizar con Apple Business** se ha incluido aquí para que puedas activar manualmente un proceso de sincronización con Apple Business, pero este es un proceso que se activará automáticamente cada hora en tu nombre. ::: **Asignar perfiles DEP a nuevos dispositivos** Ahora que los nuevos dispositivos están correctamente sincronizados con Applivery, puedes empezar a asignar perfiles DEP a esos dispositivos para que finalmente puedan inscribirse en Applivery. Sigue estos pasos: 1. En la lista de dispositivos, haz clic en el dispositivo. Se abrirá una vista lateral. 2. Usa el botón Configurar para mostrar el menú desplegable y elegir un perfil DEP. 3. Haz clic en el botón **Asignar**. Una vez asignado, el dispositivo pasará por los siguientes estados: - **Asignado**: El perfil de inscripción se ha asignado al dispositivo, pero aún no se ha aplicado al dispositivo físico. - **Enviado**: El perfil de inscripción se ha aplicado correctamente al dispositivo. Tenlos en cuenta antes de pasar al siguiente paso, ya que este es un proceso asíncrono que puede tardar unos minutos según la API de Apple. **Inicializar el dispositivo** Ahora que tus dispositivos han sido asociados a un perfil de inscripción en Applivery, es hora de encenderlos: 1. Enciende tu dispositivo por primera vez. El dispositivo puede hacer algunas preguntas de configuración iniciales. 2. Selecciona una red Wi-Fi con acceso a internet, ya que es necesaria para completar el proceso de check-in del DEP de Apple. 3. A continuación, el dispositivo recibirá la configuración del perfil DEP y seguirá los ajustes que creaste. 4. Una vez completado el proceso de configuración, el dispositivo aparecerá en la sección **Dispositivos** del panel de Applivery. :::warning Si el dispositivo se encendió y configuró antes de añadirse a Apple Business, habrá perdido el check-in del DEP en el primer arranque. La solución estándar es un restablecimiento de fábrica: ve a **Ajustes > General > Restablecer** y selecciona **Borrar contenido y ajustes**. Para dispositivos macOS, si necesitas evitar borrarlos, existe una alternativa — consulta [Activar la inscripción DEP en un Mac ya configurado](https://docs.applivery.com/es/device-management/apple/macos/troubleshooting/force-dep-enrollment/). ::: --- ## Métodos de inscripción Source: https://docs.applivery.com/es/device-management/apple/enrollment/enrollment-methods/ Description: Métodos de inscripción Apple en Applivery — DEP, inscripción por cuenta, inscripción manual y Apple Configurator para dispositivos iOS y macOS. TL;DR: Inscribe tus dispositivos Apple en Applivery usando métodos como Inscripción de usuario, Apple Configurator o DEP para una gestión mejorada. Answers: ¿Qué métodos de inscripción de dispositivos Apple están disponibles en Applivery? · ¿Para qué sirve la Inscripción de usuario por cuenta? · ¿Qué es la Inscripción automatizada de dispositivos (DEP) y cuándo debo usarla? · ¿Qué significa 'supervisado' en la inscripción de dispositivos Apple? · ¿Qué métodos de inscripción de dispositivos Apple permiten perfiles MDM no eliminables? · ¿Cuándo usaría Apple Configurator para iPhone para la inscripción de dispositivos? · ¿Qué es la Inscripción de dispositivo por cuenta? · ¿Qué es la Inscripción de dispositivo basada en perfil? Key topics: Inscripción de dispositivos Apple, Gestión de dispositivos móviles, MDM, Apple, Applivery, Apple Configurator, DEP, Inscripción de usuario Una vez configurada tu [empresa de Apple](https://docs.applivery.com/es/device-management/apple/get-started/), puedes empezar a inscribir tus dispositivos Apple en Applivery. Veamos los métodos de inscripción disponibles. :::info Si necesitas dar de alta a varias personas a la vez, puedes invitarlas todas de una vez con una [inscripción masiva](https://docs.applivery.com/es/device-management/general-settings/bulk-enrollment/). ::: ### Opciones de inscripción Apple proporciona múltiples formas de inscribir dispositivos según tu caso de uso, el tipo de propiedad del dispositivo (empresa o BYOD) y el nivel de control que necesitas sobre el dispositivo. Todos los métodos de inscripción dan como resultado que el dispositivo sea gestionado por Applivery, pero difieren en dos aspectos clave: - **Supervisión**: Los dispositivos supervisados otorgan a los administradores un control significativamente mayor sobre el dispositivo, incluyendo restricciones, instalación silenciosa de apps y configuraciones avanzadas. Generalmente está destinado a dispositivos de empresa. Puedes obtener más información [aquí](https://docs.applivery.com/es/device-management/apple/supervision/). - **MDM no eliminable**: Algunos métodos de inscripción permiten bloquear el perfil MDM para que el usuario no pueda eliminarlo, garantizando que el dispositivo siempre permanezca gestionado. #### Inscripción de usuario por cuenta Diseñada para **escenarios BYOD**. El usuario se autentica con un Apple ID gestionado para inscribir su dispositivo personal. Proporciona una separación clara entre los datos personales y de trabajo, y otorga a la organización una visibilidad limitada sobre el dispositivo, protegiendo la privacidad del usuario. El dispositivo **no está supervisado** y el usuario puede eliminar el perfil MDM. Puedes obtener más información [aquí](https://docs.applivery.com/es/device-management/apple/enrollment/account-driven-user-enrollment/). #### Inscripción de dispositivo por cuenta Un método más reciente (disponible desde iOS 17 y macOS 14) para **dispositivos de empresa que no están registrados en Apple Business**. Usa autenticación por cuenta y proporciona más capacidades de gestión que la Inscripción de usuario. Los Mac inscritos de esta forma están supervisados, pero iPhone, iPad y Apple Vision Pro no. Puedes obtener más información [aquí](https://docs.applivery.com/es/device-management/apple/enrollment/account-driven-device-enrollment/). #### Inscripción de dispositivo basada en perfil El **método de inscripción manual clásico** se realiza normalmente compartiendo un enlace o código QR que el usuario abre en Safari. No requiere Apple Business. Los Mac están supervisados al inscribirse, pero iPhone, iPad y Apple TV no. El usuario puede eliminar el perfil MDM. Puedes obtener más información [aquí](https://docs.applivery.com/es/device-management/apple/enrollment/manual-enrollment/). #### Inscripción automatizada de dispositivos (DEP) El método de inscripción más potente, diseñado para **despliegues corporativos sin intervención del usuario**. Los dispositivos se registran en Apple Business y se inscriben automáticamente durante la configuración inicial — sin ninguna interacción del usuario. Todos los dispositivos están supervisados y el usuario no puede eliminar el perfil MDM, lo que lo convierte en el método recomendado para dispositivos de empresa. Puedes obtener más información [aquí](https://docs.applivery.com/es/device-management/apple/enrollment/dep/). #### Apple Configurator para Mac Permite la inscripción **conectando físicamente el dispositivo a un Mac** que ejecuta Apple Configurator mediante USB. Permite la supervisión sin requerir Apple Business, aunque los dispositivos inscritos de esta manera tienen un periodo provisional de 30 días durante el cual el usuario aún puede eliminar el perfil MDM. Admite iPhone, iPad y Apple TV (solo modelos con Ethernet). #### Apple Configurator para iPhone Permite añadir **iPhone, iPad, Mac (chip T2 o Apple Silicon) y Apple Vision Pro** a Apple Business usando un iPhone con la app Apple Configurator — sin necesitar un Mac. El dispositivo se inscribe escaneando una imagen de emparejamiento durante el Asistente de configuración. Una vez añadidos a Apple Business, los dispositivos están supervisados, aunque existe un periodo provisional de 30 días durante el cual el usuario aún puede desvincularse de la gestión. Puedes obtener más información sobre la Inscripción con Apple Configurator [aquí](https://docs.applivery.com/es/device-management/apple/enrollment/apple-configurator/). ### Métodos de inscripción | Método de inscripción | Dispositivos compatibles | Versión mínima del OS | ¿Supervisado? | ¿MDM no eliminable? | Caso de uso típico | | --- | --- | --- | --- | --- | --- | | **Inscripción de usuario por cuenta** | iPhone, iPad, Mac, Apple Vision Pro | iOS 15, iPadOS 15, macOS 14, visionOS 1.1 | ❌ | ❌ | BYOD | | **Inscripción de dispositivo por cuenta** | iPhone, iPad, Mac, Apple Vision Pro | iOS 17, iPadOS 17, macOS 14, visionOS 1.1 | ❌ (iPhone, iPad, Vision Pro) ✅ (Mac) | ❌ | Empresa, sin DEP | | **Inscripción de dispositivo basada en perfil** | iPhone, iPad, Mac, Apple TV | iOS 4, iPadOS 13.1, macOS 10.7, tvOS 9 | ❌ (iPhone, iPad, Apple TV) ✅ (Mac) | ❌ | Inscripción manual por enlace o perfil | | **Inscripción automatizada de dispositivos (DEP)** | iPhone, iPad, Mac, Apple TV, Apple Watch, Apple Vision Pro | iOS 13, iPadOS 13.1, macOS 10.14.4, tvOS 13, watchOS 10, visionOS 2.0 | ✅ | ✅ | Empresa, despliegue sin intervención | | **Apple Configurator para Mac** | iPhone, iPad, Apple TV (solo Ethernet) | macOS (anfitrión) | ✅ | ❌ (periodo provisional de 30 días) | Añadir dispositivos a Apple Business sin compra DEP | | **Apple Configurator para iPhone** | iPhone (iOS 16+), iPad (iPadOS 16.1+), Mac (macOS 12.0.1+, T2/Apple Silicon), Apple Vision Pro (visionOS 26+) | iOS 16 (anfitrión) | ✅ | ❌ (periodo provisional de 30 días) | Añadir dispositivos a Apple Business sin un Mac | --- ## Inscripción manual Source: https://docs.applivery.com/es/device-management/apple/enrollment/manual-enrollment/ Description: Inscribe dispositivos Apple en Applivery manualmente usando enlaces de inscripción y el sitio de inscripción — cubre dispositivos iOS y macOS. TL;DR: Inscribe dispositivos Apple en el MDM de Applivery usando enlaces de inscripción o el sitio de inscripción con esta guía paso a paso. Answers: ¿Qué es la inscripción manual para dispositivos Apple? · ¿Necesito Apple Business para la inscripción manual? · ¿Pueden los usuarios eliminar el perfil MDM con la inscripción manual? · ¿Se aplica supervisión automáticamente en macOS con la inscripción manual? · ¿Qué navegador se requiere para la inscripción manual en iOS/iPadOS? · ¿Cómo instalo el perfil tras descargarlo en macOS? · ¿Cuáles son las dos opciones para distribuir el perfil de inscripción? · ¿Dónde encuentro el perfil instalado en iOS/iPadOS? Key topics: Inscripción de dispositivos Apple, Configuración MDM, Proceso de enlace de inscripción, Proceso del sitio de inscripción, Panel de Applivery, Applivery, Apple, iOS, Apple Configurator, Apple DEP La Inscripción manual (Inscripción de dispositivo basada en perfil) es el método de inscripción manual tradicional para dispositivos Apple. Funciona entregando un perfil de configuración MDM directamente al dispositivo — mediante un enlace, código QR o un sitio de inscripción dedicado — que el usuario instala desde los Ajustes del dispositivo. Es una de las opciones de inscripción más flexibles ya que **no requiere ninguna configuración de Apple Business** y funciona en cualquier iPhone, iPad, Mac o Apple TV. Sin embargo, no bloquea el perfil MDM en el dispositivo, lo que significa que el **usuario puede eliminarlo en cualquier momento**. **Supervisión y Mac:** En ordenadores Mac con macOS 11 o posterior, la Inscripción de dispositivo basada en perfil **aplica automáticamente la supervisión**, lo que desbloquea un conjunto de capacidades de gestión significativamente más amplio en comparación con los dispositivos iOS y iPadOS inscritos de la misma manera. :::info Este método es adecuado tanto para dispositivos de empresa como personales donde Apple Business o DEP no están disponibles. Para un despliegue completamente bloqueado, supervisado y sin intervención del usuario, considera usar la [Inscripción automatizada de dispositivos (DEP)](https://docs.applivery.com/es/device-management/apple/enrollment/dep/). ::: ### Requisitos - Una [empresa de Apple configurada en Applivery](https://docs.applivery.com/es/device-management/apple/get-started/). - Al menos una [política de dispositivo creada](https://docs.applivery.com/es/device-management/general-settings/create-policies/). - El dispositivo de destino debe abrir el enlace de inscripción en **Safari** (otros navegadores no son compatibles con la instalación de perfiles en iOS/iPadOS). ### Inscripción manual (código o QR) Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), navega a **Dispositivos** y haz clic en **\+ Inscribir dispositivo**. Rellena el formulario de la siguiente manera: **Configurar los ajustes de inscripción** - **Plataforma:** Asegúrate de elegir **Apple** en Plataforma. - **Empleado del dispositivo:** Usuario propietario del dispositivo. Puedes crear un nuevo empleado introduciendo la dirección de correo electrónico. - **Política:** Elige la política que se aplicará al dispositivo. Puedes hacerlo en Políticas si aún no la has creado. Alternativamente, puedes crear una nueva política aquí y configurarla más adelante. - **Etiquetas**: Define etiquetas para organizar, agrupar y filtrar dispositivos de forma eficiente. - **Nombre para mostrar (opcional):** Un nombre descriptivo para identificar fácilmente el dispositivo entre los demás. - **Expira después de:** El tiempo de expiración del token de inscripción que se generará. - **Ubicación VPP**: Define la ubicación para recuperar tus apps con licencia VPP. - **Omitir información personal**: Para evitar recopilar información sobre apps personales y ubicación de red. - **Enviar correo con instrucciones al empleado (opcional):** Elige si quieres enviar una notificación al usuario, incluyendo las instrucciones de inscripción que variarán según el modo de inscripción. ![enrollment form](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/0b9c7789-91f6-4497-a2db-1d73611a96c1.png) **Inscribir el dispositivo** Una vez enviado el formulario, se te presentarán dos opciones para entregar el perfil de inscripción al dispositivo: **Sitio de inscripción (recomendado para flujos de trabajo compartidos)** Un sitio web alojado que requiere que el usuario introduzca un código de inscripción antes de descargar el perfil. Esto añade una capa de seguridad, ya que el enlace solo no es suficiente para inscribirse. 1. Comparte la URL de inscripción y el código de inscripción con el usuario (o escanea el código QR). 2. El usuario abre el enlace en **Safari** en el dispositivo de destino. 3. Introduce el código de inscripción y toca **Continuar**. 4. Toca **Inscribir** para descargar el perfil de configuración. 5. En el dispositivo, dirígete a **Ajustes > General > VPN y gestión de dispositivos**. 6. Encuentra el perfil de Applivery y toca **Instalar**. 7. De vuelta en el panel de Applivery, haz clic en **Confirmar inscripción** para verificar que el dispositivo se ha inscrito correctamente. Si tiene éxito, serás redirigido a la vista de detalles del dispositivo. **Enlace de inscripción (descarga directa del perfil)** Una URL directa que descarga inmediatamente el perfil de configuración cuando se abre. Más sencillo de compartir pero sin la capa de protección del código. 1. Comparte el enlace de inscripción con el usuario (o escanea el código QR). 2. El usuario abre el enlace en **Safari** en el dispositivo de destino. El perfil se descarga automáticamente. 3. En el dispositivo, dirígete a **Ajustes > General > VPN y gestión de dispositivos**. 4. Encuentra el perfil de Applivery y toca **Instalar**. 5. De vuelta en el panel de Applivery, haz clic en **Confirmar inscripción** para verificar que el dispositivo se ha inscrito correctamente. Si tiene éxito, serás redirigido a la vista de detalles del dispositivo. :::info **Nota para macOS:** Tras descargar el perfil, los usuarios deben ir a **Ajustes del sistema > Privacidad y seguridad > Perfiles** para instalarlo, ya que macOS no instala perfiles automáticamente. ::: Selecciona tu opción preferida, junto con el tipo de dispositivo que vas a inscribir, y procede con los pasos. ![enrollment instructions](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/cd74ba4a-ccce-4207-b085-550f1563669f.png) --- ## Migración de dispositivos Source: https://docs.applivery.com/es/device-management/apple/enrollment/migrate-apple-devices/ Description: Migra dispositivos Apple a Applivery desde una solución MDM existente usando Apple Business — sin restablecimiento de fábrica. TL;DR: Migra tus dispositivos Apple a Applivery de forma fluida usando Apple Business, conservando datos y apps sin restablecimiento de fábrica. Answers: ¿Qué sistemas operativos de Apple son compatibles con este proceso de migración MDM? · ¿Qué roles son necesarios en Apple Business para realizar la migración MDM? · ¿Puedo migrar dispositivos iOS e iPadOS sin restablecimiento de fábrica? · ¿Qué ocurre si un dispositivo no cumple los requisitos para la migración MDM en Apple Business? · ¿Cómo asigno un dispositivo a Applivery en Apple Business para la migración? · ¿Cuánto tiempo puedo establecer como plazo de migración en Apple Business? · ¿Qué ocurre con el Bloqueo de activación durante el proceso de migración MDM? · ¿Cómo cancelo una migración MDM en Apple Business? Key topics: Migración MDM, Apple Business, Inscripción de dispositivos, Applivery, iOS, iPadOS, macOS Este proceso permite a las organizaciones mantener la continuidad del negocio durante la transición segura de la gestión, conservando apps y datos, y minimizando la interrupción para los usuarios. Es aplicable a dispositivos con **iOS 26**, **iPadOS 26** o **macOS 26**, y está pensado para usuarios con el rol de **Administrador** o **Gestor de inscripción de dispositivos** en Apple Business. :::info Puedes obtener más información sobre los roles y privilegios en Apple Business en este [enlace](https://support.apple.com/en-gb/guide/apple-business-manager/axm97dd59159/web). ::: ### Descripción general Apple Business permite transiciones fluidas entre soluciones MDM — ideal para organizaciones que pasan de la gestión local a la nube, que consolidan dispositivos tras una fusión, o que cambian de proveedor. Las principales funciones de migración incluyen: - Establecer un plazo de migración (1–90 días). - Conservar las apps y los datos gestionados en iPhone y iPad. - Gestionar los ajustes del Bloqueo de activación. - Forzar la migración mediante reinicios del dispositivo cuando los usuarios no actúan. - Cancelar migraciones antes de que comiencen, devolviendo los dispositivos al MDM original. - Migrar dispositivos iOS e iPadOS **sin restablecimiento de fábrica**. ### Requisitos Los dispositivos deben cumplir las siguientes condiciones para ser elegibles para la migración: - Ejecutar **iOS 26**, **iPadOS 26** o **macOS 26**. - Ser **propiedad de la organización** e inscritos mediante **Inscripción de dispositivos automatizada (ADE)**. - Para macOS 26, también se admite la **inscripción basada en perfil**. - Los dispositivos inscritos mediante **Apple Configurator** deben haber superado el **periodo provisional de 30 días**. :::warning Si no se cumplen estas condiciones, la opción de plazo de migración no aparecerá en Apple Business y las acciones de migración masiva fallarán, tal como quedará registrado en el registro de actividad de Apple Business. ::: ### Antes de empezar **Prepara el panel de Applivery** Antes de iniciar la migración, asegúrate de que tu entorno de Applivery está correctamente configurado: El primer paso es crear tu **cuenta Apple Enterprise** subiendo tu **certificado de Apple Push** a Applivery. Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a la sección **Configuración de Apple** 1 dentro de Configuración y sigue los pasos de [Primeros pasos](https://docs.applivery.com/es/device-management/apple/get-started/). Una vez configurada tu cuenta Apple Enterprise, el siguiente paso es configurar la integración con **Apple Business**. Empieza conectando tus tokens de **DEP** y **VPP**, lo que permitirá a Applivery importar tus dispositivos y gestionar las licencias de apps automáticamente. Para conectar tu token **DEP**, sigue [DEP](https://docs.applivery.com/es/device-management/apple/enrollment/dep/). Para configurar las licencias **VPP**, sigue [VPP](https://docs.applivery.com/es/device-management/apple/app-management/vpp/). Una vez completado esto, puedes empezar a crear **perfiles DEP** y [asignarlos como predeterminados](https://docs.applivery.com/es/device-management/apple/enrollment/default-assignments/) para cualquier dispositivo inscrito a través de Apple Business. Si aplica, configura una [**Inscripción inteligente**](https://docs.applivery.com/es/device-management/apple/enrollment/smart-enrollment/) como predeterminada para los dispositivos de Apple Business. Por último, asegúrate de que todas las **políticas de dispositivos** incluyen las apps gestionadas previamente instaladas para evitar pérdidas de datos durante la migración. **Proceso de migración** Inicia sesión en [Apple Business](https://business.apple.com/) como Administrador o Gestor de inscripción de dispositivos, dirígete a la sección **Dispositivos** y selecciona el **dispositivo de destino**. Selecciona **Asignar gestión de dispositivos** y elige **Applivery** como MDM de destino. Opcionalmente, puedes **establecer un plazo de migración** (1–90 días); si esta opción no está disponible, el dispositivo no cumple los requisitos de migración. Una vez verificados todos los ajustes, haz clic en **Confirmar** para continuar. ![asignar gestión de dispositivos](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/80d64054-543b-49bb-b5eb-a207229a86de.png) :::info También puedes seleccionar varios dispositivos para la migración manteniendo pulsada la tecla Comando mientras haces clic en los dispositivos deseados. ::: **Sincronizar con Apple Business** De vuelta en el panel de Applivery, haz clic en el botón **Sincronizar con Apple Business** para iniciar el proceso de sincronización y obtener las últimas actualizaciones de Apple Business. Los nuevos dispositivos añadidos aparecerán en la lista de abajo. ![sincronizar con apple business](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/b30f7c2c-ed6a-4940-8328-d2aedcaa0ffe.png) :::info Tras la sincronización, los dispositivos empiezan a recibir notificaciones que piden a los usuarios que inicien la migración. Estas aumentan en frecuencia a medida que se acerca el plazo — recordatorios diarios, luego alertas cada hora durante las últimas 24 horas, y notificaciones de cuenta atrás en la última hora. Si un dispositivo pierde la conexión después de darse de baja, aparecerá un selector de Wi-Fi para continuar con la configuración. ::: **Experiencia del usuario final** ##### **Notificación inicial** Los usuarios reciben una notificación de que ha comenzado la migración a Applivery. Pueden elegir **Iniciar inscripción** o **Ahora no** (para posponer). ![notificación inicial](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/f0387cad-67a7-4823-ab8d-8aefd427452b.png) ##### Inscripción Al seleccionar **Iniciar inscripción**, los usuarios son redirigidos a **Ajustes > VPN y gestión de dispositivos** para iniciar la inscripción en Applivery. ![inscripción](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/dfd98c0d-27f7-4150-a972-ae89290f994d.png) Cuando comienza la inscripción — o cuando se alcanza el plazo de migración — el dispositivo se reinicia automáticamente para aplicar la nueva configuración. Tras el reinicio, se pide a los usuarios que completen el proceso de inscripción. Si el plazo aún no ha vencido, pueden posponer una última vez; de lo contrario, la inscripción es obligatoria. Tras la migración, un dispositivo puede completarse correctamente o fallar. En una **inscripción correcta**, el dispositivo confirma la migración y reinstala apps y configuraciones de forma inalámbrica. En caso de **inscripción fallida**, el dispositivo queda sin gestión y el usuario debe contactar con el administrador para obtener ayuda. **Editar o cancelar una migración** Para modificar o cancelar la migración de un único dispositivo, inicia sesión en Apple Business, dirígete a **Dispositivos**, selecciona el dispositivo de destino, haz clic en **Cambiar plazo** para modificarlo o eliminarlo y luego en **Guardar**. Para varios dispositivos, selecciónalos en Apple Business, haz clic en **Desasignar o reasignar**, ajusta el plazo según sea necesario y haz clic en **Guardar**. :::warning Cancelar una migración restaura la configuración MDM anterior del dispositivo y elimina las notificaciones de migración. ::: **Gestión del Bloqueo de activación** Durante la migración, Applivery gestiona el estado del Bloqueo de activación del dispositivo en función de su estado previo a la migración.

Estado previo a la migración

Comportamiento durante la migración

Resultado posterior a la migración

Sin Bloqueo de activación

Applivery puede activar el Bloqueo de activación durante la migración

El dispositivo puede tener el Bloqueo de activación activado y generarse un nuevo código de omisión

Bloqueo de activación del MDM anterior

El Bloqueo de activación existente se elimina durante la migración

Applivery aplica un nuevo Bloqueo de activación, invalidando los códigos de omisión anteriores

Gestión del Bloqueo de activación (general)

Applivery envía una solicitud de Bloqueo de activación a Apple Business antes de que se complete la migración

Se genera un nuevo código de omisión gestionado a través de Applivery

Fallo en la migración

Apple Business conserva el Bloqueo de activación

El dispositivo se puede desbloquear desde Apple Business; los bloqueos y códigos de omisión anteriores ya no son válidos

--- ## Inscripciones inteligentes Source: https://docs.applivery.com/es/device-management/apple/enrollment/smart-enrollment/ Description: Automatiza la inscripción de dispositivos Apple y la asignación de políticas con las Inscripciones inteligentes de Applivery — define reglas basadas en atributos del usuario y del dispositivo. TL;DR: Automatiza la inscripción de dispositivos Apple y la asignación de políticas con las Inscripciones inteligentes de Applivery definiendo reglas basadas en datos del usuario y del dispositivo para un flujo de trabajo MDM optimizado. Answers: ¿Qué son las Inscripciones inteligentes? · ¿Cuáles son las ventajas de usar las Inscripciones inteligentes? · ¿Qué es el DEP de Apple? · ¿Qué son los Campos auxiliares en las Inscripciones inteligentes? · ¿Funcionan las Inscripciones inteligentes con todos los dispositivos? Key topics: Inscripción de dispositivos Apple, Asignación condicional de políticas, Configuración de Inscripciones inteligentes, Campos auxiliares, Integración DEP, Applivery, Inscripciones inteligentes, Apple DEP, Apple Business, SSO Si alguna vez has soñado con automatizar el 100% del proceso de inscripción de dispositivos y la asignación condicional de políticas basándose en datos del usuario (nombre, correo, grupos de usuarios) o datos del dispositivo (IMEI, número de serie, etc.), las **Inscripciones inteligentes** son la herramienta que buscabas. ### Introducción Las Inscripciones inteligentes son la forma más eficiente de gestionar las inscripciones de dispositivos sin supervisión, ya que te permitirán **definir un conjunto de reglas y condiciones que deben cumplirse para que un dispositivo pueda inscribirse** y, además, te permitirán **asignar condicionalmente políticas** basándose en estos conjuntos de reglas. Las Inscripciones inteligentes son útiles para: - Limitar la inscripción de dispositivos. - Basándose en la autenticación del usuario a través de [integraciones SSO](https://docs.applivery.com/es/platform/authentication/sso/) (grupos de usuarios o patrones de correo). - Basándose en información del dispositivo (IMEI, número de serie). - Asignar condicionalmente diferentes políticas basándose en reglas. - Automatizar las inscripciones DEP de Apple para habilitar experiencias de inscripción sin intervención del usuario. - Crear cuentas locales basadas en información del usuario recuperada tras la autenticación a través de Applivery Connect ([integración SSO](https://docs.applivery.com/es/platform/authentication/sso/)). :::info Las Inscripciones inteligentes es una función que **solo funciona con dispositivos inscritos a través del Programa de inscripción de dispositivos Apple (DEP)**. Puedes obtener más información sobre el DEP de Apple [aquí](https://docs.applivery.com/es/device-management/apple/enrollment/dep/). ::: ### Configuración de la Inscripción inteligente Empecemos a configurar tu primera Inscripción inteligente. Primero, dirígete a **Automatización** 1, selecciona **Inscripciones inteligentes** 2 y elige **Apple** 3 como plataforma en el menú lateral izquierdo. Luego haz clic en el botón **\+ Crear inscripción inteligente** 4. ![Smart Enrollment](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/244f1a61-b7dd-45cc-aeb9-edae4d64d54c.png) **Configurar la Inscripción inteligente** 1. **Nombre:** Elige un nombre descriptivo para tu nueva Inscripción inteligente. 2. **Descripción:** Elige una descripción para tu nueva Inscripción inteligente. 3. ** Proveedores de acceso**: Se mostrarán los proveedores SSO configurados a nivel del espacio de trabajo. Sin embargo, también puedes configurar la integración específica a nivel de Inscripción inteligente haciendo clic en **Anular**. 4. **Política:** Elige la política que se aplicará al dispositivo desde la biblioteca de políticas. Si aún no tienes ninguna política predefinida, escribe un nombre y se creará una nueva política vacía. 5. **Segmento destino**: Elige el [Segmento](https://docs.applivery.com/es/device-management/general-settings/segments/) al que se asignarán los dispositivos inscritos. 6. **Etiquetas**: Se usan para filtrar y agrupar. 7. **Ubicación VPP:** Elige la ubicación VPP que se usará para gestionar las licencias de apps. 8. **Permitir el Bloqueo de activación**: Permite a los dispositivos usar el Bloqueo de activación cuando el usuario activa Buscar. 9. **Asistente de configuración**: Activa el Asistente de configuración de Applivery durante la inscripción (solo para dispositivos macOS). :::info Cuando el proveedor de inicio de sesión está configurado como **Anónimo**, puedes activar la opción **Continuar automáticamente**, que permite que los dispositivos continúen la inscripción automáticamente cuando no se requiere interacción del usuario. ::: ![Smart Enrollment form](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/1870be66-fbb7-4a18-9482-813e2471f90a.png) **Configurar los Campos auxiliares** 10. **Campos auxiliares**: Rellenando este formulario, podrás configurar etiquetas de dispositivos durante la inscripción. ![auxiliary fields](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ac4d9a03-f6a7-40b8-ac5a-e54e8bf0893c.png) Usando los campos auxiliares, puedes definir una **estructura de inscripción flexible** que se adapte a las características organizativas de tu empresa. Esto permite a los usuarios inscribir sus dispositivos **según requisitos específicos**, al tiempo que permite a los administradores aplicar diferentes configuraciones basándose en estas selecciones. Estos campos auxiliares pueden usarse para generar etiquetas de dispositivos durante la inscripción, que funcionan como parámetros condicionales. Puedes crear tantos campos como necesites y asociarlos posteriormente con las políticas correspondientes para cada escenario. :::info Para los **dispositivos iOS**, la supervisión es obligatoria. Esto significa que el dispositivo debe estar inscrito a través de un **perfil DEP** y gestionado en **Apple Business**. ::: Durante el proceso de inscripción inicial desde Apple Business, el dispositivo mostrará un mensaje indicando que está gestionado. ![remote management](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/a7794950-7bfa-4016-80ed-f07c2cd0780d.png) Tras continuar, al usuario se le presentarán los menús desplegables definidos en los Campos auxiliares, según los requisitos de la organización. Una vez seleccionados los campos requeridos, el usuario se autenticará usando el método habilitado por la organización y se aplicarán las políticas apropiadas según las etiquetas asignadas. ![auxiliary fields device](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/b72fc972-4563-4cf4-a99d-e021d23eb0c5.png) El dispositivo completará entonces la inscripción y aplicará las configuraciones en segundo plano. **Configurar el Patrón de nombre para mostrar** 11. **Patrón de nombre para mostrar**: Asigna un nombre para mostrar combinando propiedades del dispositivo. ![interpolation tags](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/49359994-18ef-4557-be60-41557704b028.png) Si haces clic en **Guardar** en este punto, habrás terminado de configurar tu Inscripción inteligente básica y podrás empezar a inscribir dispositivos. **Configurar la Configuración de cuenta** 12. Opcionalmente, configura el formulario de **Configuración de cuenta** para crear cuentas locales automáticamente. Ten en cuenta que las cuentas Admin y Principal pueden crearse al mismo tiempo. También puedes usar [marcadores de posición](https://docs.applivery.com/es/platform/authentication/sso/) que se reemplazarán automáticamente con la información del proceso de autenticación SSO. - La **cuenta Admin** permite configurar el Nombre completo, el Nombre de usuario y la contraseña del usuario. También puedes ocultarla de la ventana de inicio de sesión y otras opciones. - La **cuenta Principal** solo permite configurar el Nombre completo y el Nombre de usuario. La contraseña debe ser elegida por el usuario al configurar el dispositivo por primera vez. ![account configuration](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/6869552a-64e2-4965-8d31-1081eddda608.png) **Aplicar condiciones y reglas** Ahora que tienes tu Inscripción inteligente básica configurada, puedes añadir **Condiciones** 5 y **Reglas** 6 para hacerla más inteligente. ![conditions and rules](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/09a64dfd-32ff-454e-9a31-4c1b5f93efe0.png) Usa la opción **Añadir condición** para habilitar límites de inscripción basados en información del usuario (como patrones de correo o grupos) e información del dispositivo (IMEI, número de serie y campos auxiliares). Puedes usar operadores condicionales para hacerlo tan complejo como necesites. ![conditions](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/00339b9d-db99-4d35-aa12-ca663822652d.png) También puedes usar la opción **Añadir regla adicional** para crear grupos de condiciones, cada uno con una política de destino. Como verás, cada grupo de condiciones también tendrá tantas **Condiciones** como necesites. ![rules](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/4b3e4adf-4d28-4397-bbb8-356f296e5cbe.png) Una vez hecho, haz clic en **Guardar**. **Desplegar las Inscripciones inteligentes** Para finalizar, tienes que asignar las Inscripciones inteligentes a tus dispositivos DEP de Apple Business, así que ve a la sección **Configuración** y localiza la sección **Apple DEP** 7 en el menú lateral izquierdo. Selecciona uno de tus dispositivos **DEP** 8 y haz clic en **Configurar** 9 bajo la opción **Inscripción inteligente** que aparecerá en el panel lateral. ![assign Smart Enrollment](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/43b0515a-52f1-4cba-bea9-f570a74fe3b0.png) Por último, elige una Inscripción inteligente de la lista desplegable y haz clic en **Asignar** para finalizar. --- ## Primeros pasos Source: https://docs.applivery.com/es/device-management/apple/get-started/ Description: Configura los certificados Push de Apple para el MDM de Applivery y habilita tu espacio de trabajo para interactuar con los servicios de Apple y gestionar dispositivos. TL;DR: Configura los certificados Push de Apple en el MDM de Applivery para habilitar la gestión de dispositivos iOS descargando un CSR, creando un certificado en el portal de certificados Push de Apple y subiéndolo de vuelta a Applivery. Answers: ¿Cómo descargo la Solicitud de firma de certificado (CSR) de Applivery? · ¿Dónde creo un certificado Push de Apple? · ¿Qué archivo subo al portal de certificados Push de Apple? · ¿Qué tipo de archivo descargo del portal de certificados Push de Apple? · ¿Dónde subo el certificado Push de Apple (archivo .pem)? · ¿Por qué es importante renovar el certificado Push de Apple anualmente? · ¿Dónde encuentro la sección Configuración de Apple en Applivery? Key topics: Certificado Push de Apple, Generación de CSR, Configuración del MDM de Applivery, Applivery, Apple, CSR, PEM Antes de empezar a usar la Gestión de dispositivos Apple de Applivery, debes seguir una serie de pasos para habilitar tu espacio de trabajo para interactuar con los servicios de Apple y registrar tu organización empresarial de Apple. Los siguientes pasos te guiarán a través del proceso: **Descarga la Solicitud de firma de certificado (CSR) de Applivery** Inicia sesión en el [**panel de Applivery**](https://dashboard.applivery.io/) y ve a la sección **Configuración**. Localiza la sección **Configuración de Apple** en el menú lateral izquierdo. Al lado del paso 1, haz clic en el botón **Descargar CSR**. ![configuración empresarial de apple](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/8b54c912-a61f-4eb0-bf0b-10a49f58307c.png) Se descargará a tu ordenador un archivo llamado `Applivery-CSR.csr`. **Crea un certificado Push de Apple** Ahora visita el [portal de certificados Push de Apple](https://identity.apple.com/pushcert/) e inicia sesión con tu **Apple ID**. Una vez dentro del portal, haz clic en el botón **Crear un certificado**. ![](https://www.applivery.com/wp-content/uploads/2022/05/applivery-apple-push-portal-1024x651.png "applivery-apple-push-portal | Applivery") Lee y acepta las Condiciones de uso. ![](https://www.applivery.com/wp-content/uploads/2022/05/applivery-apple-push-terms-1024x651.png "applivery-apple-push-terms | Applivery") Selecciona y sube el archivo `Applivery-CSR.csr` que descargaste en el Paso 1 y haz clic en **Subir**. ![](https://www.applivery.com/wp-content/uploads/2022/05/applivery-apple-push-upload-1024x651.png "applivery-apple-push-upload | Applivery") Haz clic en **Descargar** y guarda el archivo de certificado `.pem`. ![](https://www.applivery.com/wp-content/uploads/2022/05/apple-push-download-1024x651.png "apple-push-download | Applivery") **Sube tu certificado Push de Apple a Applivery** Vuelve al panel de Applivery y, al lado del paso 5, haz clic en **Seleccionar** y sube el certificado (archivo `.pem`) descargado en el paso anterior. A continuación, haz clic en el botón **Finalizar registro** para completar el proceso. ![finalizar configuración](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/8d48306d-d7f9-4341-aeeb-cdfd0edd8cbf.png) :::warning Recomendamos encarecidamente rellenar el campo **Apple ID** en el Paso 2, ya que el certificado Push de Apple debe renovarse anualmente usando la misma cuenta para garantizar una gestión de dispositivos ininterrumpida. De lo contrario, podrías perder el control sobre los dispositivos inscritos. Consulta [Renovar el certificado Push de Apple](https://docs.applivery.com/es/device-management/apple/renew-push-certificate/) para la renovación y para saber qué hacer si nadie recuerda con qué Apple ID se creó. ::: --- ## iOS y iPadOS Source: https://docs.applivery.com/es/device-management/apple/ios-ipados/ Description: Gestión de dispositivos iOS y iPadOS en Applivery — protege, supervisa y administra dispositivos corporativos, automatiza el aprovisionamiento y la aplicación de políticas. TL;DR: La gestión de endpoints es una plataforma centralizada para administrar y proteger todos los dispositivos corporativos. Answers: ¿Qué es la gestión de dispositivos iOS y iPadOS en Applivery? · ¿Qué puedo hacer con la gestión de dispositivos iOS y iPadOS? · ¿Cómo ayuda la gestión de dispositivos de Applivery con la seguridad? · ¿Reduce la gestión de dispositivos la carga de trabajo del equipo TI? · ¿Qué dispositivos son compatibles con la gestión de dispositivos de Applivery? · ¿Cuál es el principal beneficio de usar un panel centralizado para la gestión de dispositivos? Key topics: gestión de endpoints, seguridad de dispositivos, gestión centralizada, Dispositivos móviles, Tablets, Ordenadores Applivery te permite gestionar dispositivos iPhone y iPad a escala a través de las APIs MDM oficiales de Apple. Puedes automatizar la inscripción, desplegar apps en silencio, aplicar políticas, ejecutar comandos remotos y supervisar el estado de los dispositivos — sin necesidad de tocar físicamente el dispositivo. Gestiona políticas, comandos remotos y la resolución de problemas específicos de iOS y iPadOS. --- ## Comandos remotos Source: https://docs.applivery.com/es/device-management/apple/ios-ipados/commands/ Description: Comandos iOS en Applivery para la gestión remota de dispositivos — bloquea, borra, actualiza y gestiona la seguridad de iPhones e iPads. TL;DR: Applivery permite a los administradores gestionar remotamente dispositivos iOS mediante comandos para acciones como bloquear, borrar y actualizar dispositivos. Answers: ¿Qué son los comandos iOS en Applivery? · ¿Qué acciones puedo realizar con los comandos iOS en Applivery? · ¿Cómo ejecuto comandos iOS en los dispositivos? · ¿Puedo usar los comandos iOS para aplicar políticas de seguridad? · ¿Existe un lugar centralizado para gestionar dispositivos iOS mediante comandos? · ¿Qué tipo de gestión de dispositivos es posible con los comandos iOS? Key topics: Gestión de dispositivos iOS, Applivery, Comandos remotos, Acciones de seguridad, Gestión de dispositivos, iPhone, iPad Los comandos MDM de iOS y iPadOS te permiten realizar acciones remotas en tiempo real en iPhones e iPads gestionados — bloquear un dispositivo, borrar el código de acceso, eliminar todos los datos, reiniciar o enviar una notificación push para solicitar la reinscripción. Cada comando remoto disponible para iOS y iPadOS incluye cuándo usarlo y qué ocurre en el dispositivo cuando se ejecuta. --- ## Return to Service Source: https://docs.applivery.com/es/device-management/apple/ios-ipados/commands/return-to-service/ Description: Usa el comando Return to Service de Apple en iOS para restablecer dispositivos de forma segura y simplificar la reasignación con la reinscripción MDM. TL;DR: El comando Return to Service simplifica el restablecimiento y la reinscripción de dispositivos iOS para una reasignación rápida y segura. Answers: ¿Qué es el comando Return to Service de Apple? · ¿Qué hace Return to Service? · ¿Cuándo debo usar Return to Service? · ¿Cómo activo Return to Service en Applivery? · ¿Qué perfil de inscripción necesito para Return to Service? · ¿Puedo añadir un perfil Wi-Fi a Return to Service? · ¿Dónde puedo encontrar instrucciones para crear un perfil de inscripción? Key topics: Comando Return to Service, Restablecimiento de dispositivos iOS, Inscripción MDM, Perfiles de configuración, Automatización de la gestión de dispositivos, Apple, iOS, MDM, Applivery, mobileconfig El comando **Return to Service** de Apple es una potente función para dispositivos iOS que agiliza el proceso de borrado, restablecimiento y preparación de un dispositivo para su reutilización o reasignación en una organización. Está diseñado para minimizar el trabajo manual del equipo TI a la vez que garantiza que los dispositivos se restablecen de forma segura y están listos para el siguiente usuario. ### ¿Qué hace? - Borra de forma segura todos los datos y ajustes del usuario, protegiendo la privacidad y garantizando el cumplimiento. - Admite la reconfiguración automática incluyendo perfiles clave (por ejemplo, Wi-Fi, inscripción MDM), lo que permite al dispositivo reconectarse a la red y reinscribirse en la gestión tras el restablecimiento. - Omite las pantallas de configuración iniciales para que el dispositivo arranque directamente en la pantalla de inicio — completamente configurado y listo para usar. ### ¿Cuándo se usa? - Para la redistribución rápida de dispositivos compartidos o rotativos en colegios, sanidad, entornos corporativos, quioscos, etc. - Tras reparaciones o mantenimiento de dispositivos, para devolverlos a un estado conocido y funcional. - Durante la migración de un sistema MDM a otro. - Para cumplir con los estándares de seguridad y privacidad en el manejo de datos corporativos o personales. En resumen, el comando **Return to Service** simplifica la reasignación segura de dispositivos en entornos gestionados. Permite a los equipos TI restablecer y preparar dispositivos de forma remota para su reutilización inmediata, ahorrando tiempo, reduciendo el trabajo manual y mejorando la eficiencia operativa. ### Envía el comando Return to Service a tu dispositivo iOS **Prepara tu dispositivo** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/)dirígete a cualquiera de tus **Dispositivos**. Selecciona la pestaña **Comandos** 1 y haz clic en **\+ Nuevo comando** 2. De la lista de comandos disponibles, elige **Borrar dispositivo** 3. ![erase device](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/7afd8152-170e-4641-9e42-ccae768f53a9.png) **Activa Return to Service** En las opciones de configuración del comando **Borrar dispositivo**, asegúrate de activar la función **Return to Service**. ![enable return to service](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/e0bfbe53-6b37-46a9-9995-f2b269ff5c58.png) **Sube el perfil de inscripción** Como parte de este proceso, necesitarás proporcionar un archivo de inscripción `.mobileconfig`, que se aplicará automáticamente una vez que el dispositivo se borre, garantizando que se reincriba en tu entorno MDM sin intervención manual. Para generar este archivo, sigue las instrucciones de la sección de [inscripción manual](https://docs.applivery.com/es/device-management/apple/enrollment/manual-enrollment/) de nuestra documentación. **Opcional: sube un perfil Wi-Fi** Opcionalmente, también puedes incluir un perfil Wi-Fi `.mobileconfig` para que el dispositivo se reconecte a la red automáticamente tras el restablecimiento. :::info Asegúrate de que tus archivos `.mobileconfig` son válidos y están correctamente configurados para garantizar la reinscripción y la conectividad de red sin problemas. ::: --- ## Configurar zona horaria Source: https://docs.applivery.com/es/device-management/apple/ios-ipados/commands/set-time-zone/ Description: Configura remotamente la zona horaria en iPads e iPhones supervisados con iOS/iPadOS 14 o posterior mediante los comandos de gestión de dispositivos de Applivery. TL;DR: Usa Applivery para configurar remotamente la zona horaria en dispositivos iOS supervisados (iOS/iPadOS 14 o posterior) desde la sección de gestión de dispositivos. Answers: ¿Cómo cambio la zona horaria en un iPad o iPhone supervisado con Applivery? · ¿Qué versiones de iOS/iPadOS se necesitan para cambiar la zona horaria con Applivery? · ¿Por qué no puedo cambiar la zona horaria en mi dispositivo con Applivery? · ¿Qué es un nombre de zona horaria IANA? · ¿Puedo configurar la zona horaria en varios dispositivos a la vez en Applivery? · ¿Dónde encuentro la opción "Configurar zona horaria" en Applivery? Key topics: Gestión de dispositivos iOS, Mobile Device Management, Configuración remota, Applivery, iOS, iPadOS Con Applivery, puedes cambiar la zona horaria en un iPad o iPhone supervisado con iPadOS o iOS 14 o posterior. :::info La zona horaria no puede cambiarse en dispositivos con la restricción **Forzar fecha y hora automáticas** activada. ::: ### Configurar la zona horaria Una vez en el [**panel de Applivery**](https://dashboard.applivery.io), dirígete a cualquiera de tus **Dispositivos**. Haz clic en el botón **Acción** y selecciona **Configurar zona horaria**. Asegúrate de que la zona horaria introducida sea un nombre de zona horaria **IANA** válido. ![time zone](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/6925ed5d-b788-4e99-8697-49ed513b8a8d.png) :::info Además, puedes configurar la zona horaria en bloque desde la lista de Dispositivos haciendo clic en el botón **Acción**, seleccionando **Apple** como plataforma y eligiendo el comando **Configurar zona horaria**. ::: --- ## Políticas Source: https://docs.applivery.com/es/device-management/apple/ios-ipados/policies/ Description: Políticas de gestión de dispositivos iOS en Applivery — configura y aplica políticas en iPhones e iPads desde un panel centralizado. TL;DR: Applivery simplifica la gestión de dispositivos iOS proporcionando un panel centralizado para configurar y aplicar políticas en iPhones e iPads. Answers: ¿Qué es la gestión de dispositivos iOS en Applivery? · ¿Qué puedo gestionar con la gestión de dispositivos iOS de Applivery? · ¿Dónde gestiono los dispositivos iOS en Applivery? · ¿Puede la gestión iOS de Applivery aplicar reglas de seguridad? · ¿Puede Applivery controlar el comportamiento de las apps en dispositivos iOS? · ¿Ayuda Applivery con el cumplimiento en dispositivos iOS? Key topics: Gestión de dispositivos iOS, Applivery, Políticas de seguridad, Configuración de dispositivos, Cumplimiento, iOS, iPhone, iPad Las políticas de iOS y iPadOS en Applivery te permiten configurar y aplicar ajustes en todos tus iPhones y iPads gestionados. Desde requisitos de código de acceso y restricciones hasta el comportamiento de las apps, VPN, [Wi-Fi](https://docs.applivery.com/es/device-management/apple/apple-policies/configure-wifi-networks/) y certificados, las políticas te dan control total sobre cada dispositivo inscrito. Los ajustes de política para iOS y iPadOS están organizados por categoría. --- ## Bloquear o permitir URLs en Chrome Source: https://docs.applivery.com/es/device-management/apple/ios-ipados/policies/block-allow-urls-chrome/ Description: Restringe qué sitios web pueden visitar tus usuarios en Google Chrome en iPhone y iPad gestionados, mediante la configuración de app gestionada de Chrome en Applivery. TL;DR: Añade URLBlocklist y URLAllowlist en el campo Configuration de Chrome en tu política de iOS/iPadOS, como arrays JSON en la raíz. No requiere supervisión y hay que reiniciar Chrome para que se apliquen. Answers: ¿Cómo bloqueo sitios web en Chrome en un iPad gestionado? · ¿Cómo configuro URLBlocklist de Chrome en iOS con configuración de app gestionada? · ¿Por qué chrome://policy muestra "Política desconocida" en iOS? · ¿Cómo restrinjo Chrome a ciertos sitios web en un iPhone con MDM? Key topics: Políticas de URL de Chrome en iOS e iPadOS, Configuración de app gestionada, Sintaxis de filtros URL, Verificación con chrome://policy, Applivery, Apple, Google Chrome, iOS, iPadOS Si tus usuarios navegan con Google Chrome en sus iPhone y iPad, puedes decidir qué sitios web puede abrir Chrome: bloquear un par de sitios que distraen o limitar Chrome a una lista corta de herramientas de trabajo. Lo haces desde la app Chrome en tu política, mediante su configuración de app gestionada. ### Chrome frente al filtro de contenido web de Apple Estas propiedades solo controlan **Google Chrome**. Si necesitas restringir Safari, usa en su lugar el [Filtro de contenido web](https://docs.applivery.com/es/device-management/apple/ios-ipados/policies/web-content-filter/) nativo de Apple. Los dos mecanismos son independientes: bloquear una URL en uno no la bloquea en el otro.

Bloqueo de URLs en Chrome

Filtro de contenido web

Ámbito

Solo Google Chrome

Safari y WebKit

Dónde se configura

Política → Apps → Google Chrome → Configuration

Política → configuración Web Content Filter

Requiere supervisión

No

Sí

### Requisitos previos - Google Chrome está añadido como app en tu política de iOS/iPadOS. La configuración solo llega a Chrome cuando está instalado como app gestionada. - **No hace falta que el dispositivo esté supervisado.** - Acceso a un dispositivo de prueba para comprobar el resultado en `chrome://policy`. ### Configuración **Abre tu política** En el [**Dashboard de Applivery**](https://dashboard.applivery.io/), ve a **Políticas** 1 y selecciona tu política de iOS/iPadOS. **Abre Google Chrome** Ve a **Apps** 2 y añade o edita la entrada de **Google Chrome** 3. ![chrome managed properties](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/c3faf3fb-bacb-4deb-88e4-5d8fea337975.png) **Añade las propiedades** En el campo **Configuration**, añade `URLBlocklist` (y `URLAllowlist` si necesitas excepciones). Puedes usar el modo **JSON** o el modo **Property**: los dos dan el mismo resultado. Tienes los ejemplos a continuación. ![urlblocklist](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ba9c020f-6a3c-47c2-9783-978147e3bc4e.png) **Guarda y aplica** Guarda los cambios y aplica la política a tus dispositivos. **Reinicia Chrome en el dispositivo** Cierra Chrome por completo y vuelve a abrirlo para que recoja la nueva configuración. #### Bloquear sitios concretos **Modo JSON**: pega el objeto con la lista como array JSON: ```json { "URLBlocklist": [ "facebook.com", "x.com" ] } ``` **Modo Property**: haz clic en **\+ Add Property** y rellénala: - **Key**: `URLBlocklist` - **Value**: `["facebook.com","x.com"]` #### Permitir solo una lista de sitios Bloquea todos los sitios con `*` y añade las excepciones en `URLAllowlist`: ```json { "URLBlocklist": [ "*" ], "URLAllowlist": [ "mail.google.com", "applivery.com" ] } ``` En modo Property, añade dos propiedades: `URLBlocklist` con el valor `["*"]` y `URLAllowlist` con el valor `["mail.google.com","applivery.com"]`. :::warning **Añade las propiedades en la raíz.** `URLBlocklist` y `URLAllowlist` van directamente en el campo Configuration. No las envuelvas en una clave contenedora como `ChromePolicy`: Chrome las mostrará como **Política desconocida** y las ignorará. ::: ### Sintaxis de los filtros URL Las entradas siguen el formato de filtros de Chrome Enterprise, `[esquema://][.]host[:puerto][/ruta][@consulta]`, la misma sintaxis que usa Applivery en todas las plataformas donde están disponibles `URLBlocklist` y `URLAllowlist`.

Entrada

Qué cubre

facebook.com

El dominio y todos sus subdominios. No necesitas una entrada aparte *.facebook.com.

.www.example.com

Solo ese host exacto. Los demás subdominios siguen accesibles.

*

Todos los hosts. Es un valor especial por sí solo, no un comodín que puedas usar dentro de un nombre de host.

:::info **Cuando las dos listas chocan, gana el filtro más específico.** Chrome elige los filtros con el host coincidente más largo, después la ruta coincidente más larga y después el conjunto de parámetros de consulta más largo. Si un filtro de bloqueo y uno de permiso son igual de específicos, **tiene prioridad el de permiso**. ::: Para la referencia completa de la sintaxis, con más ejemplos y casos especiales, consulta [Filtros URL](https://docs.applivery.com/es/device-management/android/troubleshooting/url-filtering/). ### Comprobar que se ha aplicado 1. En el dispositivo, abre Chrome y ve a `chrome://policy`. 2. Pulsa **Reload policies**. 3. Busca `URLBlocklist` y `URLAllowlist`: el **Status** debe ser **OK** y el **Value** debe coincidir con lo que configuraste. 4. Intenta abrir uno de los sitios bloqueados. Chrome debe mostrar su pantalla de bloqueo. ### Resolución de problemas

Qué ves en chrome://policy

Causa probable

Qué hacer

Estado Error

Alguna entrada no tiene una sintaxis válida, por ejemplo *.dominio.com, con un comodín delante del host.

Revisa cada entrada con la sintaxis de Filtros URL. Recuerda que un dominio sin prefijo ya cubre sus subdominios.

Estado Política desconocida

Las propiedades se enviaron dentro de una clave contenedora como ChromePolicy.

Mueve URLBlocklist y URLAllowlist a la raíz del campo Configuration.

Estado OK, pero el sitio sigue abriéndose

Chrome no se ha reiniciado desde que se aplicó la política.

Cierra Chrome por completo y vuelve a abrirlo.

Un sitio permitido sigue bloqueado

Una entrada más específica de URLBlocklist coincide con él, o hay otra configuración de app en conflicto en el mismo dispositivo.

Comprueba qué filtro es más específico y asegúrate de que no se aplica otra configuración de Chrome al dispositivo.

### Bloquear la web no es bloquear la app Estas propiedades solo impiden el acceso **desde Chrome**. Si un servicio tiene su propia app nativa, los usuarios pueden seguir usándolo desde ahí. Para impedir el uso del servicio en sí, bloquea también la app: consulta [Bloquear y permitir apps](https://docs.applivery.com/es/device-management/apple/app-management/block-allow-apps/). --- ## Despliegue de libros Source: https://docs.applivery.com/es/device-management/apple/ios-ipados/policies/book-deployment/ Description: Despliega y gestiona libros en dispositivos iOS con Applivery — distribúyelos individualmente o mediante políticas en dispositivos gestionados. TL;DR: Despliega libros en dispositivos iOS individualmente o mediante políticas usando el panel de Applivery. Answers: ¿Puedo asignar libros a dispositivos macOS? · ¿Cómo despliego un libro en un único dispositivo? · ¿Cómo elimino un libro de un dispositivo? · ¿Cómo puedo desplegar libros en varios dispositivos a la vez? · ¿Qué tipos de archivo se admiten para los libros? · ¿Dónde puedo ver la lista de todos los libros subidos? · ¿Cómo se despliegan los libros en iPhones e iPads? Key topics: Gestión de dispositivos, Gestión de contenido, Gestión de políticas, Applivery, iOS, Libros :::warning Los libros (`.epub`, `.pdf`) se gestionan de forma diferente según el dispositivo en el que se despliegan. En iPhone e iPad, los libros deben desplegarse a través del canal de dispositivo, lo que significa que estarán disponibles en todo el dispositivo para todos los usuarios. **Ten en cuenta que los libros no pueden asignarse a dispositivos macOS**. ::: ### Despliegue de libros en un único dispositivo Desde el [**panel de Applivery**](https://dashboard.applivery.io/), navega a cualquiera de tus **Dispositivos** 1. Ve a la pestaña **Libros** 2 y haz clic en el botón **\+ Asignar Libro** 3. Puedes seleccionar un libro existente de la lista de recursos o subir uno nuevo haciendo clic en el botón **Cargar nuevo recurso** 4. Elige el recurso que quieras del menú desplegable y haz clic en **Añadir** 5. ![add book](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/2d3c3076-faa1-4d70-b79d-494b18299c15.png) El libro se desplegará automáticamente en tu dispositivo. Para **eliminar libros** del dispositivo, simplemente haz clic en los **tres puntos** al final de cada libro y elige **Desasignar**. ![unassign book](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/326a8fd2-8a7e-4916-8b69-82a2ee994fc9.png) ### Despliegue de libros en varios dispositivos mediante políticas También puedes gestionar libros, desplegarlos en varios dispositivos y mantenerlos sincronizados usando **Políticas**. Ve a cualquiera de tus **Políticas** 6. En el menú lateral izquierdo, navega a **Libros** 7. Luego haz clic en el botón **\+ Añadir libro** 8. ![add book Policies](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/dab2ab09-7ac6-4b24-ab2f-f8bcecbac806.png) Como se mencionó antes, puedes seleccionar un libro existente de la lista de recursos o subir uno nuevo haciendo clic en el botón **Cargar nuevo recurso** 4. Selecciona un archivo `.pdf` o `.epub` desde tus archivos. ### Gestión de tus libros Puedes ver, gestionar y descargar la lista completa de libros que has subido yendo a la sección **Recursos** 9 y seleccionando **Libros** 10 en el menú lateral izquierdo. ![resources books](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/859dcba8-a200-4541-ba8e-20e2a8d73f15.png) --- ## Modo quiosco Source: https://docs.applivery.com/es/device-management/apple/ios-ipados/policies/kiosk-mode/ Description: Configura el modo quiosco de Apple en Applivery para bloquear dispositivos iOS supervisados en entornos de una o varias apps. TL;DR: El modo quiosco de Apple, configurable a través de Applivery, bloquea dispositivos iOS supervisados a una sola app o a un diseño de pantalla de inicio controlado para usos específicos. Answers: ¿Qué es el modo quiosco de Applivery para dispositivos Apple? · ¿Cuáles son los dos tipos de modo quiosco en Applivery? · ¿Qué es el modo App Lock de Applivery? · ¿Cómo configuro App Lock en Applivery? · ¿Qué es el modo disposición de la pantalla de inicio de Applivery? · ¿Cómo configuro disposición de la pantalla de inicio en Applivery? · ¿Pueden los usuarios acceder a la app de Ajustes con la disposición de la pantalla de inicio? · ¿Se necesitan dispositivos supervisados para el modo quiosco de Applivery? Key topics: Configuración de App Lock, Configuración de la disposición de la pantalla de inicio, Requisito de dispositivos supervisados, Casos de uso del modo quiosco, Apple, iOS, Applivery, App Store, Programa de compras por volumen Apple (VPP) El modo quiosco es una de las herramientas más potentes disponibles para los administradores TI que gestionan flotas de dispositivos Apple. Te permite dedicar los dispositivos a un único propósito — bloqueándolos a una app, un conjunto controlado de apps o un diseño de pantalla de inicio completamente controlado — impidiendo que los usuarios accedan a cualquier cosa que la organización no haya definido. Applivery ofrece dos modos quiosco distintos para dispositivos Apple, cada uno adecuado para diferentes escenarios de despliegue. :::warning El modo quiosco solo está disponible en dispositivos **supervisados**. Consulta nuestro artículo sobre [Dispositivos Apple supervisados](https://docs.applivery.com/es/device-management/apple/supervision/) para más información sobre cómo supervisar tu flota. ::: ### Modos quiosco disponibles | Modo | Apps permitidas | Ideal para | | --- | --- | --- | | **App Lock** | Una sola app | Dispositivos de uso único bloqueados a una sola aplicación. | | **Disposición de la pantalla de inicio** | Varias apps | Entornos multiaplicación controlados con una interfaz personalizada. | * * * ### App Lock App Lock restringe el dispositivo a una sola aplicación. Una vez activo, los usuarios no pueden salir de la app ni acceder a ninguna otra parte del dispositivo — es el modo quiosco más restrictivo y la opción por defecto para terminales TPV, quioscos de autoservicio, señalización digital o cualquier despliegue de uso único. #### Cómo configurar App Lock App Lock se configura a nivel de política: **Añade la app a la política** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a cualquiera de tus **Políticas** 1. En el menú lateral izquierdo dirígete a **Apps** 2 y haz clic en el botón **\+ Añadir App** 3. ![add app](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/a7200ca3-bc7f-4b2c-a341-d77ff68e3888.png) Busca la app usando las pestañas **App Store** o **Applivery**, elige **iOS** e indica si la app usa una **licencia VPP** (consulta el [Programa de compras por volumen Apple](https://docs.applivery.com/es/device-management/apple/app-management/vpp/) para más detalles). **Restringe el acceso solo a esa app** Sigue los pasos descritos en el siguiente artículo para [configurar una lista de apps permitidas](https://docs.applivery.com/es/device-management/apple/app-management/block-allow-apps/) y asegurarte de que no se puede acceder a ninguna otra aplicación en el dispositivo. ![allow only some Apps](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/64b0d23c-953e-4ead-acae-f0368ead81fd.png) **Activa App Lock** En el menú lateral izquierdo, haz clic en **\+ Añadir configuración** y selecciona **App Lock** 4. ![app lock](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ff19b38b-70ec-4b01-b2f0-08e10ec87fed.png) Introduce el **Bundle ID** de la aplicación a la que quieres bloquear el dispositivo y configura los ajustes adicionales según sea necesario (consulta las opciones a continuación). ![app lock configuration ](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/6c4ee7fd-d72f-42ed-bcc1-f1f23b8a8fc4.png) **Guarda** y despliega la política. #### Opciones de configuración de App Lock Al configurar App Lock, puedes ajustar la experiencia del usuario y el comportamiento del hardware mediante las siguientes opciones: **Interacción táctil** | Opción | Descripción | | --- | --- | | Desactivar pantalla táctil | Desactiva completamente la pantalla táctil. Útil para dispositivos solo de visualización. | | Desactivar rotación del dispositivo | Bloquea la orientación de la pantalla, evitando la rotación al mover el dispositivo. | | Desactivar botones de volumen | Impide que el usuario cambie el volumen del dispositivo. | | Desactivar interruptor de timbre | Desactiva el interruptor de silencio/timbre. | | Desactivar botón de reposo/activación | Impide que el usuario ponga el dispositivo en reposo o lo active manualmente. | | Desactivar bloqueo automático | Mantiene la pantalla encendida permanentemente, anulando el ajuste de bloqueo automático. | | Activar pantalla táctil | Activa explícitamente la pantalla táctil (útil combinado con otras restricciones). | | Activar AssistiveTouch | Activa la superposición de accesibilidad AssistiveTouch de Apple. | | Activar zoom | Activa la función de accesibilidad de zoom. | | Activar VoiceOver | Activa el lector de pantalla VoiceOver. | | Activar Invertir colores | Activa la opción de accesibilidad Invertir colores. | ### Disposición de la pantalla de inicio La disposición de la pantalla de inicio permite a los administradores definir exactamente qué apps, web clips y carpetas aparecen en la pantalla de inicio del dispositivo y en qué disposición. A diferencia de App Lock, los usuarios pueden cambiar entre las apps permitidas — pero no pueden acceder a nada fuera del diseño controlado. Este modo es ideal para dispositivos corporativos en los que los empleados necesitan acceso a un conjunto controlado de herramientas: el dispositivo de un trabajador de campo con solo las apps de productividad aprobadas, un iPad compartido en una sala de reuniones o un dispositivo de punto de venta con apps orientadas al cliente y apps operativas juntas. #### Cómo configurar la disposición de la pantalla de inicio Al igual que App Lock, la disposición de la pantalla de inicio se configura a nivel de política. **Restringe el acceso a las apps necesarias** Sigue los pasos descritos en el siguiente artículo para [configurar una lista de apps permitidas](https://docs.applivery.com/es/device-management/apple/app-management/block-allow-apps/) y asegurarte de que no se puede acceder a ninguna otra aplicación en el dispositivo. ![allow only some Apps](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/64b0d23c-953e-4ead-acae-f0368ead81fd.png) **Configura la disposición de la pantalla de inicio** En el menú lateral izquierdo, haz clic en **\+ Añadir configuración** y selecciona **Disposición de la pantalla de inicio** 5. ![home screen layout](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/4bcdc29b-af5a-41e4-ad26-c38419675ea7.png) Aparecerá un editor visual con apariencia de dispositivo. Úsalo para añadir apps, web clips y carpetas, y colócalos tal como deben aparecer en la pantalla de inicio del dispositivo. ![home screen layout configuration](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/1853b4e4-fb5a-4603-97c4-00ff6d65865b.png) **Guarda** y despliega la política. :::warning La **app de Ajustes no puede bloquearse** — siempre permanecerá accesible para los usuarios independientemente de la configuración de la disposición de la pantalla de inicio. ::: ### Elegir el modo adecuado | Escenario | Modo recomendado | | --- | --- | | Terminal TPV bloqueado a una sola app de punto de venta | App Lock | | Quiosco de autoservicio o pantalla informativa | App Lock | | Dispositivo compartido con un conjunto controlado de herramientas de trabajo | Disposición de la pantalla de inicio | | Dispositivo de trabajador de campo con solo apps aprobadas | Disposición de la pantalla de inicio | | Señalización digital o pantalla solo de visualización | App Lock (con pantalla táctil desactivada) | | Dispositivo de punto de venta con apps orientadas al cliente y apps de back office | Disposición de la pantalla de inicio | --- ## Bloquear o permitir URLs en Safari Source: https://docs.applivery.com/es/device-management/apple/ios-ipados/policies/web-content-filter/ Description: Controla qué sitios web pueden visitar tus usuarios en Safari en dispositivos iOS y iPadOS supervisados, usando listas de URLs permitidas y denegadas. A veces hay que decidir de forma centralizada a qué sitios web puede acceder un dispositivo: un iPad compartido en una tienda que solo debería abrir dos herramientas internas, o un parque en el que un puñado de sitios sencillamente no deberían ser accesibles. La configuración de **Filtro de contenido web** es donde se hace. Te da dos listas: sitios que siempre permites y sitios que siempre bloqueas. Detrás de ellas, las reglas de coincidencia son menos literales de lo que parecen, y de ahí vienen casi todas las sorpresas. ### Requisitos previos - El dispositivo está **supervisado**. El filtrado de contenido web a nivel de sistema en iOS e iPadOS, Safari incluido, solo funciona en dispositivos supervisados. - La política está correctamente asignada a los dispositivos de destino. ### Configuración **Navegar a Políticas** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io), dirígete a la **política** 1 que quieras modificar. En el menú lateral izquierdo, selecciona **\+ Añadir configuración** y elige **Filtro de contenidos web** 2. ![web content filter](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/5ec728a1-e267-4618-9504-dfa0f14412d2.png) **Rellenar las listas** Añade a la lista de denegadas los sitios que quieras bloquear, a la de permitidas los que quieras que estén siempre accesibles, o ambas cosas. Una vez aplicada, un dispositivo que intente abrir un sitio bloqueado no falla en silencio: Safari muestra el mensaje **Sitio web bloqueado**. #### Qué puedes definir

Ajuste

Qué hace

Filtrado automático

El filtro integrado de Apple, que bloquea contenido adulto automáticamente. Necesario si quieres usar la lista de permitidas.

URLs permitidas

Sitios accesibles aunque el filtro automático los considerara contenido adulto. Si la dejas vacía, es accesible todo sitio no adulto salvo los que hayas denegado.

URLs denegadas

Sitios que nunca son accesibles, aunque el filtro automático los considere correctos. Mantén esta lista en no más de 500 URLs.

Ocultar URLs denegadas

Desde iOS 18, oculta la lista de denegadas del perfil que se muestra en Ajustes → General → VPN y gestión de dispositivos.

Plug-in

Cede el filtrado a un filtro de terceros en lugar del integrado de Apple.

:::info **La lista de permitidas solo funciona con el filtrado automático activado.** Apple ata las dos cosas: si el filtrado automático está desactivado, las URLs permitidas no tienen ninguna regla a la que hacer excepción, y la lista no hace nada. ::: :::info `*.apple.com` **y** `*.icloud.com` **son siempre accesibles**, los incluyas o no. No pierdas tiempo intentando bloquearlos. ::: ### Cómo se comparan las URLs Esta es la parte que conviene leer dos veces, porque el filtro no compara las URLs como esperarías. **Incluye el esquema.** Las entradas necesitan `https://` o `http://`. Si un sitio responde en ambos, añade una entrada para cada uno. **La coincidencia es por subcadena.** Una URL coincide con una entrada si los caracteres exactos de esa entrada aparecen en cualquier parte de la URL solicitada. Por eso bloquear `ejemplo.com/a` bloquea también `ejemplo.com/apple`, `ejemplo.com/about` y `ejemplo.com/a/b`. :::warning **El prefijo** `www` **se descarta antes de comparar, y las consecuencias son más amplias de lo que parece.** Bloquear `www.ejemplo.com` deja `ejemplo.com` como patrón, que a su vez coincide con `m.ejemplo.com`. Es decir, una regla que escribiste para un único host puede acabar cubriendo subdominios móviles y cualquier otra cosa que contenga esa cadena. Comprueba qué más atrapa tu entrada antes de desplegarla. ::: **Un subdominio no cubre el dominio principal.** Bloquear `blog.ejemplo.com` deja `ejemplo.com` accesible. Si quieres los dos, añade los dos. **Las barras finales se comparan de forma explícita.** Una entrada que termina en `/`, como `ejemplo.com/a/`, cubre `ejemplo.com/a` y `ejemplo.com/a/b`. **Las redirecciones no se siguen.** Si una URL bloqueada redirige a otra, el destino tiene que estar también en la lista; si no, la redirección pasa. #### Ejemplos

Objetivo

Entrada

Resultado

Bloquear un dominio completo, subrutas incluidas

https://ejemplo.com/

Bloquea ejemplo.com y todo lo que cuelgue de él

Bloquear un prefijo de ruta

https://ejemplo.com/a

Bloquea ejemplo.com/a, ejemplo.com/apple, ejemplo.com/a/b — pero no el dominio principal

Bloquear una ruta de forma explícita

https://ejemplo.com/a/

Bloquea ejemplo.com/a y ejemplo.com/a/b

Permitir solo un conjunto de sitios

Filtrado automático activado + los sitios en la lista de permitidas

Esos sitios son siempre accesibles

### Cuando se aplican varias políticas Todas las reglas de filtrado están activas a la vez, y un sitio tiene que **superarlas todas** para ser accesible. En la práctica eso significa que las restricciones se suman en lugar de sustituirse: si cualquier política aplicada deniega un sitio, queda denegado. Si un sitio que esperas que funcione aparece bloqueado, revisa **todas** las políticas asignadas al dispositivo, no solo la que editaste. ### Consideraciones importantes - **Un sitio bloqueado sigue siendo accesible desde su app.** Si una red social está en la lista de denegadas pero su app está instalada, el usuario continúa como si nada: el filtro solo cubre el tráfico web. Para cerrar ese hueco, bloquea también la app, como se explica en [Bloquear y permitir apps](https://docs.applivery.com/es/device-management/apple/app-management/block-allow-apps/). - **El filtro cubre Safari y WebKit.** Los navegadores de terceros que no usan WebKit, y el tráfico que generan las apps, quedan fuera. Para eso necesitas un filtro por plug-in o un control a nivel de red, como un proxy HTTP global o DNS filtrado. - **Activar el filtro deshabilita borrar el historial de Safari.** Es un efecto colateral documentado por Apple, no un fallo. Desde iOS 26 existe un ajuste explícito para ello, que además impide la navegación privada, porque ese modo no guarda historial que retener. - **El usuario no puede cambiar nada de esto en el dispositivo** mientras el perfil esté instalado. - **No es un filtro de grado normativo.** Para requisitos regulatorios estrictos, o para cubrir más allá de Safari, combínalo con un proxy HTTP global, DNS filtrado o un filtro de terceros mediante la opción de plug-in. ### Dispositivos no supervisados y personales El filtro integrado necesita supervisión, así que no está disponible en dispositivos no supervisados ni inscritos por usuario. La vía ahí es la opción de **plug-in** con un filtro de terceros, que requiere un **UUID de filtro de contenido**: Apple hace obligatorio ese identificador precisamente para dispositivos no supervisados y User Enrollment, desde iOS 16. Las apps gestionadas que lleven el mismo UUID comparten el filtro. ### Resolución de problemas

Síntoma

Causa probable

Qué revisar

Una URL bloqueada sigue siendo accesible

El usuario entra por la app nativa, o una redirección acaba en una URL que no está en la lista

Bloquea también la app; añade el destino de la redirección a la lista

El perfil no se instala

El dispositivo no está supervisado, o a un filtro por plug-in le faltan identificadores

Confirma la supervisión; revisa el UUID del filtro de contenido

Un sitio permitido sigue bloqueado

Hay una entrada contradictoria en una lista de denegadas, posiblemente de otra política

Revisa todas las políticas aplicadas al dispositivo; gana la denegada

La lista de permitidas no surte efecto

El filtrado automático está desactivado

Activa el filtrado automático; la lista de permitidas depende de él

El filtrado no cubre otros navegadores ni el tráfico de apps

Es lo esperado: el filtro integrado cubre Safari y WebKit

Valora un filtro por plug-in o un proxy HTTP global

--- ## Resolución de problemas Source: https://docs.applivery.com/es/device-management/apple/ios-ipados/troubleshooting/ Description: Resuelve problemas de gestión de dispositivos iOS en Applivery. Aprende a solucionar errores de inscripción, configuración y conectividad en iOS/iPadOS. TL;DR: Aprende a resolver problemas comunes de gestión de dispositivos iOS en Applivery, incluyendo inscripción, configuración y conectividad. Answers: ¿Qué cubre la resolución de problemas de gestión de dispositivos iOS en Applivery? · ¿Qué tipos de problemas aborda la resolución de problemas iOS de Applivery? · ¿A quién beneficia la resolución de problemas de gestión de dispositivos iOS en Applivery? · ¿Cuál es el objetivo de la resolución de problemas de gestión de dispositivos iOS? Key topics: Resolución de problemas iOS, Applivery, Problemas de inscripción, Errores de configuración, Problemas de conectividad, iOS, iPadOS Diagnostica y resuelve problemas comunes de gestión de dispositivos iOS y iPadOS en Applivery — incluyendo fallos de inscripción, errores de instalación de perfiles MDM, conflictos de políticas y problemas de instalación de apps. Cada artículo explica la causa probable y los pasos para resolverlo, para que puedas volver a tener los dispositivos bajo gestión lo antes posible. --- ## Desactivar el modo perdido sin conexión a internet Source: https://docs.applivery.com/es/device-management/apple/ios-ipados/troubleshooting/disable-lost-mode-without-internet/ Description: Desactiva el modo perdido en dispositivos iOS sin conexión a internet — soluciones con tarjetas SIM y adaptadores RJ45. TL;DR: Desactiva el modo perdido en un dispositivo sin internet usando una tarjeta SIM con datos o un adaptador Lightning a RJ45 para restablecer la conectividad. Answers: ¿Por qué no puedo desactivar el modo perdido en un dispositivo en Applivery? · ¿Qué ocurre cuando un dispositivo en modo perdido se queda sin batería? · ¿Puedo conectar un dispositivo en modo perdido a Wi-Fi para desactivarlo? · ¿Cómo puede ayudar una tarjeta SIM a desactivar el modo perdido en Applivery? · ¿Qué es un adaptador Lightning a RJ45 y cómo ayuda con el modo perdido? · ¿Qué debo comprobar al usar una tarjeta SIM para desactivar el modo perdido? · ¿Qué debo comprobar al usar un adaptador Lightning a RJ45 para desactivar el modo perdido? Key topics: Modo perdido, Conectividad a internet, Resolución de problemas, Gestión de dispositivos, Applivery, Apple, Tarjeta SIM, Adaptador Lightning a RJ45 En ocasiones, al activar el modo perdido en un dispositivo, este puede perder su conexión a internet y dejar de ser accesible desde Applivery. Esto impide desactivar el modo perdido. El escenario más habitual es cuando un dispositivo Apple en modo perdido se queda sin batería y se apaga. Al volver a encenderse, el dispositivo ha perdido su conexión a internet. Por tanto, es imposible enviar el comando "Desactivar modo perdido" (ni ningún otro comando) desde Applivery, ya que no hay comunicación entre el dispositivo y Applivery. Tampoco es posible conectarlo a una red Wi-Fi (ni por USB conectándolo al ordenador, ni compartiendo datos desde otro dispositivo…) ya que la pantalla estará bloqueada en modo perdido. Sin embargo, existen un par de soluciones posibles: **Usar una tarjeta SIM** La primera opción es usar una tarjeta SIM con el PIN desactivado y una red de datos activa. Insértala en el dispositivo y se conectará automáticamente a internet y recibirá todos los comandos pendientes, incluyendo el comando "desactivar modo perdido". **Usar un adaptador Lightning a RJ45** Una segunda opción es usar un adaptador Lightning a RJ45 para conectarse a una red de internet por cable. Esto consigue el mismo resultado. :::info Asegúrate de que la tarjeta SIM tiene datos suficientes y de que el adaptador Lightning a RJ45 es compatible con el dispositivo. ::: --- ## Restaurar en modo DFU Source: https://docs.applivery.com/es/device-management/apple/ios-ipados/troubleshooting/restore-dfu-mode/ Description: Restaura tu iPhone o iPad en modo DFU — instrucciones paso a paso para reinstalar el firmware cuando los métodos de restauración estándar fallan. TL;DR: Restaura tu iPhone o iPad a su estado de fábrica en modo DFU siguiendo estos pasos: haz una copia de seguridad, entra en modo DFU y restaura desde tu ordenador. Answers: ¿Qué es el modo DFU en un dispositivo iOS? · ¿Cuándo debo usar el modo DFU? · ¿Borrará el modo DFU mis datos? · ¿Cómo encuentro la combinación de botones correcta para el modo DFU? · ¿Qué software necesito para restaurar en modo DFU? · ¿Qué debo hacer antes de entrar en modo DFU? · ¿Dónde puedo encontrar la documentación oficial de Apple para restaurar mi dispositivo? Key topics: Modo DFU, Restaurar iPhone, Restaurar iPad, Actualización de firmware, iPhone, iPad, Apple, Finder, iTunes, Apple Devices :::warning Este proceso borrará todos los datos de tu dispositivo, así que asegúrate de hacer una copia de seguridad primero. - **Modelos de dispositivo:** La combinación de botones puede variar incluso dentro de la misma generación de dispositivos. - **Software actualizado:** Asegúrate de tener instalada la última versión de Finder, Apple Devices o iTunes. - **Documentación oficial:** Consulta siempre la documentación oficial de Apple para obtener las instrucciones más precisas y actualizadas para tu dispositivo. ::: Restaurar tu dispositivo en **modo DFU** (Device Firmware Update) es un proceso de nivel profundo que te permite reinstalar el firmware en tu dispositivo iOS. Normalmente es el último recurso cuando otros métodos de restauración han fallado y tu dispositivo no responde. #### ¿Cómo restauro el dispositivo? **Preparación** - **Copia de seguridad:** Haz una copia de seguridad completa de tus datos en iCloud o iTunes. - **Conexión:** Conecta tu dispositivo iOS al ordenador con el cable USB original. **Entrar en modo DFU** - **Apagar:** Apaga tu dispositivo iOS. - **Combinación de botones:** La combinación exacta de botones depende de tu modelo de dispositivo. Consulta las guías oficiales de Apple para obtener instrucciones detalladas: - [Restaurar tu iPad](https://support.apple.com/es-es/108925) - [Restaurar tu iPhone o iPod touch](https://support.apple.com/es-es/118106) **Restauración** - **Software:** Abre la aplicación correcta en tu ordenador: - macOS: Finder - Windows 10 o posterior: app "Apple Devices" - Versiones anteriores de Windows: iTunes - **Modo de recuperación:** Tu dispositivo debería aparecer en la aplicación como si estuviera en modo de recuperación. El modo DFU es potente, pero úsalo con cuidado. Haz siempre una copia de seguridad de tus datos antes de empezar. Si no estás seguro, consulta la documentación oficial de Apple o busca ayuda de un profesional. --- ## macOS Source: https://docs.applivery.com/es/device-management/apple/macos/ Description: Gestión de dispositivos macOS en Applivery — automatiza el aprovisionamiento, aplica políticas de seguridad y mantén el cumplimiento a escala. TL;DR: La gestión de dispositivos macOS permite a las organizaciones gestionar, proteger y mantener el cumplimiento de los dispositivos macOS a escala mediante soluciones MDM como Applivery. Answers: ¿Qué es la gestión de dispositivos macOS? · ¿Qué puedo hacer con la gestión de dispositivos macOS? · ¿Cómo ayuda Applivery con la gestión de dispositivos macOS? · ¿Dónde puedo gestionar dispositivos macOS? · ¿Qué políticas de seguridad puedo aplicar en dispositivos macOS? · ¿Puedo desplegar aplicaciones en dispositivos macOS de forma remota? Key topics: Gestión de dispositivos macOS, Mobile Device Management (MDM), Seguridad de dispositivos, Aprovisionamiento de apps, Cumplimiento de dispositivos, macOS, Applivery, MDM Applivery te permite gestionar dispositivos macOS a escala a través de las APIs MDM oficiales de Apple. Puedes automatizar la inscripción mediante Apple Business, desplegar apps y scripts, aplicar políticas de seguridad, gestionar FileVault y el activation lock, y ejecutar comandos remotos. Gestiona apps, políticas, comandos remotos y la resolución de problemas específicos de macOS. --- ## Gestión de apps Source: https://docs.applivery.com/es/device-management/apple/macos/app-management/ Description: Simplifica la gestión de apps macOS con Applivery. Despliega, actualiza y protege apps en dispositivos macOS desde un panel centralizado. TL;DR: Applivery simplifica la gestión de apps macOS con un panel centralizado para desplegar, actualizar y proteger apps a escala. Answers: ¿Qué es la gestión de apps macOS en Applivery? · ¿Qué pueden hacer los administradores con la gestión de apps macOS de Applivery? · ¿Dónde se controla la gestión de apps macOS en Applivery? · ¿Puedo distribuir apps en dispositivos macOS con Applivery? · ¿Puedo aplicar políticas de seguridad en apps macOS con Applivery? · ¿Permite Applivery controlar las actualizaciones de apps macOS? Key topics: Gestión de apps macOS, Funciones de Applivery, Despliegue de apps, Políticas de seguridad, Gestión centralizada La gestión de apps macOS en Applivery te permite desplegar y mantener aplicaciones en ordenadores Mac gestionados a escala. Puedes distribuir apps desde la Mac App Store mediante VPP, desplegar instaladores PKG, instalar herramientas de seguridad de terceros y configurar el comportamiento de las apps a través de políticas. Distribuye apps en macOS con distintos métodos, despliega paso a paso aplicaciones empresariales comunes y gestiona las actualizaciones y configuraciones de las apps. --- ## Catálogo de apps Source: https://docs.applivery.com/es/device-management/apple/macos/app-management/app-catalog/ Description: Instala y gestiona fácilmente aplicaciones macOS no disponibles en la App Store con el catálogo de apps macOS de Applivery. Simplifica el despliegue y controla el acceso de los usuarios. TL;DR: El catálogo de apps macOS de Applivery permite instalar y gestionar fácilmente apps macOS que no se encuentran en la App Store, simplificando el despliegue y el control de acceso de los usuarios. Answers: ¿Qué es el catálogo de apps macOS de Applivery? · ¿Cómo añado una app del catálogo a una política macOS? · ¿Puedo elegir qué versión de una app instalar del catálogo? · ¿Con qué frecuencia se actualizan las apps del catálogo de apps macOS? · ¿Qué tipos de apps están disponibles en el catálogo de apps macOS de Applivery? · ¿Cómo solicito que se añada una app al catálogo de apps macOS de Applivery? · ¿Cuáles son los requisitos para que una app se incluya en el catálogo de apps macOS de Applivery? Key topics: Catálogo de apps macOS, Despliegue de apps, Plataforma Applivery, Gestión de aplicaciones, Applivery, macOS, App Store, Apple Business, 1Clipboard, 1Password, Adobe Acrobat Reader, Aircall, Android Studio, AnyDo ¿No lo encuentras en la App Store? ¡No te preocupes! El **catálogo de apps macOS de Applivery** lo gestiona todo. Con el catálogo de apps macOS de Applivery, puedes instalar fácilmente aplicaciones macOS que todavía no están en la App Store. Nuestra plataforma simplifica todo el proceso, desde la descarga hasta la instalación de cualquier aplicación. Alojamos y actualizamos todas las aplicaciones por ti, dándote control total sobre el despliegue y el acceso de los usuarios. Tú decides cómo se despliegan las apps a tus usuarios, ya sea forzando las instalaciones o poniéndolas disponibles para el Self-Service. ### ¿Qué es el catálogo de apps macOS de Applivery? El catálogo de apps macOS de Applivery consiste en software macOS popular, listo para incluir en tus políticas y distribuir a tus dispositivos. Las apps actuales se actualizan con regularidad y se añaden nuevas continuamente. ### Cómo añadir una app a tu política macOS **Navega a Políticas** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a cualquiera de tus **Políticas** 1 o [crea una nueva](https://docs.applivery.com/es/device-management/general-settings/create-policies/). En el menú lateral izquierdo, selecciona la sección **Apps** 2 y haz clic en el botón **\+ Añadir App** 3. ![add app](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/c3deae50-2369-4ae7-b89b-c9b310e91a50.png) **Añadir apps desde el catálogo** Una vez que aparezca la vista modal, navega a la pestaña **Applivery** y selecciona **macOS** como plataforma. Para el origen de la app, selecciona **App Catalog**. Esto mostrará la lista completa de aplicaciones disponibles actualmente. Además, en la **selección de build**, puedes elegir si quieres instalar la última versión automáticamente o especificar manualmente la versión que deseas instalar. ![app catalog](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/5b50886e-9497-436f-967a-862c01329f4d.png) ### Apps disponibles Aquí tienes una muestra de algunas de las apps disponibles en el catálogo: **1Clipboard** Utilidades. **1Password** Productividad. **Adobe Acrobat Reader** Productividad. **Aircall** Comunicación. **Android Studio** Herramientas para desarrolladores. **AnyDo** Productividad. Explora todas las apps en el [catálogo de apps macOS de Applivery](https://www.applivery.com/macos-app-catalog/). ### Solicitar una app Si tienes una app en mente que te gustaría que incluyéramos, háznoslo saber a través del [formulario de solicitud de apps](https://www.applivery.com/macos-app-catalog/app-request/). La demanda de una app determinará en gran medida su prioridad para convertirse en una app del catálogo de apps macOS de Applivery. Además, los requisitos básicos para que una app sea incluida son: - La app no debe estar disponible en la Mac App Store o Apple Business. - La aplicación debe estar destinada al uso empresarial o corporativo. --- ## Permisos de apps con perfiles PPPC Source: https://docs.applivery.com/es/device-management/apple/macos/app-management/app-permissions/ Description: Usa perfiles PPPC para gestionar remotamente los permisos de apps en dispositivos macOS — controla el acceso a servicios y mejora la seguridad con Applivery. TL;DR: Los perfiles PPPC permiten a los administradores TI gestionar remotamente los permisos de apps macOS, mejorando la seguridad y optimizando los flujos de trabajo. Answers: ¿Qué son los perfiles PPPC en macOS? · ¿Qué versiones de macOS admiten perfiles PPPC? · ¿Cómo identifico los permisos que necesita una app para un perfil PPPC? · ¿Cómo creo un perfil PPPC en Applivery? · ¿Qué información se necesita para definir una app en un perfil PPPC? · ¿Qué ocurre si hay conflictos entre políticas PPPC? · ¿Tienen los usuarios algún control sobre los permisos configurados por los perfiles PPPC? · ¿Necesitan los usuarios reiniciar las apps después de desplegar un perfil PPPC? Key topics: Perfiles PPPC, Permisos de apps macOS, Gestión de dispositivos, Seguridad y privacidad, macOS, PPPC, Applivery, Apple, Photo Booth, FaceTime **Los perfiles PPPC** (o Privacy Preferences Policy Control) permiten a los administradores TI gestionar remotamente los ajustes de privacidad en dispositivos macOS (versión 10.14 Mojave y posterior). Con estos perfiles, puedes preautorizar o denegar el acceso de aplicaciones específicas a servicios macOS como Contactos, Cámara, Micrófono y más. Esto optimiza los flujos de trabajo eliminando los avisos de permisos a los usuarios y mejora la seguridad previniendo accesos no autorizados. ### Identificar los permisos de la app Antes de crear un perfil PPPC, es importante identificar los permisos específicos que requiere una aplicación: - **Entorno de prueba**: Instala la app en un Mac de prueba dedicado o máquina virtual. - **Supervisar avisos de usuario**: Lanza la app y toma nota de los avisos emergentes que soliciten acceso a servicios como la Cámara o los Documentos. - **Comprobar Preferencias del Sistema**: Ve a **Preferencias del Sistema > Seguridad y privacidad > Privacidad**. Busca la app bajo servicios como Contactos o Cámara. Si la app aparece, requiere acceso a ese servicio. ### Crear y asignar un perfil PPPC Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a cualquiera de tus **Políticas** o [crea una nueva](https://docs.applivery.com/es/device-management/general-settings/create-policies/). Haz clic en el botón **\+ Añadir configuración** y localiza la opción **Control de políticas de preferencias de privacidad**. ![privacy preferences](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/02586ccd-53c5-4aed-808e-ca4b08680d6d.png) Deberás hacer clic en el botón **\+ Añadir elemento** para las apps en las que quieras configurar permisos. :::info También puedes elegir **Permitir** o denegar el acceso de una app específica a cada servicio. ::: ![ppc policy](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/08443b02-4be3-4f5d-ae33-42934564c26f.png) Deberás definir la app a la que estás concediendo permisos especificando el **tipo de identificador** 4 y el **Bundle ID** o el identificador de **ruta** de la app. Además, debes añadir el [**Requisito de código de la app**](https://docs.applivery.com/es/device-management/apple/macos/troubleshooting/app-code-requirements/). :::warning **Validar requisito de código**. Marca esta opción para asegurarte de que la app cumple los requisitos de firma de código. ::: ### Consideraciones importantes - **Políticas en conflicto**: Si se aplican varios perfiles PPPC con configuraciones en conflicto, prevalecerá la configuración más restrictiva (denegar). - **Control del usuario**: Aunque las políticas preconfiguran los permisos de las apps, los usuarios aún pueden acceder a ciertos ajustes en apps desarrolladas por Apple como Photo Booth o FaceTime. - **Actualización del dispositivo**: Los usuarios deben relanzar las apps configuradas después del despliegue de la política para que los cambios surtan efecto. --- ## Gestión de actualizaciones Source: https://docs.applivery.com/es/device-management/apple/macos/app-management/app-updates/ Description: Controla cuándo llegan las nuevas versiones de tus apps a los Mac con la Update Policy de Applivery: activa Auto-updates y define cuarentena y periodo de gracia. TL;DR: En cada app de una política, abre Update Policy, activa Auto-updates y define una cuarentena y un periodo de gracia. Las nuevas builds esperan la cuarentena, son opcionales durante la gracia y se instalan automáticamente al vencer la fecha límite. Answers: ¿Cómo retraso las actualizaciones de apps en los Mac gestionados? · ¿Cómo fuerzo una actualización de app tras una fecha límite en macOS? · ¿Qué es el periodo de cuarentena de una actualización? · ¿Qué es el periodo de gracia de una actualización? Key topics: Auto-updates, Periodo de cuarentena, Periodo de gracia, Fecha límite de actualización, Tipos de instalación, Applivery, macOS, Agente de Applivery Cada app que asignas a una política de macOS tiene una **Update Policy**. Con ella decides cuándo llegan las nuevas versiones a tus Mac y cuándo dejan de ser opcionales. Activas **Auto-updates**, defines cuánto espera una nueva build antes de ofrecerse (**cuarentena**) y cuánto tiempo tienen los usuarios para instalarla antes de que se aplique de forma obligatoria (**periodo de gracia**). ### Antes de empezar - Dispositivos macOS gestionados con Applivery. - Una app asignada a una política. El **tipo de instalación** de la app (Instalación forzada, Requerida para la configuración o Disponible) cambia lo que ocurre con Auto-updates desactivado. Encontrarás los tres tipos explicados en [Gestión de apps](https://docs.applivery.com/es/device-management/apple/app-management/manage-apps/). - Acceso al [panel de Applivery](https://dashboard.applivery.io/) con permiso para editar políticas. ### Opciones de la Update Policy

Opción

Rango

Qué hace

Auto-updates

Activado / Desactivado

Activa las actualizaciones automáticas de esta app. La cuarentena y la gracia solo se aplican si está activado.

Cuarentena

0–30 días

Días que espera una nueva build desde su publicación antes de ofrecerse. Un único valor para las actualizaciones major, minor y patch.

Periodo de gracia (major, minor, patch)

0–90 días cada uno

Días que la actualización es opcional cuando termina la cuarentena. Configuras un valor distinto para cada tipo de actualización. Con 0, no hay periodo opcional.

:::info En cuanto configures cualquier periodo de gracia, Auto-updates tiene que estar activado. ::: ### Configurar la Update Policy **Abre la app en la política** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), ve a **Políticas** 1 o [**crea una nueva**](https://docs.applivery.com/es/device-management/general-settings/create-policies/). Selecciona la sección de Apps 2 desde el menú lateral izquierdo y añade la aplicación o abre una que ya se encuentre asignada 3. ![app updates](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/22d3a0d8-f732-4469-9aad-64f784b1a884.png) **Configura la Update Policy** Abre **Update Policy** 4, activa **Política de actualizaciones** y define la **cuarentena** y el **periodo de gracia** para las actualizaciones major, minor y patch. ![automatic updates](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/4e108f25-d3b6-499d-89c1-eb4cf9db3a75.png) **Guarda** Guarda los cambios. ### Cómo se calcula la fecha límite Applivery calcula la fecha límite de cada nueva build y la envía al agente de Applivery en el Mac: **Fecha límite = fecha de publicación + cuarentena + periodo de gracia de ese tipo de actualización** El periodo de gracia que se usa depende de si la nueva build es una actualización major, minor o patch. :::info La fecha límite siempre se cuenta desde la fecha de publicación de la build. Si la build llega antes a un Mac por cualquier motivo, la fecha límite no cambia. ::: ### Qué pasa en cada fase

Fase

Qué pasa

Cuarentena

La nueva build no se ofrece. Tus Mac reciben la build más reciente que ya ha superado la cuarentena. Si todavía ninguna la ha superado, la app no se sirve.

Periodo de gracia

La actualización está disponible, pero instalarla es opcional hasta la fecha límite.

Tras la fecha límite

El agente de Applivery instala la actualización. Si la app está abierta, primero se cierra y después se actualiza.

:::info La cuarentena no retiene las instalaciones enviadas con un comando MDM de Apple, las instalaciones durante el Asistente de configuración, las asignaciones fijadas a una build concreta ni la [composición de políticas](https://docs.applivery.com/es/device-management/general-settings/policy-composition/). ::: ### Con Auto-updates desactivado Con Auto-updates desactivado, no hay actualizaciones automáticas después de la primera instalación. Lo que eso supone depende del tipo de instalación:

Tipo de instalación

Comportamiento

Instalación forzada

Solo la primera versión. Sin actualizaciones automáticas posteriores.

Requerida para la configuración

Solo la primera versión. Sin actualizaciones automáticas posteriores.

Disponible

Los usuarios instalan las actualizaciones desde la app de Self-Service.

Si nunca has configurado Auto-updates en una app, Applivery no envía ninguna política de actualización y el agente de Applivery mantiene su comportamiento por defecto. No es lo mismo que desactivar Auto-updates. ### Ejemplo **Actualización de versiones con Actualizaciones automáticas activado.** La cuarentena es de 3 días y el periodo de gracia para patch, de 7 días. Se publica una nueva build el lunes: 1. **De lunes a miércoles:** la build está en cuarentena y no se ofrece. 2. **Jueves:** termina la cuarentena y empieza el periodo de gracia. Los usuarios pueden instalar la actualización cuando quieran. 3. **El jueves siguiente:** vence la fecha límite y el agente de Applivery instala la actualización en todos los Mac que sigan en la versión anterior. **App con Instalación forzada y Actualizaciones automáticas desactivado.** Las nuevas builds no se aplican automáticamente. Tus Mac se quedan en la primera versión instalada hasta que cambies la asignación o actives Actualizaciones automáticas. --- ## Despliegue de Cloudflare WARP Source: https://docs.applivery.com/es/device-management/apple/macos/app-management/cloudflare-warp-deployment/ Description: Distribuye e inscribe el cliente Zero Trust de Cloudflare WARP en Macs gestionados desde una política de Applivery, sin interacción del usuario. TL;DR: Añade el paquete de WARP como instalación forzada e importa un perfil personalizado con tu organización de Cloudflare y el modo de servicio. El cliente se inscribe solo. Answers: ¿Cómo despliego Cloudflare WARP con MDM? · ¿Qué es el payload com.cloudflare.warp? · ¿Dónde encuentro el team name de Cloudflare? · ¿Cómo inscribo WARP sin interacción del usuario? Key topics: Requisitos, Valores que aporta Cloudflare, El perfil de configuración, Montar la política, Applivery, Cloudflare, Cloudflare WARP, Cloudflare Zero Trust, macOS **Cloudflare WARP** es el cliente que hay detrás de Cloudflare Zero Trust: enruta el tráfico del dispositivo por la red de Cloudflare para que las políticas, el filtrado y las comprobaciones de identidad se apliquen esté donde esté el Mac. Desplegarlo a mano significa instalar el cliente en cada equipo y escribir ahí el nombre de la organización, algo que no escala y que rara vez sobrevive al contacto con una flota real. Con Applivery envías las dos mitades desde una sola política —el paquete y su configuración—, así que el cliente se instala y se inscribe sin que nadie toque el Mac. ### Requisitos Para desplegar Cloudflare WARP en macOS a través de Applivery, asegúrate de tener lo siguiente: - **El paquete de Cloudflare WARP.** El `.pkg` de macOS está disponible en el [catálogo de apps de Applivery](https://docs.applivery.com/es/device-management/apple/macos/app-management/app-catalog/). - **Una organización de Cloudflare Zero Trust.** Free, Standard o Enterprise. El **plan Free cubre hasta 50 usuarios**, que suele bastar para un piloto o un equipo pequeño; comprueba el número de licencias en el panel de Cloudflare antes de dar por hecho que cubre a todo el mundo. - **Tu team name de Cloudflare.** El identificador único de tu organización de Zero Trust. Va en el perfil como `organization`, así que tiene que existir antes de generarlo. - **Macs inscritos en Applivery.** Mediante Apple Business y Automated Device Enrollment para un despliegue silencioso y sin intervención, o mediante inscripción manual. Sin inscripción previa no hay forma gestionada de enviar el perfil. **Consigue los valores en Cloudflare** Todo lo que necesita el perfil sale del panel de **Cloudflare Zero Trust**:

Valor

Dónde encontrarlo

Team name (organization)

En Overview, como team domain con la forma tu-equipo.cloudflareaccess.com. El valor que necesitas es solo tu-equipo, sin el dominio.

Modo de servicio (service_mode)

Decisión tuya: warp para túnel completo, que es lo habitual para una VPN, o 1dot1dot1dot1 para modo solo DNS.

:::info El team name no es un secreto. Ahora bien, cualquier parámetro que **fuerce comportamiento** —desactivar el cierre de sesión, forzar la conexión automática— cambia la experiencia del usuario final, así que acuérdalos con el equipo antes de llevarlo a producción. ::: **Prepara el perfil de configuración** Cloudflare recomienda mantener el payload al mínimo, para que configure la inscripción sin sobrescribir lo que ya gestionas desde el panel de Zero Trust. Si prefieres no escribir el XML a mano, [iMazing Profile Editor](https://apps.apple.com/us/app/imazing-profile-editor/id1487860882?mt=12) te lo genera. ```xml PayloadContent PayloadDisplayName Cloudflare WARP Client PayloadIdentifier com.example.profiles.warp-vpn.client PayloadType com.cloudflare.warp PayloadUUID GENERATE-A-UNIQUE-UUID-HERE PayloadVersion 1 display_name Example-Corp-WARP organization example-corp service_mode warp PayloadDisplayName Cloudflare WARP Configuration PayloadIdentifier com.example.profiles.warp-vpn PayloadType Configuration PayloadUUID GENERATE-A-UNIQUE-UUID-HERE PayloadVersion 1 ``` Antes de subirlo, adapta cuatro cosas: - `organization`: tu team name real de Cloudflare, no el valor de ejemplo. - `service_mode`: `warp` para un túnel VPN completo. Cámbialo solo si tu caso de uso es distinto. - **Los dos** `PayloadUUID`: genera UUID nuevos y únicos para cada perfil, tanto el del payload de WARP como el del perfil raíz. Reutilizarlos provoca conflictos, sobre todo si mantienes varias variantes como piloto y producción. - `PayloadIdentifier`: usa tu propia nomenclatura de dominio inverso en lugar de la que haya generado la herramienta de edición. También puedes poner en `display_name` lo que quieras que vea el usuario final en el cliente WARP. Merece la pena si vas a acabar gestionando más de una organización. **Añade el paquete de WARP** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a cualquiera de tus **Políticas** 1 o [crea una nueva](https://docs.applivery.com/es/device-management/general-settings/create-policies/). En el menú lateral izquierdo, selecciona la sección **Apps** 2 y haz clic en el botón **\+ Añadir App** 3. ![add app](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/c3deae50-2369-4ae7-b89b-c9b310e91a50.png) En la vista modal, ve a la pestaña **Applivery**. Selecciona **macOS** como plataforma, elige **App Catalog** como origen de la app y busca **Cloudflare WARP**. En **Build selection**, elige **Last** para asegurarte de que siempre se despliega la última versión. ![cloudflare warp](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/251eb271-dea4-40a2-bb98-39f748603342.png) **Importa el perfil de configuración** Dentro de la política, selecciona **\+ Añadir configuración** en el menú lateral izquierdo, después elige **\+ Importar** y sube tu `.mobileconfig` ya adaptado. Esta es la pieza que realmente define `organization` y `service_mode`, y el motivo de que no haga falta interacción del usuario. ![import profile](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/5a21e731-5b2a-4600-a14a-c2ebbad50d51.png) Una vez hecho, acuérdate de **Guardar cambios** para aplicar la configuración. --- ## Despliegue de Cortex XDR Source: https://docs.applivery.com/es/device-management/apple/macos/app-management/cortex-xdr-deployment/ Description: Despliega Cortex XDR de forma silenciosa en dispositivos macOS usando Applivery MDM — configura perfiles, scripts de activación e instalación silenciosa. TL;DR: Despliega Cortex XDR en macOS de forma silenciosa usando Applivery MDM subiendo el paquete, configurando una política con un script de activación y aplicando un perfil .mobileconfig personalizado. Answers: ¿Qué se necesita para desplegar Cortex XDR en macOS mediante Applivery? · ¿Dónde encuentro el ID de distribución y la dirección Cloud ELB de Cortex XDR? · ¿Cómo subo el paquete de Cortex XDR a Applivery? · ¿Cómo configuro el script de activación en Applivery? · ¿Qué modos de instalación están disponibles para Cortex XDR en Applivery? · ¿Cómo añado el perfil de configuración personalizado de Cortex XDR en Applivery? · ¿Por qué se necesita un perfil .mobileconfig personalizado para Cortex XDR? Key topics: Despliegue de Cortex XDR, MDM macOS, Configuración de Applivery, Seguridad de endpoints, Cortex XDR, macOS, Applivery, Palo Alto Networks, MDM [Cortex XDR de Palo Alto Networks](https://www.paloaltonetworks.es/cortex/cortex-xdr) es una plataforma avanzada de protección de endpoints que integra capacidades de detección, prevención y respuesta. Instalar Cortex XDR en dispositivos macOS a través de tu solución MDM permite un despliegue centralizado y garantiza que todos los endpoints estén protegidos sin necesidad de instalación manual. ### Requisitos Antes de desplegar Cortex XDR en dispositivos macOS a través de Applivery, asegúrate de tener lo siguiente: - **Paquete cliente de Cortex XDR** (`.pkg`). - **ID de distribución** y **dirección Cloud ELB** (desde tu panel de Cortex XDR). - **Script de activación** (para la licencia del agente). - **Política de acceso completo al disco** (mediante perfil de configuración). - **Perfil** `.mobileconfig` **personalizado de Cortex XDR**. - **1 licencia de Applivery** para Distribución de Apps. **Preparar Cortex XDR** Para desplegar Cortex XDR usando Applivery, deberás cargar el paquete de app comprimido (`.zip`) a tu sección de Gestión de Apps y configurarlo con un script de activación previo a la instalación. Primero, descarga el instalador `.pkg` de Cortex XDR desde tu **panel de Cortex XDR** y asegúrate de copiar tu **ID de distribución** y **dirección Cloud ELB**, ya que los necesitarás más adelante para el script de activación. Una vez descargado, comprime el archivo `.pkg` haciendo clic derecho sobre él y seleccionando **Comprimir**, lo que generará un archivo `.zip`. A continuación, inicia sesión en el [**panel de Applivery**](https://dashboard.applivery.io) y navega a la sección **Gestión de Apps**. Desde allí, sigue los pasos de nuestra documentación: 1. [Crea tu primera app](https://docs.applivery.com/es/app-distribution/getting-started/create-first-app/). 2. [Sube tu primera build](https://docs.applivery.com/es/app-distribution/getting-started/upload-first-build/). ![app distribution](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ae4cc3a4-bfa2-4904-9b6e-d6d42544f6b1.png) **Configura tu política de Cortex XDR** A continuación, dirígete a la sección **Gestión de Dispositivos** y selecciona cualquiera de tus **Políticas** 1 o [crea una nueva](https://docs.applivery.com/es/device-management/general-settings/create-policies/). En el menú lateral izquierdo, selecciona la sección **Apps** 2 y haz clic en el botón **\+ Añadir App** 3. ![add app](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/574db999-782f-45a1-b794-89631e0407e9.png) En la vista modal, navega a la pestaña **Applivery**. Configura la plataforma como **macOS**, elige **Tu Workspace** como origen de la app y busca la app **Cortex XDR** que creaste anteriormente. Para la selección de build, elige **Último** para asegurarte de que siempre se despliega la versión más reciente. ![cortex xdr](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ac813cb1-b3b1-4cc8-9942-50ab636d4929.png) Continúa al siguiente paso y selecciona tu **modo de instalación** preferido — **Instalación forzosa**, **Necesario para la instalación** o **Disponible** — según tu estrategia de despliegue. En la sección **Configuración**, selecciona **Pre-install** y pega tu script de activación, asegurándote de reemplazar los valores de marcador de posición con tu **ID de distribución** y **dirección Cloud ELB** reales. ![cortex pre install](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/32e89e42-a7a8-45f0-8176-f81a975859fc.png) ``` #!/bin/bash ## Get current session user currentUser=$(scutil <<< "show State:/Users/ConsoleUser" | awk '/Name :/ && ! /loginwindow/ { print $3 }') #Cortex XDR Distribution ID and Cloud Address <---- MODIFY VARIABLES WITH YOURS distribution="DISTRIBUTION_ID" cloud="CLOUD_ADDRESS" # https:// format ## Path where Config.xml will be saved folderPath="/Users/$currentUser/Library/Application Support/auditApps" filePath="$folderPath/Config.xml" ## Ensure auditApps folder exists and adjust permissions sudo mkdir -p "$folderPath" sudo chown "$currentUser" "$folderPath" sudo chmod 700 "$folderPath" ## Write content to Config.xml using cat sudo cat << EOF > "$filePath" $distribution $cloud EOF ## Adjust file permissions sudo chown "$currentUser" "$filePath" sudo chmod 600 "$filePath" sudo installer -applyChoiceChangesXML "/Users/$currentUser/Library/Application Support/auditApps/Config.xml" -pkg "/Users/$currentUser/Library/Application Support/auditApps/Cortex XDR.pkg" -target / ## Verify if the file was created successfully if [[ -f "$filePath" ]]; then echo "Config.xml created at $filePath" else echo "Error creating Config.xml" exit 1 fi ``` **.mobileconfig personalizado de Cortex XDR** Para aplicar la configuración personalizada, navega a la política deseada y haz clic en + Añadir configuración en el menú del lado izquierdo. Luego, selecciona el botón + Importar y pega el contenido .xml proporcionado en el editor: ```xml PayloadContent PayloadDisplayName Cortex XDR Privacy Preferences Policy Control PayloadIdentifier com.apple.TCC.configuration-profile-policy.7388C706-49BA-4067-BADE-8D031B084B69 PayloadType com.apple.TCC.configuration-profile-policy PayloadUUID 7388C706-49BA-4067-BADE-8D031B084B69 PayloadVersion 1 Services Accessibility Allowed CodeRequirement identifier "com.paloaltonetworks.cortex.agent" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = PXPZ95SK77 Identifier com.paloaltonetworks.cortex.agent IdentifierType bundleID StaticCode SystemPolicyAllFiles Allowed CodeRequirement identifier "com.paloaltonetworks.traps.securityextension" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = PXPZ95SK77 Identifier com.paloaltonetworks.traps.securityextension IdentifierType bundleID StaticCode Allowed CodeRequirement identifier pmd and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = PXPZ95SK77 Identifier /Library/Application Support/PaloAltoNetworks/Traps/bin/pmd IdentifierType path StaticCode AllowUserOverrides AllowedSystemExtensions PXPZ95SK77 com.paloaltonetworks.traps.securityextension com.paloaltonetworks.traps.networkextension PayloadDisplayName Cortex XDR System Extensions PayloadIdentifier com.apple.system-extension-policy.93526FBD-2421-4402-9CAF-210780E2D0FF PayloadType com.apple.system-extension-policy PayloadUUID 93526FBD-2421-4402-9CAF-210780E2D0FF PayloadVersion 1 FilterDataProviderBundleIdentifier com.paloaltonetworks.traps.networkextension FilterDataProviderDesignatedRequirement identifier "com.paloaltonetworks.traps.networkextension" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = PXPZ95SK77 FilterGrade firewall FilterPacketProviderBundleIdentifier com.paloaltonetworks.traps.networkextension FilterPacketProviderDesignatedRequirement identifier "com.paloaltonetworks.traps.networkextension" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = PXPZ95SK77 FilterPackets FilterSockets FilterType Plugin PayloadDescription Content Filter for the Cortex XDR agent network extension PayloadDisplayName Cortex XDR Network Content Filter PayloadIdentifier com.apple.webcontent-filter.CA9C208A-EC6D-4565-864D-02B30DE9D56A PayloadType com.apple.webcontent-filter PayloadUUID CA9C208A-EC6D-4565-864D-02B30DE9D56A PayloadVersion 1 PluginBundleID com.paloaltonetworks.cortex.app UserDefinedName Cortex XDR Network Filter NotificationSettings AlertType 1 BadgesEnabled BundleIdentifier com.paloaltonetworks.traps-agent CriticalAlertEnabled GroupingType 0 NotificationsEnabled PreviewType 0 ShowInCarPlay ShowInLockScreen ShowInNotificationCenter SoundsEnabled AlertType 1 BadgesEnabled BundleIdentifier com.paloaltonetworks.cortex.agent CriticalAlertEnabled GroupingType 0 NotificationsEnabled PreviewType 0 ShowInCarPlay ShowInLockScreen ShowInNotificationCenter SoundsEnabled PayloadDisplayName Cortex XDR Notifications PayloadIdentifier com.apple.notificationsettings.FE495ADF-1E68-4486-9BB6-0E75D6C3177E PayloadType com.apple.notificationsettings PayloadUUID FE495ADF-1E68-4486-9BB6-0E75D6C3177E PayloadVersion 1 PayloadDisplayName Cortex XDR Managed Login Items PayloadIdentifier com.apple.servicemanagement.1645DB60-CBC6-4AE2-A679-BC52DD4C85CE PayloadType com.apple.servicemanagement PayloadUUID 1645DB60-CBC6-4AE2-A679-BC52DD4C85CE PayloadVersion 1 Rules Comment Allows Cortex XDR launch daemons and launch agents RuleType LabelPrefix RuleValue com.paloaltonetworks.cortex TeamIdentifier PXPZ95SK77 PayloadDescription Cortex XDR Config: PPPC + SE + Content Filter + Notifications + BTM PayloadDisplayName Cortex XDR Agent Unified Config Profile v5 PayloadIdentifier com.paloaltonetworks.cortex.AA16E926-D153-4B2E-B4CC-342BB PayloadOrganization Palo Alto Networks PayloadRemovalDisallowed PayloadScope System PayloadType Configuration PayloadUUID AA16E926-D153-4B2E-B4CC-342BB PayloadVersion 1 TargetDeviceType 5 ``` Una vez hecho, asegúrate de **Guardar cambios** para aplicar la configuración. --- ## Despliegue de CrowdStrike Falcon Source: https://docs.applivery.com/es/device-management/apple/macos/app-management/crowdstrike-falcon-deployment/ Description: Despliega y configura el sensor CrowdStrike Falcon en dispositivos macOS usando Applivery para una protección de endpoints y gestión de seguridad mejoradas. TL;DR: Despliega y configura CrowdStrike Falcon en macOS usando Applivery subiendo el paquete, configurando políticas y configurando el acceso completo al disco para una seguridad de endpoints mejorada. Answers: ¿Qué es CrowdStrike Falcon? · ¿Cuáles son los requisitos para desplegar CrowdStrike Falcon en macOS con Applivery? · ¿Cómo preparo el paquete de CrowdStrike Falcon para Applivery? · ¿Dónde configuro la política de CrowdStrike Falcon en Applivery? · ¿Cómo activo CrowdStrike Falcon tras la instalación mediante Applivery? · ¿Cómo concedo acceso completo al disco a CrowdStrike Falcon en macOS? · ¿Cómo añado el perfil de configuración personalizado de CrowdStrike Falcon? · ¿Cuál es el propósito del script de activación? Key topics: Despliegue de CrowdStrike Falcon, Configuración macOS, Applivery MDM, Seguridad de endpoints, Política de acceso completo al disco, CrowdStrike Falcon, Applivery, macOS, CID, Grouping Tag **CrowdStrike Falcon** es una potente plataforma de seguridad nativa en la nube diseñada para ofrecer antivirus y protección de endpoints líder en el sector para dispositivos macOS y Windows. Aprovechando tecnologías de vanguardia como la **inteligencia artificial (IA)** y el **aprendizaje automático (ML)**, Falcon detecta, previene y responde de forma proactiva a las amenazas antes de que puedan afectar a tus sistemas. Ya sea que gestiones una flota de endpoints o protejas un entorno de trabajo híbrido, CrowdStrike Falcon ofrece protección en tiempo real, impacto mínimo en el sistema y capacidades de integración robustas. ### Requisitos Para desplegar CrowdStrike Falcon en macOS a través de Applivery, asegúrate de tener lo siguiente: - **Paquete cliente de CrowdStrike Falcon** (`.pkg`). - **Identificación del cliente (CID)** y **Grouping Tag** proporcionados por CrowdStrike. - **Script de activación** (para la licencia del agente). - **Política de acceso completo al disco** (mediante perfil de configuración). - **Perfil** `.mobileconfig` **personalizado**. - **Configuración de filtro de contenido web** para garantizar una cobertura de protección completa. - **1 licencia de Applivery** para Distribución de Apps. **Prepara tu CrowdStrike Falcon** Para desplegar CrowdStrike Falcon usando Applivery, deberás cargar el paquete de app comprimido (`.zip`) a tu sección de Gestión de Apps y configurarlo con un script de activación posterior a la instalación. Primero, descarga el instalador `.pkg` de CrowdStrike Falcon desde tu **panel de CrowdStrike** y asegúrate de copiar tu **CID** y **Grouping Tag**, ya que los necesitarás más adelante para el script de activación. Una vez descargado, comprime el archivo `.pkg` haciendo clic derecho sobre él y seleccionando **Comprimir**, lo que generará un archivo `.zip`. A continuación, inicia sesión en el [**panel de Applivery**](https://dashboard.applivery.io) y navega a la sección **Gestión de Apps**. Desde allí, sigue los pasos de nuestra documentación: 1. [Crea tu primera app](https://docs.applivery.com/es/app-distribution/getting-started/create-first-app/). 2. [Sube tu primera build](https://docs.applivery.com/es/app-distribution/getting-started/upload-first-build/). ![app distribution](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ae4cc3a4-bfa2-4904-9b6e-d6d42544f6b1.png) **Configura tu política de CrowdStrike Falcon** A continuación, dirígete a la sección **Gestión de Dispositivos** y selecciona cualquiera de tus **Políticas** 1 o [crea una nueva](https://docs.applivery.com/es/device-management/general-settings/create-policies/). En el menú lateral izquierdo, selecciona la sección **Apps** 2 y haz clic en el botón **\+ Añadir App** 3. ![add app](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/574db999-782f-45a1-b794-89631e0407e9.png) En la vista modal, navega a la pestaña **Applivery**. Configura la plataforma como **macOS**, elige **Tu Workspace** como origen de la app y busca la app **Falcon Sensor** que creaste anteriormente. Para la selección de build, elige **Último** para asegurarte de que siempre se despliega la versión más reciente. ![falcon sensor](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/d09c789d-ce9c-453f-a9de-d50effd7dbcc.png) Continúa al siguiente paso y selecciona tu **modo de instalación** preferido — **Instalación forzosa**, **Necesario para la instalación** o **Disponible** — según tu estrategia de despliegue. En la sección **Configuración**, selecciona **Post-install** 9 y pega tu script de activación, asegurándote de reemplazar los valores de marcador de posición con tu **CID** y **Grouping Tag** reales. ![falcon sensor post install](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/1e55f53d-4292-4393-aedd-01bfb445a602.png) ``` #!/bin/bash ## Configure CID and Grouping Tag <----- MODIFY WITH YOUR VARIABLES CID="CID" GROUPING_TAG="TAG" #OPTIONAL ## Apply CID license sudo /Applications/Falcon.app/Contents/Resources/falconctl license "$CID" ## Set Grouping Tag. Comment it if you will not use tags. sudo /Applications/Falcon.app/Contents/Resources/falconctl grouping-tags set "$GROUPING_TAG" ## Restart the service to apply changes sudo /Applications/Falcon.app/Contents/Resources/falconctl unload sudo /Applications/Falcon.app/Contents/Resources/falconctl load echo "Configuration successfully updated." ``` **Política de acceso completo al disco** Para garantizar el correcto funcionamiento de la app tras la instalación, debemos concederle permisos de **acceso completo al disco**. Dentro de la política, selecciona **+Añadir configuración** en el menú lateral izquierdo y elige **Control de políticas de preferencias de privacidad**. ![privacy preferences](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/3d322909-6c49-44dc-a842-e313d8c6f036.png) A continuación, añadiremos **dos entradas relacionadas con System Policy All Files**. Para cada elemento añadido a esta configuración, establece el acceso como **Permitido**. La primera configuración debe incluir los siguientes parámetros: - **Requisito de código**: `identifier "com.crowdstrike.falcon.Agent" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists / and certificate leaf[field.1.2.840.113635.100.6.1.13] / exists */ and certificate leaf[subject.OU] = X9E956P446` - **Identificador**: `com.crowdstrike.falcon.Agent`. - **Tipo de identificador**: Bundle ID. - **Código estático**: Desactivado. Para la segunda configuración: - **Requisito de código**: `identifier "com.crowdstrike.falcon.App" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists / and certificate leaf[field.1.2.840.113635.100.6.1.13] / exists */ and certificate leaf[subject.OU] = X9E956P446` - **Identificador**: `com.crowdstrike.falcon.App`. - **Tipo de identificador**: Bundle ID. - **Código estático**: Desactivado. **.mobileconfig personalizado de CrowdStrike Falcon** Para aplicar la configuración personalizada, navega a la política deseada y haz clic en **\+ Añadir configuración** en el menú del lado izquierdo. Luego, selecciona el botón **\+ Importar** y pega el contenido `.xml` proporcionado en el editor: ```xml PayloadDescription Network Content Filter, System Extensions, and Privacy Preferences PayloadDisplayName Crowdstrike Settings PayloadEnabled PayloadIdentifier com.applivery.crowdstrike PayloadOrganization Applivery, Inc. PayloadRemovalDisallowed PayloadScope System PayloadType Configuration PayloadUUID bbc888dc-6f2c-479d-9f3a-ce0593e6420e PayloadVersion 1 PayloadContent FilterBrowsers FilterDataProviderBundleIdentifier com.crowdstrike.falcon.Agent FilterDataProviderDesignatedRequirement identifier "com.crowdstrike.falcon.Agent" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] and certificate leaf[field.1.2.840.113635.100.6.1.13] and certificate leaf[subject.OU] = "X9E956P446" FilterGrade inspector FilterPacketProviderBundleIdentifier com.crowdstrike.falcon.Agent FilterPacketProviderDesignatedRequirement identifier "com.crowdstrike.falcon.Agent" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] and certificate leaf[field.1.2.840.113635.100.6.1.13] and certificate leaf[subject.OU] = "X9E956P446" FilterPackets FilterSockets FilterType Plugin Organization CrowdStrike Inc. PayloadDisplayName Web Content Filter PayloadIdentifier io.applivery.crowdstrike.2C5CBFD0-7CFE-41CB-95BC-A681F4D293B8 PayloadType com.apple.webcontent-filter PayloadUUID 2C5CBFD0-8CFE-41CB-95BC-A681F4D293B8 PayloadVersion 1 PluginBundleID com.crowdstrike.falcon.App UserDefinedName Falcon AllowUserOverrides AllowedSystemExtensionTypes X9E956P446 EndpointSecurityExtension NetworkExtension AllowedSystemExtensions X9E956P446 com.crowdstrike.falcon.Agent NonRemovableFromUISystemExtensions X9E956P446 com.crowdstrike.falcon.Agent PayloadDescription Configures System Extensions Policy settings PayloadDisplayName System Extensions PayloadIdentifier 20258B06-5889-4424-8893-A3AF1AFAAEDC PayloadOrganization CrowdStrike Inc. PayloadType com.apple.system-extension-policy PayloadUUID 20258B06-5889-4424-8893-A3AF1AFAAEDC PayloadVersion 1 NotificationSettings BundleIdentifier com.crowdstrike.falcon.UserAgent NotificationsEnabled PayloadDisplayName Notifications PayloadIdentifier 61090B22-3DCD-435E-ABB2-BE997B3CB78D PayloadType com.apple.notificationsettings PayloadUUID 61090B22-3DCD-435E-ABB2-BE997B3CB78D PayloadVersion 1 PayloadDescription Configures Privacy Preferences Policy Control settings PayloadDisplayName Privacy Preferences PayloadIdentifier 9A10BE5D-5E57-4C22-89C9-20597A04B616 PayloadOrganization CrowdStrike Inc. PayloadType com.apple.TCC.configuration-profile-policy PayloadUUID 9A10BE5D-5E57-4C22-89C9-20597A04B616 PayloadVersion 1 Services SystemPolicyAllFiles Allowed CodeRequirement identifier "com.crowdstrike.falcon.Agent" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = "X9E956P446" Comment Identifier com.crowdstrike.falcon.Agent IdentifierType bundleID StaticCode Allowed CodeRequirement identifier "com.crowdstrike.falcon.App" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = X9E956P446 Comment Identifier com.crowdstrike.falcon.App IdentifierType bundleID StaticCode PayloadDescription PayloadDisplayName Crowdstrike Falcon Content Filter PayloadEnabled PayloadRemovalDisallowed PayloadScope System PayloadType Configuration PayloadVersion 1 ``` Una vez hecho, asegúrate de **Guardar cambios** para aplicar la configuración. --- ## Despliegue de Escrow Buddy Source: https://docs.applivery.com/es/device-management/apple/macos/app-management/escrow-buddy-deployment/ Description: Custodia las claves de recuperación de FileVault en tu MDM usando Escrow Buddy y Applivery — despliegue silencioso y configuración para dispositivos macOS. TL;DR: Despliega Escrow Buddy con Applivery para custodiar de forma segura las claves de recuperación de FileVault en dispositivos macOS, mejorando la seguridad y el cumplimiento. Answers: ¿Qué es Escrow Buddy? · ¿Cuáles son los requisitos para desplegar Escrow Buddy con Applivery? · ¿Dónde puedo descargar el paquete de Escrow Buddy? · ¿Cómo subo el script de rotación de claves de recuperación de FileVault en Applivery? · ¿Cómo añado Escrow Buddy a una política de dispositivo en Applivery? · ¿Cómo configuro el script post-instalación de Escrow Buddy en Applivery? · ¿Con qué frecuencia debe ejecutarse el script de rotación de claves de recuperación de FileVault? · ¿Cómo me aseguro de que FileVault está activado en la política de dispositivo? Key topics: Cifrado FileVault, Gestión de dispositivos macOS, Configuración de Escrow Buddy, Escrow Buddy, Applivery, FileVault, GitHub **Escrow Buddy** es una utilidad ligera diseñada para custodiar de forma segura las claves de recuperación de FileVault en tu MDM. Al gestionar dispositivos macOS con Applivery, usar Escrow Buddy simplifica el cumplimiento de las políticas de cifrado de disco y garantiza que las claves de recuperación estén almacenadas de forma segura y accesibles cuando sea necesario. ### Requisitos Antes de desplegar Escrow Buddy en dispositivos macOS a través de Applivery, asegúrate de tener lo siguiente: - **Paquete de Escrow Buddy** (`.pkg`). - **Script post-instalación**. - **FileVault activado en la política de dispositivo**. - **Script de rotación de claves de recuperación de FileVault**. - **1 licencia de Applivery** para Distribución de Apps. ### Configuración de Escrow Buddy **Preparar Escrow Buddy** Para desplegar Escrow Buddy usando Applivery, deberás cargar el paquete de app comprimido (`.zip`) a tu sección de **Gestión de Apps** y configurarlo con un script post-instalación. Primero, descarga el instalador `.pkg` de Escrow Buddy desde el repositorio de [GitHub](https://github.com/macadmins/escrow-buddy?tab=readme-ov-file). Una vez descargado, comprime el archivo `.pkg` haciendo clic derecho sobre él y seleccionando **Comprimir**, lo que generará un archivo `.zip`. A continuación, inicia sesión en el [**panel de Applivery**](https://dashboard.applivery.io) y navega a la sección **Gestión de Apps**. Desde allí, sigue los pasos de nuestra documentación: 1. [Crea tu primera app](https://docs.applivery.com/es/app-distribution/getting-started/create-first-app/). 2. [Sube tu primera build](https://docs.applivery.com/es/app-distribution/getting-started/upload-first-build/). ![](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/9d2785ae-7ef4-44f7-aa46-3d0a6a49a09a.png) :::tip Para garantizar que la clave de recuperación de FileVault se custodia correctamente y sigue siendo válida con el tiempo, recomendamos usar un script de monitoreo que se ejecute con regularidad, por ejemplo una vez cada 7 días. Este script, cuando se aplica a la política y se programa en consecuencia, ayudará a detectar cualquier problema con la clave de FileVault actual. Si se identifica un problema, el script eliminará automáticamente la clave no válida, generará una nueva y la custodiará de forma segura en el inventario del dispositivo dentro de Applivery. ::: **Subir el script de rotación de claves de recuperación de FileVault** A continuación, dirígete a la sección **Gestión de Dispositivos** y selecciona **Recursos** 1. Selecciona la sección **Scripts** 2 desde el menú lateral izquierdo y haz clic en el botón **\+ Crear Script** 3. ![escrow budy script creation](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/f34c71ab-171c-4023-985e-10728ab718e2.png) Copia el script bash proporcionado y **créalo** 4 como **Script de rotación de clave FileVault**. ``` #!/bin/bash defaults write /Library/Preferences/com.netflix.Escrow-Buddy.plist GenerateNewKey -bool true exit 0 ``` **Configura tu política de Escrow Buddy** Ahora, dirígete a cualquiera de tus **Políticas** 1 o [crea una nueva](https://docs.applivery.com/es/device-management/general-settings/create-policies/). En el menú lateral izquierdo, selecciona la sección **Apps** 2 y haz clic en el botón + Añadir App 3. ![add app](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/8c66994f-4986-499c-8b3e-95e410066115.png) En la vista modal, navega a la pestaña **Applivery**. Configura la plataforma como **macOS**, elige **Tu Workspace** como origen de la app y busca la app **Escrow Buddy** que creaste anteriormente. Para la selección de build, elige **Último** para asegurarte de que siempre se despliega la versión más reciente. ![add app form](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/039eeedd-3507-4463-ad1b-8667a0dd7dd9.png) Continúa al siguiente paso y selecciona **Instalación forzosa** como **modo de instalación**. En la sección **Configuración**, selecciona **Post-install** y pega tu script. ![escrow buddy post install](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/c083dfab-a672-45ff-8ea5-3c1a38bf589b.png) ``` #!/bin/bash APP_NAME="Escrow Buddy.app" APP_BUNDLE_ID="com.netflix.Escrow-Buddy" APP_PATH="/Applications/${APP_NAME}" ## Create the app structure with appropriate permissions sudo mkdir -p "${APP_PATH}/Contents/MacOS" sudo mkdir -p "${APP_PATH}/Contents/Resources" ## Verify if the structure was created successfully if [[ ! -d "${APP_PATH}/Contents/MacOS" ]]; then echo "Error: Could not create the application structure" exit 1 fi ## Create Info.plist file sudo tee "${APP_PATH}/Contents/Info.plist" > /dev/null < CFBundleIdentifier ${APP_BUNDLE_ID} CFBundleName Escrow Buddy CFBundleVersion 1.0.0 CFBundleShortVersionString 1.0.0 CFBundleExecutable EscrowSecurityAlert EOF ## Create an empty executable with appropriate permissions sudo touch "${APP_PATH}/Contents/MacOS/${APP_NAME}" sudo chmod +x "${APP_PATH}/Contents/MacOS/${APP_NAME}" ## Verify that the app exists ls -ld "${APP_PATH}" ``` **Configurar FileVault** A continuación, debemos configurar la política para activar FileVault en los dispositivos. Para ello, sigue los pasos de nuestra [documentación](https://docs.applivery.com/es/device-management/apple/macos/policies/filevault/) en la sección **Gestión de clave de recuperación – Auto**. **Añadir el script a la política** Una vez que FileVault esté correctamente activado, es importante añadir el **Script de rotación de clave FileVault** para garantizar que cualquier clave de recuperación de FileVault no válida o faltante sea detectada y corregida automáticamente. Esto garantiza que Applivery siempre conserve una clave válida y custodiada para cada dispositivo. Para añadir el script, navega a **Scripts** desde el menú lateral izquierdo y haz clic en el botón + Añadir Script. Luego busca y selecciona el **Script de rotación de clave FileVault** que se subió anteriormente a la sección **Recursos**. Para el método de ejecución, recomendamos elegir **Loop** y establecer el intervalo de repetición según las necesidades de tu organización (por ejemplo, cada 7 días). ![](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/b98076d2-9821-4605-b473-2b86dab4d054.png) Por último, haz clic en **Añadir** para incluir el script en la política y **Guardar cambios** para desplegarlo. --- ## Despliegue de PKG Source: https://docs.applivery.com/es/device-management/apple/macos/app-management/pkg-deployment/ Description: Despliega archivos PKG en dispositivos macOS usando Applivery MDM para una instalación y gestión de apps optimizadas. TL;DR: Despliega archivos PKG en dispositivos macOS usando Applivery para una instalación y gestión de apps optimizadas, ya sea individualmente o a través de políticas. Answers: ¿Qué es un archivo PKG? · ¿Cómo puedo desplegar un PKG en un dispositivo específico con Applivery? · ¿Cómo despliego PKGs usando las políticas de Applivery? · ¿Qué versiones de macOS admiten el despliegue de PKG con Applivery? · ¿Cómo puedo asegurarme de que siempre se despliega la última versión de un PKG? · ¿Puedo desplegar apps no disponibles en la App Store en dispositivos macOS? · ¿Dónde puedo encontrar la sección Distribución de Apps en Applivery? Key topics: Despliegue de apps macOS, Gestión de archivos PKG, Mobile device management, Applivery, macOS, Archivos PKG Los paquetes son como parcelas bien envueltas para tu software — vienen con todos los componentes necesarios para instalar o actualizar aplicaciones en tu dispositivo. Estos archivos suelen terminar en `.pkg` o `.mpkg`, contienen todo lo necesario para instalaciones, actualizaciones y eliminaciones de apps sin problemas. Además, puede que necesites estos paquetes de aplicaciones (PKGs) para desplegar apps en dispositivos con macOS 10.13.6 o posterior. :::info Dependiendo de tu plan de suscripción, puedes distribuirlos a dispositivos individuales o gestionar el despliegue a través de políticas para un enfoque más optimizado. Consulta las opciones de precios disponibles para ver qué funciones están incluidas [aquí](https://www.applivery.com/device-management-pricing/). ::: Veamos ahora cómo conseguirlo. **Despliegue de PKGs en dispositivos individuales** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), localiza el dispositivo en el que quieres instalar el PKG en la sección **Dispositivos**. Navega a la pestaña **Apps** y haz clic en el botón **Instalar desde archivo**. Esto te permitirá seleccionar el PKG desde tu unidad e **instalarlo** en tu dispositivo. ![install form file](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/044427a1-b6e1-4133-943a-e758ed692e1e.png) **Usar políticas para optimizar la gestión de PKGs** Alternativamente, los PKGs pueden gestionarse a través de la **Gestión de Apps** de Applivery. Esta función te permite desplegar paquetes desde **Applivery** a nivel de política, además de mantener versiones actualizadas de los PKGs. Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), navega a la sección **Gestión de Apps** y sigue los pasos de nuestra documentación para [crear tu primera app](https://docs.applivery.com/es/app-distribution/getting-started/create-first-app/) y [subir tu primera build](https://docs.applivery.com/es/app-distribution/getting-started/upload-first-build/). ![app distribution](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/f339a905-22de-4c47-8238-98face2a90a9.png) Tras subir tu PKG, dirígete a cualquiera de tus **Políticas** o [crea una nueva](https://docs.applivery.com/es/device-management/general-settings/create-policies/). Navega a la sección **Apps** en el menú lateral izquierdo y haz clic en el botón **\+ Añadir App**. En la vista modal, navega a la pestaña **Applivery**. Configura la plataforma como **macOS**, elige **Tu Workspace** como origen de la app y busca la app que quieres desplegar en tus dispositivos. Para la selección de build, elige **Último** para asegurarte de que siempre se despliega la versión más reciente. ![add app from app distribution](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/dd275dc6-bd0b-4762-ba0e-3da44321a83b.png) :::info También puedes desplegar apps no disponibles en la App Store en tus dispositivos macOS usando el **catálogo de apps macOS de Applivery**. Al seleccionar **App Catalog** como origen de la app, accedes a un repositorio con aplicaciones actualizadas y gestión automática de parches para macOS. Para más detalles, consulta nuestra documentación detallada [aquí](https://docs.applivery.com/es/device-management/apple/macos/app-management/app-catalog/). ::: --- ## Despliegue de SentinelOne Source: https://docs.applivery.com/es/device-management/apple/macos/app-management/sentinelone-deployment/ Description: Protege los endpoints macOS con SentinelOne. Esta guía detalla el despliegue MDM mediante Applivery, incluyendo perfiles de configuración y scripts de activación. TL;DR: Aprende a desplegar y configurar SentinelOne en dispositivos macOS usando Applivery MDM para una seguridad de endpoints mejorada. Key topics: Instalación de SentinelOne, Configuración MDM macOS, Acceso completo al disco, Perfiles de configuración, Script de activación, SentinelOne, macOS, Applivery, macOS Sequoia 15 **El agente SentinelOne** es una plataforma de ciberseguridad avanzada y basada en IA diseñada para proporcionar protección autónoma de endpoints en entornos Windows, macOS y Linux. Aprovechando una arquitectura de agente único, SentinelOne unifica las capacidades de prevención, detección, respuesta y caza de amenazas en tiempo real — sin depender de la conectividad en la nube ni de la intervención humana constante. Desarrollado para los equipos de seguridad modernos, SentinelOne ofrece una protección robusta contra malware, ransomware, ataques sin archivos y amenazas de día cero combinando IA conductual, aprendizaje automático y remediación automatizada. Su potente funcionalidad EDR (Endpoint Detection and Response) permite a las organizaciones no solo detectar y responder a las amenazas rápidamente, sino también obtener una visibilidad profunda de todo el ciclo de vida del ataque. Ya sea que gestiones una plantilla remota o protejas infraestructura empresarial, SentinelOne ofrece una seguridad de endpoints escalable, resiliente y fácil de gestionar adaptada al panorama de amenazas actual en evolución. ### Actualizaciones importantes #### Cambios en macOS Sequoia 15 macOS Sequoia 15 introduce una nueva interfaz que permite a los usuarios ver y gestionar todas las extensiones del sistema instaladas, incluidas las extensiones de red. Esta actualización proporciona a los usuarios un mayor control sobre estos componentes. ![network-extensions](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/25eb8e0f-0ef9-4c44-be78-3f0b79934f40.png "network-extensions | Applivery") Como administrador, es posible que quieras evitar que los usuarios desactiven ciertas extensiones del sistema a través de Configuración del sistema. Para ello, macOS Sequoia 15 incluye una nueva clave `NonRemovableFromUISystemExtensions` dentro del payload `com.apple.system-extension-policy`. Al especificar la **extensión de monitoreo de red de SentinelOne** en este payload, los usuarios aún podrán ver los detalles de la extensión — pero no podrán modificarla ni desactivarla. :::warning La clave `NonRemovableFromUISystemExtensions` **no es compatible con macOS Ventura 13 ni macOS 14 Sonoma**. Por tanto, se recomienda crear un perfil de configuración separado específicamente para macOS Sequoia 15 y posterior. Esto garantiza que cuando los usuarios actualicen a Sequoia, las restricciones correctas se apliquen y se hagan cumplir automáticamente. ::: ### Requisitos Para desplegar SentinelOne en macOS a través de Applivery, asegúrate de tener lo siguiente: - **Paquete del agente SentinelOne** (`.pkg`). - **Token de SentinelOne**. - **Script de activación** (para la licencia del agente). - **Política de acceso completo al disco** (mediante perfil de configuración). - **Perfil** `.mobileconfig` **personalizado**. - **Extensiones del sistema**. - **1 licencia de Applivery** para Distribución de Apps. **Preparar SentinelOne** Para desplegar SentinelOne usando Applivery, deberás cargar el paquete de app comprimido (`.zip`) a tu sección de Gestión de Apps y configurarlo con un script de activación posterior a la instalación. Primero, descarga el instalador `.pkg` de SentinelOne desde tu **panel de SentinelOne** y asegúrate de copiar el **token de tu organización**, ya que lo necesitarás más adelante para el script de activación. Una vez descargado, comprime el archivo `.pkg` haciendo clic derecho sobre él y seleccionando **Comprimir**, lo que generará un archivo `.zip`. A continuación, inicia sesión en el [**panel de Applivery**](https://dashboard.applivery.io) y navega a la sección **Gestión de Apps**. Desde allí, sigue los pasos de nuestra documentación: 1. [Crea tu primera app](https://docs.applivery.com/es/app-distribution/getting-started/create-first-app/). 2. [Sube tu primera build](https://docs.applivery.com/es/app-distribution/getting-started/upload-first-build/). **Configura la política de SentinelOne** Ve a la sección **Gestión de Dispositivos** y ve a cualquiera de tus **Políticas** 1 o crea una nueva. En el menú lateral izquierdo, selecciona la sección **Apps** 2 y haz clic en el botón **\+ Añadir App** 3. ![add app](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/69d0a55b-d5ad-4e1d-b3a1-236d7f5ac46d.png) En la vista modal, navega a la **pestaña Applivery**. Configura la plataforma como **macOS**, elige **Tu Workspace** como origen de la app y busca la app SentinelOne que creaste anteriormente. Para la selección de build, elige **Último** para asegurarte de que siempre se despliega la versión más reciente. ![sentinel one](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/6c91c80d-3764-4a89-9827-b2128f4f74a6.png) Continúa al siguiente paso y selecciona tu **modo de instalación** preferido — **Instalación forzosa**, **Necesario para la instalación** o **Disponible** — según tu estrategia de despliegue. En la sección **Configuración**, selecciona **Pre-install** y pega tu script de activación, asegurándote de reemplazar los valores de marcador de posición con el **token de la organización**. ![sentinel one pre install](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/e6d12abc-0691-496f-b452-69f1146c08c5.png) ``` #!/bin/bash ## Get the currently logged-in user (macOS) currentUser=$(/bin/ls -l /dev/console | /usr/bin/awk '{ print $3 }') ## Ensure we have a valid username if [ -z "$currentUser" ]; then echo "Error: Unable to determine the current user." exit 1 fi ## Define the registration token <<<<---- MODIFY BY YOUR ORGANIZATION'S TOKEN token="TOKEN" ## Define the folder and file path folderPath="/Users/$currentUser/Library/Application Support/auditApps" filePath="$folderPath/com.sentinelone.registration-token" ## Ensure the auditApps folder exists and set proper permissions if ! sudo mkdir -p "$folderPath"; then echo "Error: Failed to create directory $folderPath" exit 1 fi if ! sudo chown "$currentUser" "$folderPath"; then echo "Error: Failed to change ownership of $folderPath" exit 1 fi if ! sudo chmod 700 "$folderPath"; then echo "Error: Failed to set permissions on $folderPath" exit 1 fi ## Write the token to the file and set proper permissions if ! echo "$token" | sudo tee "$filePath" > /dev/null; then echo "Error: Failed to write the token to $filePath" exit 1 fi if ! sudo chown "$currentUser" "$filePath"; then echo "Error: Failed to change ownership of $filePath" exit 1 fi if ! sudo chmod 600 "$filePath"; then echo "Error: Failed to set permissions on $filePath" exit 1 fi ## Open the token file with nano for manual editing as the regular user if ! sudo -u "$currentUser" nano "$filePath"; then echo "Error: Failed to open $filePath in nano" exit 1 fi ## Check if sentinelctl exists before executing if ! command -v /usr/local/bin/sentinelctl &> /dev/null; then echo "Error: sentinelctl command not found." exit 1 fi ## Register the token with SentinelOne if ! sudo -u "$currentUser" /usr/local/bin/sentinelctl set registration-token -- "$token"; then echo "Error: Failed to register the token with SentinelOne." exit 1 fi ## Exit successfully echo "Registration token successfully written and applied." exit 0 ``` **Política de acceso completo al disco** Para garantizar el correcto funcionamiento de la app tras la instalación, debemos concederle permisos de **acceso completo al disco**. Dentro de la política, selecciona **\+ Añadir configuración** en el menú lateral izquierdo y elige **Control de políticas de preferencias de privacidad**. ![privacy preferences](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/2c1e22c7-09ff-4df0-9548-785445a57e6c.png) A continuación, añadiremos varias entradas relacionadas con **System Policy All Files**. Para cada elemento añadido a esta configuración, establece el acceso como **Permitido**. La primera configuración debe incluir los siguientes parámetros: - **Requisito de código**: `anchor apple generic and identifier "com.sentinelone.sentineld" and (certificate leaf[field.1.2.840.113635.100.6.1.9] /* exists */ or certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = "4AYE5J54KN")` - **Identificador**: `com.sentinelone.sentineld`. - **Tipo de identificador**: Bundle ID. - **Código estático**: Desactivado. Para la segunda configuración: - **Requisito de código**: `anchor apple generic and identifier "com.sentinelone.sentineld-shell" and (certificate leaf[field.1.2.840.113635.100.6.1.9] /* exists */ or certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = "4AYE5J54KN")` - **Identificador**: `com.sentinelone.sentineld-helper`. - **Tipo de identificador**: Bundle ID. - **Código estático**: Desactivado. Para la tercera configuración: - **Requisito de código**: `anchor apple generic and identifier "com.sentinelone.sentineld-helper" and (certificate leaf[field.1.2.840.113635.100.6.1.9] /* exists / or certificate 1[field.1.2.840.113635.100.6.2.6] / exists / and certificate leaf[field.1.2.840.113635.100.6.1.13] / exists */ and certificate leaf[subject.OU] = "4AYE5J54KN")` - **Identificador**: `com.sentinelone.sentineld-shell`. - **Tipo de identificador**: Bundle ID. - **Código estático**: Desactivado. Para la última configuración: - **Requisito de código**: `anchor apple generic and identifier "com.sentinelone.sentinel-shell" and (certificate leaf[field.1.2.840.113635.100.6.1.9] /* exists */ or certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = "4AYE5J54KN")` - **Identificador**: `com.sentinelone.sentinel-shell`. - **Tipo de identificador**: Bundle ID. - **Código estático**: Desactivado. **.mobileconfig personalizado de SentinelOne** Para aplicar la configuración personalizada, navega a la política deseada y haz clic en **\+ Añadir configuración** en el menú del lado izquierdo. Luego, selecciona el botón **\+ Importar** y pega el contenido `.xml` proporcionado en el editor: ```xml PayloadContent NotificationSettings BundleIdentifier com.sentinelone.SentinelAgent CriticalAlertEnabled PayloadDescription Configures notifications settings for apps PayloadDisplayName Notifications PayloadIdentifier com.apple.notificationsettings.26E82306-CDA4-4AF0-9714-0B8363D2A26F PayloadType com.apple.notificationsettings PayloadUUID 26E82306-CDA4-4AF0-9714-0B8363D2A26F PayloadVersion 1 PayloadDescription Configures Conference Room Display mode PayloadDisplayName Conference Room Display PayloadIdentifier com.apple.conferenceroomdisplay.B64EF9CA-0B32-43F9-82D7-5ABB51D1422B PayloadType com.apple.conferenceroomdisplay PayloadUUID B64EF9CA-0B32-43F9-82D7-5ABB51D1422B PayloadVersion 1 FilterBrowsers FilterSockets FilterType Plugin Organization Applivery Inc PayloadDescription Configures content filtering settings PayloadDisplayName SentinelOne PayloadIdentifier com.apple.webcontent-filter.B456B4A3-5794-4C8E-99FA-9148C6458AEE PayloadType com.apple.webcontent-filter PayloadUUID B456B4A3-5794-4C8E-99FA-9148C6458AEE PayloadVersion 1 PluginBundleID com.sentinelone.extensions-wrapper UserDefinedName SentinelOne PayloadDisplayName SentinelOne Config PayloadIdentifier com.applivery.sentinelone PayloadOrganization Applivery PayloadRemovalDisallowed PayloadType Configuration PayloadUUID 9B3EA38F-D1C7-4045-A745-AE3AA25ACCEE PayloadVersion 1 ``` Una vez hecho, asegúrate de **Guardar cambios** para aplicar la configuración. --- ## Comandos remotos Source: https://docs.applivery.com/es/device-management/apple/macos/commands/ Description: Comandos macOS en Applivery para la gestión remota de dispositivos — bloquea, borra, reinicia y actualiza dispositivos desde un panel centralizado. TL;DR: Los comandos macOS de Applivery permiten a los administradores gestionar y controlar remotamente dispositivos macOS en tiempo real. Answers: ¿Qué son los comandos macOS en Applivery? · ¿Qué acciones puedo realizar con los comandos macOS? · ¿Cómo ejecuto los comandos macOS? · ¿Por qué usar los comandos macOS? · ¿Se ejecutan los comandos macOS en tiempo real? · ¿Puedo reiniciar remotamente un dispositivo macOS? · ¿Puedo actualizar remotamente un dispositivo macOS? Key topics: Gestión de dispositivos macOS, Comandos remotos, Applivery, Seguridad de dispositivos, Gestión centralizada, macOS Los comandos MDM de macOS te permiten realizar acciones remotas en tiempo real en ordenadores Mac gestionados — bloquear un dispositivo, borrar el código de acceso, reiniciar, borrar todos los datos o actualizar la configuración MDM sin necesidad de acceso físico. Cada comando remoto disponible para macOS incluye sus requisitos previos, como el estado de supervisión, y lo que ocurre en el dispositivo cuando se envía. --- ## Bloqueo de recuperación Source: https://docs.applivery.com/es/device-management/apple/macos/commands/recovery-lock/ Description: Establece, verifica y elimina remotamente el Bloqueo de recuperación de macOS usando los comandos MDM de Applivery para una mayor seguridad del dispositivo. TL;DR: Gestiona remotamente el bloqueo de recuperación de macOS con Applivery para una mayor seguridad del dispositivo. Answers: ¿Qué es el bloqueo de recuperación de macOS? · ¿Cómo puedo establecer un bloqueo de recuperación en un Mac usando Applivery? · ¿Puedo verificar la contraseña de bloqueo de recuperación con Applivery? · ¿Cómo elimino un bloqueo de recuperación usando Applivery? · ¿Qué ocurre si olvido la contraseña del bloqueo de recuperación? · ¿Contra qué protege el bloqueo de recuperación? · ¿Guarda Applivery la contraseña del bloqueo de recuperación? Key topics: macOS, seguridad, MDM, Bloqueo de recuperación, Applivery, Apple, Recuperación de macOS El **Bloqueo de recuperación** es una función de seguridad nativa de macOS diseñada para **proteger el acceso a la recuperación de macOS**. Cuando está activada, evita que usuarios no autorizados reinstalen macOS, borren el disco o modifiquen ajustes críticos del sistema fuera del sistema operativo gestionado. A través de Applivery, los administradores TI pueden **establecer**, **verificar** y **eliminar** el bloqueo de recuperación de forma remota usando comandos MDM oficiales de Apple, sin necesidad de acceso físico al dispositivo ni de interacción del usuario. ### ¿Qué hace el bloqueo de recuperación? Cuando el bloqueo de recuperación está activado en un Mac, el acceso al modo de recuperación está protegido con una contraseña. Sin esta contraseña, no es posible reinstalar macOS, borrar el dispositivo ni realizar acciones de recuperación a nivel del sistema. Esto añade una capa extra de protección contra el robo, el acceso no autorizado o la manipulación física, especialmente en dispositivos corporativos totalmente gestionados. ### Establecer un bloqueo de recuperación Applivery permite a los administradores establecer una contraseña de bloqueo de recuperación personalizada enviando un comando MDM directamente al dispositivo. **Navega al dispositivo de destino** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io), dirígete a cualquiera de tus **Dispositivos** 1 y abre la pestaña **Comandos** 2. **Establecer bloqueo de recuperación** Haz clic en **\+ Nuevo comando** 3 y, en la sección **Bloqueo de recuperación**, elige **Establecer bloqueo de recuperación** 4. ![set recovery lock](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/121ad47a-f4c3-4312-9d2f-8be01b3d92cf.png) Define la **contraseña deseada** y haz clic en **Enviar** para ejecutar el comando. La contraseña se aplica inmediatamente. No se requiere ninguna acción del usuario final y el dispositivo estará protegido la próxima vez que se acceda a la recuperación de macOS. Este enfoque es especialmente recomendable para los Macs totalmente gestionados en entornos corporativos. ### Verificar la contraseña de bloqueo de recuperación Applivery también permite a los administradores **verificar si una contraseña de bloqueo de recuperación es válida**, sin necesidad de reiniciar el dispositivo ni acceder al modo de recuperación. **Navega a los comandos del dispositivo** Desde la pestaña **Comandos** del dispositivo, haz clic en **\+ Nuevo comando**. **Selecciona Verificar bloqueo de recuperación** Selecciona **Verificar bloqueo de recuperación**, introduce la contraseña que quieres validar y ejecuta el comando. ![verify recovery lock](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/76305dbc-1864-4c33-8c95-9cfc75cfb520.png) El sistema devolverá un resultado claro indicando si la contraseña es **correcta** o **incorrecta**. :::warning Este proceso de verificación no modifica el estado actual del bloqueo de recuperación. ::: Esta capacidad ayuda a los equipos TI a validar contraseñas antes de realizar operaciones sensibles, evitar el acceso físico innecesario a los dispositivos y reducir los errores durante las tareas de soporte o mantenimiento. ### Eliminar el bloqueo de recuperación **Navega a los comandos del dispositivo y proporciona la contraseña actual** Desde la pestaña **Comandos** del dispositivo, haz clic en **\+ Nuevo comando** y selecciona **Establecer bloqueo de recuperación** de nuevo. Debes proporcionar la **contraseña del bloqueo de recuperación actualmente activa**. Si la contraseña es correcta, el lock se elimina correctamente. Si no se proporciona la contraseña correcta, el bloqueo de recuperación no puede eliminarse mediante MDM. :::warning Apple no almacena la contraseña del bloqueo de recuperación y el protocolo MDM no permite recuperarla una vez que se pierde. **Si se olvida o no está disponible la contraseña, la única opción de recuperación es contactar directamente con Apple**. Este proceso requiere el justificante de compra original del dispositivo y puede resultar en un borrado completo del dispositivo. ::: :::warning El uso del bloqueo de recuperación debe planificarse cuidadosamente, con procedimientos internos claros para el almacenamiento de contraseñas, el control de acceso y los escenarios de recuperación. ::: El bloqueo de recuperación es una potente función de seguridad para proteger los dispositivos macOS corporativos contra el acceso no autorizado a la recuperación. Con Applivery, los administradores pueden gestionar el bloqueo de recuperación de forma centralizada y remota usando los comandos Establecer bloqueo de recuperación y Verificar bloqueo de recuperación, sin implicación del usuario final. Sin embargo, dado que las contraseñas del bloqueo de recuperación no pueden recuperarse si se pierden, es esencial aplicar esta función con una estrategia bien definida que equilibre una seguridad sólida con la continuidad operativa y la capacidad de soporte. --- ## Desbloquear cuentas de usuario Source: https://docs.applivery.com/es/device-management/apple/macos/commands/unlock-user-accounts/ Description: Desbloquea remotamente cuentas de usuario macOS desactivadas por intentos de inicio de sesión fallidos usando los comandos MDM de Applivery para restaurar el acceso. TL;DR: Desbloquea cuentas de usuario macOS bloqueadas de forma remota usando Applivery para restaurar el acceso y mantener la seguridad. Answers: ¿Por qué mi cuenta macOS está bloqueada después de introducir la contraseña correcta? · ¿Cómo puedo desbloquear una cuenta de usuario macOS bloqueada? · ¿Puedo usar un comando o script para eliminar un bloqueo de cuenta macOS? · ¿Qué debo hacer si el comando "Desbloquear cuenta de usuario" en Applivery permanece pendiente? · ¿Qué ocurre si FileVault está activado en el dispositivo macOS bloqueado? · ¿Dónde encuentro el comando "Desbloquear cuenta de usuario" en Applivery? · ¿Cuánto tiempo tarda en completarse el comando "Desbloquear cuenta de usuario" en Applivery? · ¿Cuáles son las mejores prácticas para gestionar los bloqueos de cuentas macOS? Key topics: Bloqueo de cuenta de usuario macOS, Desbloqueo remoto con Applivery, Consideraciones de FileVault, Gestión de políticas de contraseñas, Resolución de problemas, macOS, Applivery, FileVault, MDM Gestionar los problemas de acceso de los usuarios es una parte esencial para mantener el buen funcionamiento y la seguridad en todos los dispositivos macOS corporativos. En ocasiones, una cuenta de usuario puede quedar bloqueada después de superar el número permitido de intentos fallidos de inicio de sesión — normalmente por las políticas de contraseñas aplicadas. Cuando esto ocurre, los usuarios pueden ver el mensaje "Tu cuenta se ha desactivado" después de esperar e introducir la contraseña correcta. :::warning Los usuarios no pueden intentar introducir la contraseña de nuevo hasta que el período de bloqueo haya expirado completamente. Si la siguiente contraseña introducida es incorrecta, la duración del bloqueo aumentará. **Este bloqueo no puede eliminarse usando ningún comando o script debido a las restricciones de seguridad de macOS**. Sin embargo, si el período de bloqueo termina y la siguiente contraseña introducida es correcta, el usuario seguirá recibiendo el mensaje "Tu cuenta se ha desactivado". ::: Para restaurar el acceso, puedes desbloquear de forma remota la cuenta de usuario afectada directamente desde el panel de Applivery. ### Cómo desbloquear una cuenta de usuario **Navega al dispositivo de destino** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io), dirígete a cualquiera de tus **Dispositivos** 1 y abre la pestaña **Comandos** 2. **Encuentra el dispositivo** Haz clic en **\+ Nuevo comando** 3 y selecciona **Desbloquear cuenta de usuario** 4 ![unlock user account](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/7ebcc2c9-ecf8-4daf-905d-4dab286e35d4.png) El estado del comando debería cambiar a **Hecho** en pocos minutos, después de lo cual puedes notificar al usuario para que intente iniciar sesión de nuevo. :::info Si el comando permanece **Pendiente** o no cambia, comprueba lo siguiente: - El Mac está conectado a una red Wi-Fi válida y gestionada. - El perfil MDM está correctamente instalado y tiene los permisos necesarios para la gestión de usuarios. ::: ### Casos especiales: dispositivos con FileVault activado Si FileVault está activo: - El comando de desbloqueo no funcionará hasta que el disco se desbloquee al iniciar sesión usando la contraseña del usuario o la clave de recuperación de FileVault. - Si el usuario no puede desbloquear el disco, la única solución es restablecer la contraseña mediante el [modo de recuperación usando la clave de recuperación de FileVault](https://docs.applivery.com/es/device-management/apple/macos/policies/reset-password/#restablecer-la-contraseña-de-mac-con-la-clave-de-recuperación-de-filevault). ### Recomendaciones Para mantener una gestión de cuentas eficiente y segura: - Revisa periódicamente las políticas de contraseñas y los umbrales de bloqueo aplicados mediante Applivery. - Comunica a los usuarios los tiempos de espera esperados y los procedimientos de desbloqueo para reducir la confusión. - Documenta cada solicitud de desbloqueo o acción de soporte para una trazabilidad adecuada. Manteniendo estas prácticas y una comunicación clara con los usuarios, puedes resolver los bloqueos de cuentas de forma rápida y proactiva, reforzando la seguridad y mejorando la experiencia del usuario en toda tu flota macOS. --- ## Políticas Source: https://docs.applivery.com/es/device-management/apple/macos/policies/ Description: Políticas macOS en Applivery — gestión centralizada, seguridad y cumplimiento para los dispositivos macOS de tu organización. TL;DR: Las políticas macOS de Applivery ofrecen un panel centralizado para gestionar los ajustes del sistema, la seguridad y el cumplimiento de dispositivos macOS a escala. Answers: ¿Qué son las políticas macOS en Applivery? · ¿Qué puedo gestionar con las políticas macOS de Applivery? · ¿Dónde se gestionan las políticas macOS en Applivery? · ¿Cuál es el beneficio de usar políticas macOS? · ¿Pueden las políticas macOS garantizar el cumplimiento? Key topics: Gestión de dispositivos macOS, Políticas de Applivery, Configuración de seguridad, Aplicación del cumplimiento, Gestión centralizada, Applivery, macOS Las políticas macOS en Applivery te permiten definir y aplicar configuraciones en todos tus ordenadores Mac gestionados. Desde las preferencias del sistema y las reglas de seguridad hasta FileVault, el firewall, scripts, certificados y perfiles PPPC personalizados — las políticas te dan un control profundo sobre cada Mac inscrito. Los ajustes de política para macOS están organizados por categoría, con instrucciones paso a paso para las configuraciones más comunes. --- ## Automatizar la creación de la cuenta de administrador Source: https://docs.applivery.com/es/device-management/apple/macos/policies/automate-admin-account/ Description: Automatiza la creación y gestión de cuentas de administrador locales en dispositivos macOS usando scripts y políticas de Applivery. TL;DR: Automatiza la creación y gestión de cuentas de administrador macOS usando scripts de Applivery para un aprovisionamiento de dispositivos ágil y una mayor seguridad. Answers: ¿Cómo puede Applivery automatizar la gestión de cuentas de usuario macOS? · ¿Qué parámetros se pueden configurar en el script de creación de usuarios macOS? · ¿Cómo oculto una cuenta de usuario macOS usando el script de Applivery? · ¿Qué ocurre si la cuenta de usuario ya existe cuando se ejecuta el script? · ¿Cómo asigno el script de creación de usuarios macOS a una política en Applivery? · ¿Cuáles son los métodos de ejecución del script de creación de usuarios macOS? · ¿Qué es la app agente de Applivery para macOS? · ¿Dónde puedo activar manualmente el script para crear un usuario? Key topics: Gestión macOS, Mobile Device Management, Scripting, Applivery, macOS Gestionar las cuentas de usuario en dispositivos macOS es una parte esencial de la administración de dispositivos empresariales. Con Applivery, los equipos TI pueden automatizar la creación de cuentas de administrador locales, actualizar credenciales y opcionalmente ocultar perfiles de usuario — garantizando una configuración consistente, una mayor seguridad y un esfuerzo manual reducido en toda la flota macOS. :::info La **app del agente de Applivery para macOS** debe estar activada en el dispositivo. Puedes obtener más información sobre ella [aquí](https://docs.applivery.com/es/device-management/apple/apple-policies/agent/). ::: **Crea tu script** Para empezar, aprende a crear scripts siguiendo [este enlace](https://docs.applivery.com/es/device-management/apple/macos/scripts/). Asigna un nombre descriptivo al script y copia y pega el siguiente script en el editor, luego ajusta los parámetros necesarios: - **USERNAME** (`username`): El nombre corto de la cuenta a crear. - **FULLNAME** (`Full Name`): El nombre completo de visualización del usuario. - **PASSWORD** (`password`): La contraseña que se asignará al usuario. - **HIDDEN** (`no`): Cambia a `yes` si quieres que la cuenta de usuario quede oculta en la ventana de inicio de sesión. ```typescript title="example.ts" #!/bin/sh export PATH=/usr/bin:/bin:/usr/sbin:/sbin ## User details USERNAME="username" FULLNAME="Full Name" PASSWORD="password" HIDDEN="no" # Change to "yes" if you want the user to be hidden ## Function to check if user exists check_user_exists() { dscl . -list /Users | grep -q "^$USERNAME$" return $? } ## Function to check if user is hidden is_user_hidden() { dscl . -read /Users/$USERNAME IsHidden 2>/dev/null | grep -q "1" return $? } ## Function to hide user hide_user() { sudo defaults write /Library/Preferences/com.apple.loginwindow HiddenUsersList -array-add $USERNAME sudo chown root:wheel /Library/Preferences/com.apple.loginwindow.plist } ## Function to unhide user unhide_user() { sudo defaults delete /Library/Preferences/com.apple.loginwindow HiddenUsersList } ## Function to update password update_password() { sudo dscl . -passwd /Users/$USERNAME "$PASSWORD" } ## Check if user exists if check_user_exists; then echo "Usuario $USERNAME ya existe." ## Update password automatically update_password echo "Contraseña actualizada para $USERNAME" ## Check and update hidden status if needed current_hidden=$(is_user_hidden && echo "yes" || echo "no") if [ "$current_hidden" != "$HIDDEN" ]; then if [ "$HIDDEN" = "yes" ]; then hide_user echo "Usuario $USERNAME ha sido ocultado" else unhide_user echo "Usuario $USERNAME ha sido des-ocultado" fi fi else ## Create new user if [ "$HIDDEN" = "yes" ]; then HIDDEN_FLAG="-hidden" else HIDDEN_FLAG="" fi ## Create the user with or without the hidden option sysadminctl -addUser "$USERNAME" -fullName "$FULLNAME" -password "$PASSWORD" -admin $HIDDEN_FLAG echo "Usuario $USERNAME creado exitosamente" fi ``` **Asignar script a la política** A continuación, dirígete a cualquiera de tus **Políticas** 1 y selecciona la sección **Scripts** 2 desde el menú lateral izquierdo. Haz clic en el botón **\+ Añadir Script** 3. ![add script to policy](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/e3750ae5-46fc-4673-87bf-47fe706a6c25.png) A continuación, selecciona el script escribiendo su nombre, elige el método de ejecución y añade los argumentos necesarios. Dependiendo del método de ejecución seleccionado, el script se ejecutará automáticamente en modo **Loop** o **Once**, o puede **activarse manualmente** desde la sección **Acciones** dentro del agente de Applivery cuando se configure como **On-demand**. ![actions self service](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/be26aa8c-99bd-4cfd-ae23-97c97e636757.png) Este método automatizado para crear usuarios administradores en macOS ayuda a estandarizar el aprovisionamiento de dispositivos y garantiza una postura de seguridad unificada en toda la organización. El script gestiona de forma inteligente tanto la creación de nuevas cuentas como la actualización de las existentes, lo que lo convierte en una herramienta flexible y potente para múltiples escenarios de despliegue. Aprovechando Applivery y la automatización mediante scripts, los equipos TI pueden gestionar cuentas de administrador de forma eficiente a escala, reducir la carga de trabajo repetitivo y mantener una configuración consistente en todos los dispositivos macOS gestionados. Ya sea para desplegar nuevo hardware o actualizar los despliegues actuales, este flujo de trabajo proporciona una forma fiable, segura y repetible de aprovisionar usuarios administradores en entornos macOS. --- ## Automatizar la creación de la cuenta de usuario estándar Source: https://docs.applivery.com/es/device-management/apple/macos/policies/automate-standard-user-account/ Description: Automatiza la creación de cuentas de usuario estándar (no administrador) en dispositivos macOS usando scripts y políticas de Applivery. TL;DR: Automatiza la creación de cuentas de usuario estándar macOS con scripts de Applivery para mejorar la seguridad y la eficiencia. Answers: ¿Por qué es importante crear cuentas de usuario estándar en dispositivos macOS? · ¿Cómo ayuda Applivery a gestionar cuentas de usuario estándar en macOS? · ¿Cuál es el primer paso para crear una cuenta de usuario estándar con Applivery? · ¿Qué parámetros deben definirse en el script de creación de usuario? · ¿Cómo asigno el script de creación de usuario a una política en Applivery? · ¿Qué métodos de ejecución están disponibles para los scripts en Applivery? · ¿Cuál es el beneficio de automatizar la creación de cuentas de usuario estándar? · ¿Se requiere la app agente de Applivery en el dispositivo macOS? Key topics: macOS, MDM, gestión de cuentas de usuario, scripting, automatización, Applivery, Administradores TI Gestionar las cuentas de usuario con los niveles de privilegios adecuados es esencial para mantener tanto la seguridad como la eficiencia operativa en entornos macOS corporativos. Los usuarios estándar (no administradores) ayudan a reducir los riesgos de seguridad evitando cambios no autorizados a nivel del sistema, mientras permiten a los empleados realizar tareas cotidianas sin restricciones. A través de Applivery, los equipos TI pueden automatizar la creación de estas cuentas estándar en todos los dispositivos macOS gestionados, garantizando la consistencia, reduciendo el trabajo manual y aplicando un sólido modelo de seguridad de mínimo privilegio. :::info La **app del agente de Applivery para macOS** debe estar activada en el dispositivo. Puedes obtener más información sobre ella [aquí](https://docs.applivery.com/es/device-management/apple/apple-policies/agent/). ::: **Crea tu script** Para empezar, aprende a crear scripts siguiendo este enlace Asigna un nombre descriptivo al script y copia y pega el siguiente script en el editor, luego ajusta los parámetros necesarios: - **USERNAME** (`username`): El nombre corto de la cuenta a crear. - **FULLNAME** (`Full Name`): El nombre completo de visualización del usuario. - **PASSWORD** (`password`): La contraseña que se asignará al usuario. ``` #!/bin/sh export PATH=/usr/bin:/bin:/usr/sbin:/sbin #User details USERNAME="User" FULLNAME="Full Name" PASSWORD="Password" ## Create the user with the specified username, full name and password sysadminctl -addUser "$USERNAME" -fullName "$FULLNAME" -password "$PASSWORD" ``` **Asignar script a la política** A continuación, dirígete a cualquiera de tus **Políticas** 1 y selecciona la sección **Scripts** 2 desde el menú lateral izquierdo. Haz clic en el botón **\+ Añadir Script** 3. ![add script to policy](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/91d154f5-98af-4536-bc1e-be612c2faad5.png) A continuación, selecciona el script escribiendo su nombre, elige el método de ejecución y añade los argumentos necesarios. Dependiendo del método de ejecución seleccionado, el script se ejecutará automáticamente en modo **Loop** o **Once**, o puede activarse manualmente desde la sección **Acciones** dentro del agente de Applivery cuando se configure como **On-demand**. ![actions agent](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/366dd41e-14ee-4560-87af-35cbf23fb91d.png) Crear usuarios estándar con privilegios limitados es una práctica de seguridad recomendada que ayuda a proteger los dispositivos macOS contra modificaciones no intencionadas o accesos no autorizados. Automatizar este proceso a través de Applivery garantiza una configuración consistente en toda la flota de dispositivos, apoya el cumplimiento de las políticas internas y minimiza la sobrecarga operativa. Aprovechando las capacidades de scripting de Applivery, los equipos TI pueden desplegar eficientemente cuentas de usuario estándar a escala, mantener la integridad del sistema y agilizar la incorporación y la gestión de dispositivos macOS. Este enfoque ofrece un método sencillo, fiable y repetible para aplicar el acceso de mínimo privilegio en toda tu organización. --- ## Bloquear o permitir URLs en Chrome y Safari Source: https://docs.applivery.com/es/device-management/apple/macos/policies/block-allow-urls-chrome-safari/ Description: Controla a qué sitios web pueden acceder tus usuarios en macOS. Safari y Chrome usan payloads distintos, y esta guía explica cómo desplegar ambos desde Applivery. TL;DR: Bloquea sitios web en los Mac con dos payloads independientes: URLBlocklist para Chrome y el filtro de contenido de Controles Parentales para Safari. No hace falta supervisión, y el usuario debe reiniciar el navegador después. Answers: ¿Puedo bloquear un sitio web en Chrome y Safari con un solo ajuste? · ¿Necesito supervisar un Mac para bloquear URLs? · ¿Por qué no funciona el bloqueo justo después de aplicar la política? · ¿Qué campos de Safari debo usar en el panel? · ¿Cómo bloqueo todo excepto una lista de sitios en Chrome? · ¿Bloquear un dominio en Chrome bloquea también sus subdominios? · ¿Cómo compruebo que una política de Chrome se ha aplicado? · ¿Bloquear un sitio web bloquea también la app de escritorio? Key topics: Políticas de URL de Chrome en macOS, Filtrado de contenido en Safari, Importación de configuración custom, Navegador frente a app nativa, Applivery, Apple, Google Chrome, Safari, macOS En macOS, Safari y Chrome no comparten mecanismo de gestión. Cada uno se controla con un payload distinto dentro del perfil de configuración, así que restringir el acceso web implica configurar los dos: no hay un único ajuste que cubra ambos. ### Antes de empezar - El Mac está inscrito en Applivery, mediante Apple MDM, Automated Device Enrollment o inscripción manual. **Ninguno de los dos payloads requiere supervisión.** - Ambos payloads se pueden importar como configuración custom: ve a **Policies**, selecciona tu política de macOS y entra en **\+ Add configuration → + Import**. Ahí puedes pegar el XML o subirlo con **Load XML**. - Para Safari hay una vía mejor: Applivery expone el payload como configuración nativa en **\+ Add configuration → Parental Controls: Content Filter**. - Puedes combinar ambos payloads en un mismo `.mobileconfig` bajo el mismo `PayloadContent`, o importarlos como configuraciones independientes dentro de la misma política. :::warning **El usuario tiene que reiniciar el navegador.** Hasta que no se relanza, sigue funcionando con la configuración que leyó al arrancar, así que la restricción parece no haberse aplicado. Es lo primero que hay que comprobar antes de investigar nada más. ::: ### Google Chrome Chrome en macOS se gestiona mediante managed preferences inyectadas en el dominio `com.google.Chrome`, usando sus políticas nativas `URLBlocklist` y `URLAllowlist`. Dirígete a tus **Políticas** 1, selecciona tu política de macOS, entra en **\+ Añadir configuración → + importar** 2 y pega o sube el XML. ![import](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/9c208869-9433-463e-8af8-7f14b056b603.png) #### Bloquear dominios concretos ```xml PayloadContent PayloadType com.google.Chrome PayloadUUID 7D9A8B87-7A4F-4B9E-9C75-111111111111 PayloadDisplayName Google Chrome - URL Blocklist PayloadIdentifier com.google.Chrome.7D9A8B87-7A4F-4B9E-9C75-111111111111 PayloadVersion 1 URLBlocklist website1.com website2.com PayloadDisplayName Chrome URL Policy macOS PayloadIdentifier com.applivery.profile.f537cccc-6b42-4a4d-a432-9ef86ae7366a PayloadType Configuration PayloadUUID 8c99db2f-eb79-4b1a-9099-827422b47588 PayloadVersion 1 ``` #### Permitir solo una lista de sitios Bloquea todos los hosts con un único asterisco y después lista las excepciones: ```xml URLBlocklist * URLAllowlist mail.google.com applivery.com ``` #### Formato de los filtros Las entradas siguen el patrón `[scheme://][.]host[:port][/path][@query]`.

Entrada

Con qué coincide

website1.com

El dominio y todos sus subdominios. No necesitas una entrada *.website1.com aparte.

.www.ejemplo.com

Solo ese host exacto. Los demás subdominios siguen accesibles.

*

Todos los hosts. Es un valor especial por sí solo, no un comodín que puedas meter dentro de un nombre de host.

Dos límites que conviene conocer: - **El asterisco no es un comodín general.** `*.website1.com` no sirve para cubrir subdominios — un `website1.com` a secas ya lo hace. Tampoco se admite al final de una ruta, así que `https://ejemplo.com/*` no es una entrada válida. - **Puedes listar hasta 1.000 entradas.** :::info **Cuando las dos listas chocan, gana el filtro más específico.** Chrome selecciona los filtros con la coincidencia de host más larga, después los de ruta más larga y después los que tengan más tokens de consulta. Si un filtro de bloqueo y uno de permiso son igual de específicos, **gana el de permiso**. ::: #### Comprobar que se ha aplicado En el Mac, abre `chrome://policy` y confirma que `URLBlocklist` o `URLAllowlist` aparecen con **Source: Platform** y el valor que esperas. Si no están, el perfil no ha llegado; si están pero la navegación sigue funcionando, el navegador no se ha reiniciado. Una vez funcionando, al visitar un sitio de la lista Chrome muestra su página de sitio bloqueado. ### Safari Safari en macOS **no** usa el payload `WebContentFilter` de iOS e iPadOS: ese requiere supervisión y es exclusivo de iOS. En macOS el equivalente es el payload de Controles Parentales, `com.apple.familycontrols.contentfilter`. Puedes importarlo como XML custom, pero el formulario nativo es la mejor vía. Abajo están las dos. #### Usar el formulario nativo Applivery expone este payload como configuración nativa, con los campos traducidos y validados en el panel. **Abrir tu política de macOS** Dirígete a tus **Políticas** 3 y selecciona la política de macOS que quieras modificar. **Añadir la configuración** En el menú lateral izquierdo, haz clic en **\+ Añadir configuración**, busca **control parental**, selecciona **Control parental: Filtro de contenidos** 4 y pulsa **\+ Añadir**. ![parental control](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/934a5330-e5ae-40d5-b409-43c82303bcf0.png) :::warning **Usa los campos marcados como deprecados.** El formulario recomienda los nuevos _Denylist_ y _Allowlist_, y a fecha de hoy **hay que ignorar esa recomendación**: las claves nuevas no aplican el bloqueo de forma fiable en macOS, y las deprecadas sí. Utiliza **Filtrar lista negra** y **Filtrar lista blanca**. Apple las deprecó en macOS 15.2, pero siguen funcionando — incluido en macOS 26 Tahoe. ::: ##### Los interruptores maestros **Restringir Web** debe estar en **ON** para que se aplique cualquier filtrado. Con él desactivado, nada más de la configuración tiene efecto. Lo mismo ocurre con **Utilizar filtro de contenidos**, que activa el filtrado automático de contenido de Apple. ##### Dos modos, mutuamente excluyentes El formulario respeta la misma lógica del payload: solo se usa un modo a la vez. **Bloqueo selectivo** — bloquea sitios concretos y el resto queda accesible: - **Filtrar lista negra**: los sitios a bloquear, uno por elemento con **\+ Add element**. - **Filtrar lista blanca**: excepciones dentro de ese bloqueo. Útil sobre todo cuando **Use Content Filter** está activo y el filtro automático de contenido adulto está bloqueando un sitio que no debería. - **Lista blanca activada** debe permanecer en **OFF**. Si lo activas, pasas al otro modo y la blacklist deja de aplicarse. **Permitir solo los sitios listados** — bloquea todo excepto una lista: - **Lista blanca activada**: ON. - **Lista blanca de sitios**: el único campo con efecto en este modo, y obligatorio una vez Lista blanca activada está activo. - **Filtrar lista negra** se ignora mientras este modo esté activo. No hace falta vaciarlo.

Objetivo

Restringir Web

Lista blanca activada

Campo a rellenar

Bloquear sitios concretos, permitir el resto

ON

OFF

Filtrar lista negra

Permitir solo ciertos sitios, bloquear el resto

ON

ON

Lista blanca de sitios

#### Usar XML custom Si prefieres importar el payload directamente, así se bloquean sitios concretos: ```xml PayloadContent PayloadType com.apple.familycontrols.contentfilter PayloadUUID A2B3C4D5-6E7F-4A1B-9C2D-222222222222 PayloadDisplayName Safari - Content Filter PayloadIdentifier com.applivery.safari.A2B3C4D5-6E7F-4A1B-9C2D-222222222222 PayloadVersion 1 restrictWeb useContentFilter filterBlacklist https://www.website1.com https://www.website2.com https://website3.com PayloadDisplayName Safari URL Policy macOS PayloadIdentifier com.applivery.profile.b6d1e2f3-4a5b-4c6d-8e9f-0a1b2c3d4e5f PayloadType Configuration PayloadUUID b6d1e2f3-4a5b-4c6d-8e9f-0a1b2c3d4e5f PayloadVersion 1 ``` Y así se permiten únicamente los sitios listados: ```xml restrictWeb whitelistEnabled siteWhitelist https://mail.google.com https://applivery.com ``` :::info `whitelistEnabled` y `useContentFilter` son mutuamente excluyentes. Usa uno u otro, nunca los dos en el mismo payload. ::: #### Formato de las URLs en Safari - **Las URLs deben empezar por** `http://` **o** `https://`**.** Si el sitio responde en ambos, añade una entrada para cada uno. - **La coincidencia es por raíz de cadena.** Bloquear `https://www.website1.com` bloquea también `www.website1.com/example` y cualquier ruta por debajo, pero **no** cubre automáticamente otros subdominios como `example.website1.com`. Añádelos como entradas independientes si los necesitas. - **Para blindar un dominio por completo, incluye las cuatro variantes:** ``` https://www.website1.com https://website1.com http://www.website1.com http://website1.com ``` - **Las redirecciones no se siguen.** Si una URL bloqueada o permitida redirige a otra, el destino tiene que estar también en la lista. - **El filtro deshabilita además borrar el historial y los datos de navegación de Safari, y desactiva la navegación privada.** :::info **Si tras relanzar Safari sigue sin bloquear, reinicia el Mac.** Es un comportamiento conocido en macOS Sonoma y Sequoia: los cambios de Content Filtering no se aplican de forma fiable hasta que el dispositivo se reinicia. Prueba primero a reiniciar el navegador y recurre al reinicio del equipo antes de dar por malo el payload. ::: ### Bloquear el sitio web no es bloquear la herramienta Bloquear un dominio en Chrome o Safari solo impide el acceso **vía navegador**. Muchas herramientas tienen una **app nativa de escritorio** que habla directamente con sus servidores, sin pasar por ningún navegador, y que por tanto no se ve afectada por `URLBlocklist` ni por `filterBlacklist`. Si el objetivo es impedir el uso de un servicio y no solo el acceso a su web, combina esta configuración con el control de aplicaciones. Tienes dos opciones: - **Impedir que la app se instale**, mediante la lista de apps permitidas o bloqueadas de la política de macOS — consulta [Bloquear y permitir apps](https://docs.applivery.com/es/device-management/apple/app-management/block-allow-apps/). - **Impedir que se ejecute un binario ya instalado**, mediante el payload `com.apple.applicationaccess.new` y su clave `pathBlackList`. ### Resumen de payloads

Navegador

PayloadType

Claves de bloqueo

Claves de permitido

Supervisión

Google Chrome

com.google.Chrome

URLBlocklist

URLAllowlist

No requerida

Safari

com.apple.familycontrols.contentfilter

filterBlacklist

filterWhitelist / siteWhitelist

No requerida

:::info Apple introdujo claves renombradas en **macOS 15.2** — `filterDenyList`, `filterAllowList`, `siteAllowList` y `allowListEnabled` — y deprecó las originales al mismo tiempo. La tabla anterior usa deliberadamente los nombres deprecados, porque son los que a día de hoy bloquean de forma fiable. ::: ### Antes de desplegarlo Despliega primero en un Mac y confirma dos cosas: que la política ha llegado, usando `chrome://policy` en el caso de Chrome, y que el navegador se ha reiniciado. La mayoría de los "el bloqueo no funciona" se explican por una de esas dos, no por el payload. --- ## Bloquear USB y unidades externas Source: https://docs.applivery.com/es/device-management/apple/macos/policies/block-usb-external-drives/ Description: Bloquea las unidades USB y los dispositivos de almacenamiento externo en macOS usando perfiles MDM de Applivery para evitar la fuga de datos y mejorar la seguridad. TL;DR: Bloquea las unidades USB y el almacenamiento externo en macOS usando perfiles de configuración MDM para mejorar la seguridad de los datos y evitar la transferencia de datos no autorizada. Answers: ¿Cómo puedo bloquear las unidades USB en macOS? · ¿Qué tipos de almacenamiento externo se pueden restringir en macOS? · ¿Qué es "logout eject" en la gestión de medios de macOS? · ¿Qué son los "mount controls" en la gestión de medios de macOS? · ¿Qué hace la acción "Deny" en la gestión de medios de macOS? · ¿Qué hace la acción "Read-only" en la gestión de medios de macOS? · ¿Qué ocurre cuando se elimina un perfil de gestión de medios de macOS? · ¿Qué es la acción "Authenticate" para la gestión de medios en macOS? Key topics: Control de medios macOS, Perfiles de configuración MDM, Bloqueo de unidades USB, Prevención de pérdida de datos, Applivery, macOS, Unidades USB, SystemUIServer, mobileconfig En entornos corporativos, el uso de dispositivos de almacenamiento externo como unidades USB, discos duros externos, CDs o DVDs representa un riesgo significativo para la seguridad de la información y el cumplimiento normativo. macOS proporciona mecanismos nativos para restringir estos dispositivos a través de perfiles de configuración, permitiendo a las organizaciones aplicar políticas estrictas de control de medios sin instalar agentes adicionales ni depender de scripts de monitoreo. Este enfoque se basa en un perfil de configuración `.mobileconfig` que aplica restricciones al comportamiento del sistema macOS — específicamente a través del componente **SystemUIServer** — controlando cómo el sistema operativo reacciona cuando se conecta un medio de almacenamiento externo. Cuando se aplica, el perfil puede detectar la inserción de medios externos, evitar que se monten, expulsarlos automáticamente y mostrar una notificación del sistema informando al usuario de que el dispositivo está bloqueado. Otros periféricos, como teclados, ratones o cables de carga, no se ven afectados, siempre que macOS no los reconozca como dispositivos de almacenamiento. ### Tipos de medios bloqueados Con esta configuración, macOS puede restringir múltiples tipos de almacenamiento extraíble, incluyendo discos duros USB externos, memorias USB, CDs y DVDs, medios ópticos y otros dispositivos de almacenamiento masivo reconocidos por el sistema. Cuando se conecta uno de estos dispositivos, macOS lo expulsa automáticamente y evita que se monte, haciéndolo inaccesible para el usuario. ### Configuración Una vez en el [**panel de Applivery**](https://dashboard.applivery.io), dirígete a cualquiera de tus **Políticas** o [crea una nueva](https://docs.applivery.com/es/device-management/general-settings/create-policies/). En el menú lateral izquierdo, navega a la opción **\+ Añadir configuración** y elige **Gestión de medios: Medios permitidos**. ![media management allowed media](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/913878c7-e1a2-451a-a712-8e187f47546b.png) Este payload está estructurado en tres secciones distintas, cada una aplicada en un momento diferente del ciclo de vida del dispositivo y con un propósito de seguridad específico. #### Logout eject: control del dispositivo al cerrar sesión Esta sección **define qué dispositivos de almacenamiento se expulsan automáticamente cuando un usuario cierra sesión** en macOS. No bloquea el uso del dispositivo durante una sesión activa, pero garantiza que no quede ningún almacenamiento externo montado una vez que termina la sesión del usuario. Esto es especialmente útil en dispositivos compartidos, evitando que las unidades externas sean accedidas por usuarios posteriores y reforzando la seguridad sin afectar los flujos de trabajo cotidianos. #### Mount controls: control del montaje del dispositivo Esta es la sección más crítica del payload, ya que **determina si un dispositivo de almacenamiento puede montarse cuando se conecta**. macOS evalúa estas reglas inmediatamente al insertar el dispositivo. Los administradores pueden bloquear completamente el acceso, permitir el acceso de solo lectura o permitir el uso completo según los requisitos de la organización. Los controles de montaje se usan habitualmente para bloquear las unidades USB para evitar la exfiltración de datos, permitir los medios ópticos en modo de solo lectura o controlar estrictamente los dispositivos de almacenamiento no corporativos. Si un tipo de dispositivo está bloqueado aquí, no puede usarse bajo ninguna circunstancia, independientemente de cualquier otra sección de configuración. #### Unmount controls: control de la expulsión manual del dispositivo Esta sección regula **si un usuario puede expulsar manualmente un dispositivo que ya está montado**. No afecta la conexión inicial ni el montaje del dispositivo. Los casos de uso típicos incluyen evitar la desconexión accidental de unidades de red críticas o proteger entornos corporativos específicos donde la expulsión manual podría causar problemas operativos. #### Resumen funcional | Sección | Se aplica cuando | Función principal | | --- | --- | --- | | Logout eject | Cierre de sesión del usuario | Expulsión automática del dispositivo | | Mount controls | Conexión del dispositivo | Permitir o bloquear el montaje | | Unmount controls | Expulsión manual | Permitir o bloquear la desmontaje del dispositivo | ### Acciones disponibles Dentro de las secciones de logout eject, mount controls y unmount controls, los administradores pueden definir cómo reacciona macOS a cada tipo de medio: - La acción **Authenticate** permite el uso del dispositivo solo después de que el usuario se autentique correctamente con sus credenciales macOS. Esta opción es adecuada cuando el acceso debe restringirse a usuarios autorizados sin bloquear completamente el dispositivo. - La acción **Read-only** permite el acceso a los archivos mientras evita que se escriban datos en el dispositivo. Los usuarios pueden ver y copiar archivos del dispositivo al Mac, pero no pueden modificar archivos ni copiar datos corporativos al almacenamiento externo, lo que hace que esta opción sea ideal para evitar la fuga de datos. - La acción **Deny** bloquea completamente el dispositivo, evitando que se monte o acceda de cualquier manera. En este caso, el dispositivo puede aparecer brevemente y luego desaparecer, o no aparecer en absoluto. Si un tipo de medio está configurado como Deny en mount controls, ninguna otra configuración anulará este comportamiento. - La acción **Eject** permite el uso normal durante la sesión activa pero expulsa automáticamente el dispositivo cuando se produce el evento configurado, como el cierre de sesión del usuario. Esta opción se usa habitualmente en Macs compartidos para garantizar que los dispositivos externos no queden montados. | Acción | Acceso permitido | Escritura permitida | Auth requerida | Uso típico | | --- | --- | --- | --- | --- | | Authenticate | ✅ | ✅ | ✅ | Control basado en usuario | | Read-only | ✅ | ❌ | ❌ | Evitar la exfiltración de datos | | Deny | ❌ | ❌ | ❌ | Bloqueo total | | Eject | ✅ (temporal) | ✅ | ❌ | Limpieza al cerrar sesión | ### Recomendación general En la mayoría de los entornos corporativos gestionados con Applivery, las políticas de control de medios suelen basarse en los **mount controls** como mecanismo de aplicación principal, complementado por el **logout eject** como salvaguarda adicional. Los **unmount controls** generalmente se reservan para escenarios muy específicos. Combinar estas secciones de forma apropiada permite a las organizaciones implementar controles de seguridad sólidos sin impactar innecesariamente en la productividad de los usuarios. ### Comportamiento al eliminar la restricción Si el perfil de configuración se elimina del dispositivo, **se requiere reiniciar el sistema** para que se levanten completamente todas las restricciones. Hasta que se produzca el reinicio, macOS puede seguir aplicando el bloqueo de medios. Este comportamiento es inherente al sistema operativo y debe tenerse en cuenta durante la resolución de problemas o los cambios de política. :::tip Recuerda reiniciar el dispositivo macOS después de eliminar el perfil de configuración para levantar completamente las restricciones. ::: Al distribuir perfiles de configuración a través de Applivery, las organizaciones pueden bloquear de forma nativa y eficaz los dispositivos de almacenamiento externo en macOS de manera centralizada, escalable y no intrusiva. Este enfoque mejora la seguridad de los datos, se integra perfectamente con macOS y proporciona a los equipos TI un control preciso sobre el uso de medios extraíbles, manteniendo a la vez una experiencia de usuario equilibrada. --- ## Desplegar Check Point Source: https://docs.applivery.com/es/device-management/apple/macos/policies/deploy-checkpoint/ Description: Automatiza la instalación y configuración de Check Point Endpoint Security en dispositivos macOS usando un script de Applivery. TL;DR: Automatiza la instalación de Check Point Endpoint Security en macOS usando un script para un despliegue más rápido, fiable y consistente. Answers: ¿Qué hace el script de despliegue de Check Point Endpoint Security? · ¿Cuál es el propósito principal del script? · ¿Qué datos de configuración se integran en el script? · ¿Cómo garantiza el script despliegues consistentes? · ¿Qué utilidades valida el script antes de la ejecución? · ¿Cómo se almacenan los datos de configuración dentro del script? · ¿Cómo descarga el script el instalador de Check Point? · ¿Qué ocurre después de instalar el cliente de Check Point? Key topics: Seguridad de endpoints, Automatización macOS, Scripting, Check Point Endpoint Security, macOS Desplegar software de seguridad en una flota de dispositivos macOS puede ser lento y propenso a errores cuando se hace manualmente. Para abordar esto, hemos creado un script que automatiza la instalación y configuración inicial del cliente de **Check Point Endpoint Security** para macOS. Este enfoque garantiza un despliegue más rápido y fiable mientras mantiene la consistencia en la configuración de cada dispositivo. Al integrar ajustes esenciales — como direcciones de servidor, certificados y configuraciones de política — el script permite que cada Mac se conecte de forma segura a tu infraestructura de gestión de Check Point inmediatamente después de la instalación. ### Propósito Este script está diseñado para agilizar el despliegue del cliente de **Check Point Endpoint Security** en dispositivos macOS automatizando tanto la instalación como la configuración inicial. Su objetivo es: - **Automatizar el despliegue**: Eliminar los pasos manuales automatizando la distribución e instalación del cliente de seguridad en múltiples Macs, reduciendo la probabilidad de errores del usuario y ahorrando valiosos recursos TI. - **Habilitar la preconfiguración**: Integrar todos los datos de configuración necesarios — incluyendo certificados, direcciones de servidor y ajustes de política — para que el cliente esté inmediatamente listo para conectarse a tu infraestructura de gestión de Check Point después de la instalación. - **Garantizar la consistencia**: Garantizar que cada endpoint recibe la misma configuración y políticas de seguridad, mejorando la uniformidad y el cumplimiento en toda la organización. ### Flujo de trabajo general El script sigue un flujo de trabajo estructurado para garantizar un despliegue fiable y consistente: **Preparación** Las utilidades clave del sistema como `base64`, `curl` y `unzip` se definen y validan al inicio del script para garantizar la compatibilidad y evitar errores de ejecución. **Integración de datos de configuración** El script contiene un gran bloque de información de configuración codificada en formato Base64, típicamente exportada desde el Portal de gestión de Check Point. Este bloque incluye elementos necesarios como certificados, URLs de servidor y ajustes de política. **Decodificación y aplicación de la configuración** La configuración codificada en Base64 se decodifica y guarda en una ubicación temporal o predefinida donde el cliente de Check Point espera encontrar sus archivos de configuración. **Descarga del instalador** Usando `curl` o una utilidad similar, el script recupera el instalador de Check Point Endpoint Security — normalmente empaquetado como un archivo ZIP — desde un repositorio interno o externo de confianza. **Proceso de instalación** El instalador descargado se extrae y la instalación se ejecuta usando herramientas nativas de macOS, como el comando de línea `installer` o lanzando el `.app` incluido. Puede requerirse privilegios de administrador. **Limpieza y validación post-instalación** Después de la instalación, el script elimina los archivos temporales y opcionalmente realiza un paso de validación, como comprobar la presencia de la aplicación instalada o verificar su estado operativo. ``` #!/bin/sh -x set -e BASE64=/usr/bin/base64 UNZIP=/usr/bin/unzip CURL=/usr/bin/curl INSTALLER=/usr/sbin/installer ECHO=/bin/echo RM=/bin/rm PKGUTIL=/usr/sbin/pkgutil CONFIG_DAT_B64=PERBX0NPTkZJRz48QUxMT1dfTk9OX1RSVVNURURfQ0E+MTwvQUxMT1dfTk9OX1RSVVNURURfQ0E+PEFMTE9XX0lOVkFMSURfQ0VSVF9EQVRFPjE8L0FMTE9XX0lOVkFMSURfQ0VSVF9EQVRFPjxBTExPV19JTlZBTElEX1NJVEVfTkFNRT4xPC9BTExPV19JTlZBTElEX1NJVEVfTkFNRT48Q0hFQ0tfRk9SX1JFVk9DQVRJT04+MDwvQ0hFQ0tfRk9SX1JFVk9DQVRJT04+PFZEU19MT0NBVElPTj48L1ZEU19MT0NBVElPTj48SEVBREVSP1gtQ1BFUFA6dllvaWdkR0Zubm9RYzc8L0hFQURFUj4... MANIFEST_B64=PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0idXRmLTgiPz4... URL="https://ep-client-installers-prd-public.s3.amazonaws.com/eps-clients/mac/88.40.5927/EPS_E88.40_ONLY_DA.zip" CURL_SWITCH= CURL_SWITCH="$CURL_SWITCH --connect-timeout 10 -f" ## [... resto del script ...] set +e $PKGUTIL --pkg-info com.checkpoint.pkg.eps.core if [ $? -eq 0 ]; then echo "Endpoint Security for macOS already deployed (core receipt exists)" exit 0 fi set -e EPS_ZIP=EPS_ONLY_DA.zip TMP_DIR="$(mktemp -d /tmp/endpoint_security_installer.XXXXXX)" cd $TMP_DIR echo $CONFIG_DAT_B64 | $BASE64 --decode -o .config_dat echo $MANIFEST_B64 | $BASE64 --decode -o .InstallationManifest.plist $CURL $CURL_SWITCH $URL -o $EPS_ZIP >/dev/null 2>&1 $UNZIP $EPS_ZIP PKG_DIR="$TMP_DIR/Endpoint Security Installer.app/Contents/Resources/Configurations" cd "$PKG_DIR" PKG_NAME="$(ls "$PKG_DIR" | grep *.pkg)" PKG_PATH="$PKG_DIR/$PKG_NAME" $INSTALLER -pkg "$PKG_PATH" -target / exit 0 ``` --- ## Configuración del Dock Source: https://docs.applivery.com/es/device-management/apple/macos/policies/dock-configuration/ Description: Personaliza el Dock de macOS usando las políticas de gestión de dispositivos de Applivery — añade apps persistentes, apps estáticas y controla el diseño. TL;DR: Personaliza el Dock de macOS en dispositivos macOS con Applivery añadiendo apps persistentes o estáticas. Answers: ¿Qué versión de macOS se requiere para configurar el Dock con Applivery? · ¿Necesito la supervisión del dispositivo para configurar el Dock? · ¿Cómo añado una aplicación al Dock usando Applivery? · ¿Cuál es la diferencia entre apps persistentes y apps estáticas en el Dock? · ¿Qué es "Tile Data" al configurar elementos del Dock? · ¿Cómo añado una carpeta al Dock usando Applivery? · ¿Cómo añado una URL de sitio web al Dock? · ¿Dónde puedo configurar la posición y el tamaño del Dock? Key topics: Configuración del Dock macOS, Gestión de dispositivos Applivery, Gestión de aplicaciones, Applivery, Dock de macOS El Dock es la barra de inicio de aplicaciones que aparece en la parte inferior (o lados) de la pantalla macOS de forma predeterminada. A través de Applivery, puedes configurar y bloquear el Dock en toda tu flota de Macs gestionados — controlando qué apps aparecen, dónde está posicionado el Dock, cómo se comporta y si los usuarios pueden modificarlo en absoluto. Esto es especialmente útil para estandarizar el entorno del usuario en Macs compartidos o corporativos, garantizando que las herramientas organizativas clave siempre sean visibles y accesibles. ### Requisitos - **macOS:** 10.12 o posterior (la mayoría de los ajustes). Algunas claves requieren versiones más recientes — se indica donde corresponda. - **Supervisión:** No requerida para los payloads de configuración del Dock. - **Tipo de inscripción:** Se aplica a los perfiles de inscripción a nivel de dispositivo y canal de usuario. ### Configuración del Dock **Cómo configurar el Dock** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io), dirígete a cualquiera de tus **Políticas** o [crea una nueva](https://docs.applivery.com/es/device-management/general-settings/create-policies/). En el menú lateral izquierdo, navega a la opción **\+ Añadir configuración** y luego elige **Dock**. ![dock](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/283d5467-2cb4-4688-8e5f-228593913041.png) **Diseño del Dock: Añadir apps, carpetas y archivos** La configuración del Dock te permite definir qué elementos aparecen en el Dock y en qué orden. Los elementos se organizan en dos secciones principales — **Apps** (lado izquierdo del divisor) y **otros** (lado derecho del divisor, para carpetas y archivos) — y cada tipo de elemento requiere una configuración diferente. **Apps persistentes vs. Apps estáticas** Al añadir aplicaciones al Dock, debes elegir uno de dos modos para cada app: | Modo | Clave | Comportamiento | | --- | --- | --- | | **Apps persistentes** | `persistent-Apps` | La app aparece en el Dock, pero los usuarios pueden eliminarla arrastrándola fuera. | | **Apps estáticas** | `static-Apps` | La app está fijada permanentemente al Dock. Los usuarios no pueden eliminarla. | :::tip Usa `static-apps` para herramientas organizativas obligatorias (por ejemplo, tu cliente VPN, sistema de tickets o portal corporativo). Usa `persistent-apps` para apps recomendadas donde se acepta cierta flexibilidad del usuario. ::: Igualmente, para elementos que no son aplicaciones (Carpetas, Archivos, URLs): | Modo | Clave | Comportamiento | | --- | --- | --- | | **Otros persistentes** | `persistent-others` | Carpetas y archivos que el usuario puede eliminar. | | **Otros estáticos** | `static-others` | Carpetas y archivos fijados permanentemente en el Dock. | **Tile Data: Definir cada elemento del Dock** Cada elemento añadido al Dock — ya sea una App, Carpeta o Archivo — requiere un diccionario **Tile Data** que le dice a macOS cómo identificarlo y renderizarlo. Las claves requeridas varían según el tipo de tile. **Tiles de aplicación (tile-type: application-tile)** | Clave | Tipo | Descripción | | --- | --- | --- | | `file-data` | Diccionario | Contiene la clave `_CFURLString` con la ruta completa a la aplicación. | | `_CFURLString` | Cadena | Ruta absoluta al paquete `.app`. Ejemplo: `/Applications/Safari.app` | | `_CFURLStringType` | Entero | Siempre `0` para rutas de archivos locales. | | `tile-type` | Cadena | Debe ser `application-tile`. | | `label` | Cadena | Opcional. Nombre de visualización bajo el icono. Si se omite, se usa el nombre predeterminado de la app. | **Ejemplo: Añadir Safari** ```xml tile-data file-data _CFURLString /Applications/Safari.app _CFURLStringType 0 label Safari tile-type application-tile ``` **Tiles de carpeta (tile-type: directory-tile)** Se usa para añadir carpetas (como la carpeta de Descargas o un volumen de red compartido) al lado derecho del Dock. | Clave | Tipo | Descripción | | --- | --- | --- | | `file-data` | Diccionario | Contiene `_CFURLString` con la ruta completa a la carpeta. | | `_CFURLString` | Cadena | Ruta absoluta a la carpeta. Ejemplo: `~/Downloads` o `/Users/Shared` | | `_CFURLStringType` | Entero | `0` para rutas locales. | | `tile-type` | Cadena | Debe ser `directory-tile`. | | `displayas` | Entero | Cómo se muestra la carpeta: `0` = Stack, `1` = Folder. | | `showas` | Entero | Cómo se revelan los contenidos: `0` = Automático, `1` = Abanico, `2` = Cuadrícula, `3` = Lista. | | `arrangement` | Entero | Orden de clasificación del contenido: `1` = Nombre, `2` = Fecha añadida, `3` = Fecha modificada, `4` = Fecha creada, `5` = Tipo. | | `label` | Cadena | Etiqueta de visualización opcional. | **Ejemplo: añadir la carpeta Descargas como stack en cuadrícula** ```xml tile-data file-data _CFURLString /Users/username/Downloads _CFURLStringType 0 label Downloads displayas 0 showas 2 arrangement 2 tile-type directory-tile ``` **Tiles de URL (tile-type: url-tile)** Añade una URL web directamente al Dock. Al hacer clic se abre la URL en el navegador predeterminado. | Clave | Tipo | Descripción | | --- | --- | --- | | `url` | Cadena | La URL a abrir. Ejemplo: `https://intranet.empresa.com` | | `label` | Cadena | Nombre de visualización bajo el icono. | | `tile-type` | Cadena | Debe ser `url-tile`. | **Ajustes de apariencia y comportamiento del Dock** Más allá de los elementos del Dock, la configuración admite un conjunto completo de ajustes de apariencia y comportamiento. #### Posición y tamaño | Clave | Tipo | Valores / Descripción | | --- | --- | --- | | `orientation` | Cadena | Posición del Dock en pantalla: `bottom` (predeterminado), `left`, `right`. | | `tilesize` | Entero | Tamaño de los iconos del Dock en puntos. Rango: `16`–`128`. Predeterminado: `64`. | | `magnification` | Booleano | Si es `true`, los iconos se amplían al pasar el cursor. | | `largesize` | Entero | Tamaño máximo del icono cuando la ampliación está activada. Rango: `16`–`128`. | #### Ocultación automática y mostrado | Clave | Tipo | Descripción | | --- | --- | --- | | `autohide` | Booleano | Si es `true`, el Dock se oculta automáticamente cuando no está en uso y reaparece al pasar el cursor. | | `autohide-delay` | Real | Retraso en segundos antes de que el Dock se oculte (predeterminado: `0.5`). | | `autohide-time-modifier` | Real | Multiplicador de duración para la animación de ocultación/mostrado. | #### Animaciones y efectos visuales | Clave | Tipo | Descripción | | --- | --- | --- | | `launchanim` | Booleano | Si es `true`, las apps se animan (rebotan) al abrirse desde el Dock. | | `mineffect` | Cadena | Estilo de animación al minimizar ventanas: `genie` (predeterminado) o `scale`. | | `show-recents` | Booleano | Si es `false`, la sección "Aplicaciones recientes" se oculta del Dock. Requiere macOS 10.14+. | #### Gestión de ventanas y apps | Clave | Tipo | Descripción | | --- | --- | --- | | `expose-group-Apps` | Booleano | Si es `true`, Mission Control agrupa las ventanas por aplicación. | | `mru-spaces` | Booleano | Si es `false`, los Espacios no se reordenan automáticamente según el uso reciente. Útil para mantener una distribución de espacios fija. | | `show-process-indicators` | Booleano | Si es `true` (predeterminado), aparece un punto bajo los iconos de las aplicaciones en ejecución. Ponlo en `false` para ocultar estos indicadores. | **Bloquear el Dock para evitar cambios del usuario** La configuración del Dock incluye varias claves de bloqueo que evitan que los usuarios modifiquen la configuración del Dock establecida por MDM. | Clave | Tipo | Descripción | | --- | --- | --- | | `contents-immutable` | Booleano | Si es `true`, los usuarios no pueden añadir, eliminar ni reorganizar elementos en el Dock. El Dock queda completamente bloqueado. | | `size-immutable` | Booleano | Si es `true`, los usuarios no pueden cambiar el tamaño del Dock. | | `position-immutable` | Booleano | Si es `true`, los usuarios no pueden cambiar la posición del Dock en pantalla. | | `autohide-immutable` | Booleano | Si es `true`, los usuarios no pueden activar/desactivar la ocultación automática. | | `magnify-immutable` | Booleano | Si es `true`, los usuarios no pueden activar/desactivar la ampliación. | | `magsize-immutable` | Booleano | Si es `true`, los usuarios no pueden cambiar el tamaño de la ampliación. | | `mineffect-immutable` | Booleano | Si es `true`, los usuarios no pueden cambiar el estilo de la animación al minimizar. | :::tip Establecer `contents-immutable` en `true` es el enfoque más habitual para dispositivos bloqueados. Evita que los usuarios añadan, eliminen o reorganicen elementos, pero no restringe los ajustes visuales del Dock a menos que también estén activadas las claves `*-immutable` correspondientes. ::: ### Ejemplos de configuración habituales Un Mac corporativo con un conjunto fijo de apps obligatorias. Los usuarios no pueden modificar el Dock en absoluto. - Establece `contents-immutable` en `true`. - Añade las apps necesarias en `static-apps`. - Establece `show-recents` en `false` para ocultar la sección de apps recientes. - Establece `position-immutable` y `size-immutable` en `true` si también quieres bloquear los ajustes visuales. Apps que la organización quiere que sean visibles por defecto, pero que permite personalizar desde ahí. - Añade apps en `persistent-apps` (no en `static-apps`). - Deja todas las claves `*-immutable` en `false`. - Establece `tilesize` en un valor predeterminado cómodo para tu hardware. Un dispositivo compartido donde el Dock debe tener siempre el mismo aspecto, independientemente de quién inicie sesión. - Establece `contents-immutable`, `size-immutable`, `position-immutable`, `autohide-immutable` todos en `true`. - Usa `static-apps` y `static-others` exclusivamente. - Establece `autohide` en `false` para mantener el Dock siempre visible. - Establece `show-recents` en `false`. ### Comportamientos y limitaciones importantes - **Las actualizaciones del payload se aplican al siguiente inicio de sesión o sincronización de política.** Los cambios al payload del Dock se aplican cuando se actualiza el perfil MDM. En algunos casos, puede que el usuario necesite cerrar sesión y volver a iniciarla para que los cambios surtan efecto completamente. - **Los elementos añadidos por el usuario pueden persistir entre actualizaciones de MDM** si `contents-immutable` no está configurado. Cuando se envía un nuevo perfil sin este bloqueo, los elementos añadidos anteriormente por el usuario pueden permanecer en el Dock. - **Las rutas de las apps deben ser exactas.** Si una aplicación no está instalada en la ruta especificada en `_CFURLString`, el Dock mostrará un icono roto. Asegúrate de que la app esté instalada en el dispositivo antes de añadirla a la configuración del Dock. - **La expansión de `~` (tilde) en las rutas** puede no funcionar de forma fiable en los payloads de MDM. Usa rutas absolutas (por ejemplo, `/Users/Shared/`) en lugar de rutas relativas al usuario donde sea posible, o usa [variables dinámicas](https://docs.applivery.com/es/device-management/general-settings/dynamic-variables/). - **La configuración del Dock no instala apps.** Solo configura lo que aparece en el Dock. Las apps deben desplegarse por separado a través de la gestión de apps antes de añadirlas a la configuración del Dock. --- ## Gestión de archivos Source: https://docs.applivery.com/es/device-management/apple/macos/policies/file-management/ Description: Gestiona y protege archivos de contenido en dispositivos macOS usando Applivery — distribuye archivos mediante políticas y garantiza la seguridad organizativa. TL;DR: Distribuye y gestiona de forma segura archivos de contenido en dispositivos macOS usando Applivery añadiendo archivos a políticas, seleccionando tipos de archivo y configurando el alcance y la ubicación. Answers: ¿Qué tipos de archivo puedo gestionar en dispositivos macOS con Applivery? · ¿Dónde se guardan los archivos cuando se selecciona el alcance "Usuario primario"? · ¿Dónde se guardan los archivos cuando se selecciona el alcance "Todos los usuarios"? · ¿Dónde se guardan los archivos cuando se selecciona el alcance "Sistema"? · ¿Con qué frecuencia comprueba Applivery los cambios en los archivos de los dispositivos macOS? · ¿Cómo añado un archivo a una política en Applivery? · ¿Se requiere el agente macOS de Applivery para la gestión de archivos? Key topics: Gestión de archivos macOS, Mobile Device Management (MDM), Applivery, macOS A medida que las empresas crecen, también lo hace la necesidad de gestionar y proteger los datos en los dispositivos. Gestionar los archivos de contenido en dispositivos macOS es fundamental para mantener la productividad y la seguridad dentro de una organización. La gestión de archivos en macOS te permite subir archivos definiendo su ubicación y atributos, asignándolos al sistema, a todos los usuarios o al usuario actual. Con esta configuración, puedes distribuir libros, configurar un fondo de pantalla o desplegar certificados. :::warning Para usar esta función, asegúrate de que el **agente macOS de Applivery** esté activado. Puedes obtener más información sobre él [aquí](https://docs.applivery.com/es/device-management/apple/apple-policies/agent/). ::: **Añadir un archivo a una política** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a cualquiera de tus **Políticas** 1 o [crea una nueva](https://docs.applivery.com/es/device-management/general-settings/create-policies/). En el menú lateral izquierdo, haz clic en la sección **Recursos** 2 y luego haz clic en el botón **\+ Añadir Recurso** 3. ![add resource](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ade63557-2f89-45f2-b3ee-3fc13d6b5ab4.png) **Selecciona el tipo de archivo** Se mostrará una vista modal que te permite seleccionar el tipo de archivo que quieres añadir a la política: - **Libros**: en formato `.epub` o `.pdf`. - **Certificados**: en formato `.p12`, `.pem` o `.der`. - **Imágenes**: en formato `.png` o `.jpg`. **Subir el archivo** Puedes elegir subir el archivo seleccionado desde la sección Recursos o desde tu dispositivo. A continuación, puedes seleccionar tanto el **Alcance** como la **Ubicación** donde se guardará el archivo. Una vez que eliges el alcance, en el campo Ubicación puedes usar la ubicación recomendada o definirla tú mismo: - **Usuario primario**: El archivo se guardará para el usuario actual y solo será accesible para él. La ruta recomendada será `~/AppliveryAssets`. - **Todos los usuarios**: El archivo se guardará en una carpeta compartida accesible para todos los usuarios. La ruta recomendada será `/Users/Shared/AppliveryAssets`. - **Sistema**: El archivo se almacenará en una ruta protegida accesible solo por root. La ruta recomendada será `/var/root/AppliveryAssets`. :::info Las comprobaciones de archivos se realizan cada 10 minutos. Si el archivo no se encuentra, ha cambiado en tamaño o tiene atributos diferentes, se volverá a descargar, sobrescribiendo la versión anterior. ::: --- ## Configuración de FileVault Source: https://docs.applivery.com/es/device-management/apple/macos/policies/filevault/ Description: Configura el cifrado de disco FileVault en dispositivos macOS con Applivery — aplica el cifrado completo del disco y gestiona las claves de recuperación mediante MDM. TL;DR: Protege tus dispositivos macOS con FileVault usando Applivery configurando políticas de cifrado y gestionando las claves de recuperación mediante métodos automáticos o manuales. Answers: ¿Qué es FileVault en macOS? · ¿Qué se necesita para acceder a un Mac con FileVault activado? · ¿Cuáles son las opciones de gestión de claves de recuperación en Applivery? · ¿Cómo recupero la clave de recuperación de FileVault usando el método "Auto" en Applivery? · ¿Cómo recupero la clave de recuperación de FileVault usando el método "Manual" en Applivery? · ¿Qué hago si la clave de recuperación de FileVault muestra caracteres extraños en Applivery? · ¿Qué ocurre si aplico otra política de FileVault a un dispositivo ya cifrado? · ¿Desactivar la política de FileVault en Applivery desactiva FileVault en el dispositivo? Key topics: Configuración de FileVault, Gestión de dispositivos con Applivery, Políticas de seguridad macOS, FileVault, Applivery, macOS, Apple FileVault, disponible en macOS 10.3 y versiones posteriores, cifra todo el disco para proteger tus datos y evitar el acceso no autorizado en tu Mac. Una vez activado, necesitarás una **Contraseña** o **Clave de recuperación** para acceder a tu dispositivo, garantizando que tus datos permanezcan seguros e inaccesibles sin la autenticación adecuada. FileVault también cifra automáticamente todos los archivos nuevos, proporcionando una protección continua. Activar FileVault es una configuración útil para proteger tus datos en caso de que tu Mac se pierda o dañe. :::info Una vez configurada, eliminar la política o desasociar los dispositivos **no desactivará FileVault**. ::: Con Applivery, tienes dos opciones para la gestión de claves de recuperación (pudiendo elegir cómo se cifra y recupera la clave de recuperación): - **Auto** (recomendado): Applivery gestionará los certificados necesarios. La clave de recuperación se mostrará en los ajustes del dispositivo. - **Manual**: Deberás subir la clave pública. Más adelante, puedes descargar la clave de recuperación cifrada y descifrarla en tu dispositivo usando la clave privada. ### Gestión de clave de recuperación - Auto **Navega a Políticas** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), navega a cualquiera de tus **Políticas** 1 o [crea una nueva](https://docs.applivery.com/es/device-management/general-settings/create-policies/). En el menú lateral izquierdo, navega a la opción **\+ Añadir configuración** y selecciona **FileVault** 2. ![filevault](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/fa5b0322-8dbc-4abf-9d09-486604c35366.png) **Configura los ajustes principales** En el menú **Principal**, deberás **Activar** FileVault y seleccionar la opción **Diferir**, que pospone la activación de FileVault hasta que el usuario cierre sesión. Además, marca las opciones **Usar clave de recuperación** y **Mostrar clave de recuperación** para mostrarla más adelante. ![enable and defer](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/0e4d0d84-93b5-4fb3-9465-8a1e6b712449.png) ![recovery key](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/5db4eab0-6104-4cd3-a488-5d12d2faf569.png) **Configura los ajustes de opciones** En el menú **Opciones**, selecciona **No permitir deshabilitar FDE** para evitar que se desactive FileVault. ![dont allow disable](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/3e91cd76-0bcc-4418-8cfb-c18d344a3cbd.png) **Configura los ajustes de recuperación** En el menú **Recuperación**, deja seleccionada la opción **Auto**. Applivery gestionará los certificados necesarios y la clave de recuperación se mostrará en los **Ajustes del dispositivo**. ![recovery auto](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/1fdcb600-5b12-4f7b-928f-3ed3ee308c8f.png) **Recuperar la clave de recuperación** Después de guardar y actualizar la política, el usuario deberá cerrar sesión. Al siguiente inicio de sesión, aparecerán los formularios de activación de FileVault. En el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a cualquiera de tus **Dispositivos**, seleccionando el que deseas para obtener la clave de recuperación. Ve a la pestaña **Ajustes** 3 y selecciona **FileVault** 4 en el menú lateral izquierdo. Haz clic en el botón **Revelar** 5 para recuperar la clave de recuperación. ![reveal recovery key](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/8381ecc3-7e16-4790-942d-4270e0ab51af.png) ### Gestión de clave de recuperación - Manual **Crear un certificado para el cifrado de la clave de recuperación de FileVault** Para cifrar la clave de recuperación, debe crearse y subirse a Applivery un **certificado de cifrado**. En un ordenador macOS (10.8+), abre el **Terminal** y ejecuta el comando: ``` openssl req -x509 -nodes -newkey rsa:2048 -keyout private.pem -out public.der -days 365 -outform der ``` Esto generará una clave pública en formato `.der`. Después de crear el certificado, dirígete a **Recursos** 6 y selecciona **Certificados** 7 en el menú lateral izquierdo. Haz clic en **\+ Subir certificado** 8. Aparecerá una vista modal que te permite subir el certificado recién creado haciendo clic en el botón **Seleccionar archivo** 9 y cargándolo desde tu unidad. ![upload certificate](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/2a6f55f3-cc09-4e17-8235-f0a73690b481.png) **Configurar la política** Deberás realizar las mismas configuraciones que hiciste en el modo **Auto** para los menús **Principal** y **Opciones**. **Solo se modificarán los ajustes del menú de recuperación**. Esta vez, seleccionarás **Manual** para la gestión de claves de recuperación. En el campo **UUID del payload del certificado de cifrado** 10, cargarás el certificado subido anteriormente en la sección Certificados. Describe el campo **Ubicación** para indicar dónde se almacena la clave de recuperación, asegurándote de que los usuarios sepan dónde encontrarla. Para el campo **Clave del dispositivo**, introduce una cadena (texto de ayuda) para los usuarios que puedan haber olvidado su contraseña. Los administradores del sitio pueden usar esta clave para localizar la clave depositada para el dispositivo específico. ![recovery manual](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/da977ae3-fe42-4c06-9b07-ca647ae709d5.png) **Qué ocurre en el dispositivo** Después de guardar y actualizar la política en el terminal, el usuario deberá cerrar sesión. Al siguiente inicio de sesión, aparecerán los formularios de activación de FileVault. Una vez completados, envía un comando **Actualizar estado** y tendrás la clave cifrada disponible en el dispositivo bajo el campo **FDE Personal Recovery Key CMS**. Una vez aplicada la política, los usuarios no podrán modificar los ajustes de FileVault en **Preferencias del Sistema > Seguridad y privacidad > FileVault**. Los ajustes configurados en la política se aplicarán. :::warning Aplicar otra política de FileVault a un dispositivo ya cifrado no tiene ningún efecto. ::: **Recuperar la clave de recuperación** Por último, navega a cualquiera de tus **Dispositivos**. Ve a la sección **Ajustes**, selecciona **FileVault** en el menú lateral izquierdo y haz clic en el botón **Descargar archivo cifrado**. Se descargará un archivo `.dat` y deberás ejecutar el siguiente comando para descifrar la clave: ``` openssl cms -decrypt -in recovery.dat -inform DER -inkey filevault_privateKey.pem ``` :::warning La clave de recuperación de FileVault no puede recuperarse si el dispositivo fue cifrado antes de inscribirse o antes de aplicarle una política de FileVault. ::: ### Resolución de problemas #### Caracteres extraños o ilegibles al mostrar la clave de recuperación de FileVault Si la clave de recuperación de FileVault se muestra con caracteres extraños o ilegibles, generalmente significa que el dispositivo ya estaba cifrado antes de inscribirse en Applivery. En este escenario, Applivery está recuperando la clave de recuperación cifrada anteriormente, no una recién generada. Para resolver este problema, sigue estos pasos: 1. Pide al usuario que desactive manualmente FileVault en el dispositivo yendo a **Ajustes del sistema** > **Privacidad y seguridad** > **FileVault** > **Desactivar**. **Esta acción debe realizarla un usuario administrador en el Mac**. 2. Una vez desactivado FileVault, pide al usuario que **inicie sesión de nuevo** en el dispositivo. Tras el siguiente inicio de sesión, FileVault generará una nueva clave de recuperación que será correctamente gestionada y mostrada por Applivery sin problemas de formato. Este proceso garantiza que la clave de recuperación se regenere bajo la gestión de Applivery y pueda visualizarse y almacenarse correctamente para futuros escenarios de recuperación. --- ## Configuración de la página de inicio de Google Chrome Source: https://docs.applivery.com/es/device-management/apple/macos/policies/google-chrome-homepage-configuration/ Description: Configura la URL de la página de inicio de Google Chrome en dispositivos macOS usando un archivo Plist desplegado mediante las políticas de gestión de dispositivos de Applivery. TL;DR: Configura la página de inicio de Chrome en macOS usando archivos Plist y políticas de Applivery. Answers: ¿Cómo establezco una página de inicio personalizada para Google Chrome en macOS? · ¿Cuál es la clave Plist para establecer la URL de la página de inicio de Chrome? · ¿Cómo importo el Plist de la página de inicio de Chrome en Applivery? · ¿Qué clave Plist controla la página de nueva pestaña en Chrome? · ¿Dónde puedo encontrar el panel de Applivery para configurar las políticas de Chrome? · Después de importar la configuración de Chrome, ¿cómo lo verifico? · ¿Qué tipo de archivo subo para configurar la página de inicio de Chrome? Key topics: Gestión de dispositivos, Configuración del navegador, Políticas macOS, Google Chrome, Applivery, macOS Configurar la página de inicio permite a los administradores TI controlar el contenido que se muestra cuando los usuarios lanzan el navegador. Usa el siguiente Plist para establecer una URL de página de inicio para el navegador Google Chrome. Copia el contenido de abajo e impórtalo en la política macOS relevante. ```html title="Chrome Homepage Plist" PayloadContent HomepageLocation https://www.applivery.com NewTabPageLocation https://www.applivery.com/docs PayloadDisplayName Google Chrome PayloadIdentifier com.google.Chrome.F8C05D93-31F5-416E-AF46-2E54F2578F9A PayloadType com.google.Chrome PayloadUUID B98A135C-3F21-40E9-9D0C-CD9E4A5A46A6 PayloadVersion 1 ``` Reemplaza la URL de la página de inicio con la URL que quieras usar en el payload anterior. Por ejemplo: ```xml HomepageLocation https://www.applivery.com NewTabPageLocation https://www.applivery.com/docs ``` Una vez en el [**panel de Applivery**](https://dashboard.applivery.io), dirígete a cualquiera de tus **Políticas** 1 o [crea una nueva](https://docs.applivery.com/es/device-management/general-settings/create-policies/). Haz clic en el botón **\+ Añadir configuración** en el menú lateral izquierdo, luego haz clic en el botón **\+ Importar** 2. ![import](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/f3b41af3-190e-4361-9dfb-c0b1a568514a.png) Puedes copiar el Plist anterior o usar el botón **Subir XML** para subir uno nuevo. ![plist](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/417c6f5d-ffc2-46b2-9108-07b0ffa2194a.png) :::info Reinicia Google Chrome para verificar que la configuración se ha aplicado correctamente. ::: --- ## Instalar extensiones de Chrome Source: https://docs.applivery.com/es/device-management/apple/macos/policies/install-chrome-extensions/ Description: Fuerza la instalación de extensiones de Google Chrome en dispositivos macOS importando un Plist con ExtensionInstallForcelist o ExtensionSettings en una política de Applivery. TL;DR: Importa en una política macOS un Plist con la clave ExtensionInstallForcelist (payload com.google.Chrome). Los scripts de Applivery sirven para verificar el resultado o como alternativa cuando no puedes usar una política. Answers: ¿Cómo instalo una extensión de Chrome en macOS con Applivery? · ¿Cómo obtengo el ID de una extensión de Chrome? · ¿Necesito un Plist o un UUID nuevo por cada extensión? · ¿Puedo repartir las extensiones en varias políticas? · ¿Cómo fijo una extensión en la barra de herramientas de Chrome? · ¿Cómo compruebo que la extensión se ha instalado? · ¿Puedo instalar extensiones sin una política? · ¿Qué hago si la extensión aparece deshabilitada? Key topics: ID de una extensión de Chrome, Plist con ExtensionInstallForcelist, Fijar extensiones con ExtensionSettings, Scripts de verificación e instalación alternativa, Resolución de problemas, Applivery, Google Chrome, Chrome Web Store, macOS, Plist La forma recomendada de instalar extensiones de Google Chrome en macOS es importar en una política macOS un Plist con la clave `ExtensionInstallForcelist` (payload `com.google.Chrome`), igual que se hace con la [página de inicio de Chrome](https://docs.applivery.com/es/device-management/apple/macos/policies/google-chrome-homepage-configuration/). Los scripts de Applivery sirven para verificar el resultado o como alternativa cuando no puedes usar una política. ### Antes de empezar - Dispositivos macOS gestionados por Applivery, con Google Chrome instalado. - El **ID de la extensión**. - Acceso al [panel de Applivery](https://dashboard.applivery.io/) con permisos para editar políticas y, si usas scripts, la sección **Recursos**. ### Cómo obtener el ID de una extensión El ID es una cadena de 32 letras minúsculas (de la `a` a la `p`) que identifica de forma única la extensión. Puedes obtenerlo de tres maneras: 1. **Desde Chrome Web Store.** Abre la ficha de la extensión y copia el último fragmento de la URL: `https://chromewebstore.google.com/detail/nombre-de-la-extension/` 2. **Desde** `chrome://extensions`**.** Activa el **Modo desarrollador** (esquina superior derecha). Cada extensión instalada muestra su **ID** bajo la descripción. 3. **Desde Terminal en un Mac con la extensión instalada.** Los nombres de las carpetas de este directorio son los IDs: ```bash ls ~/Library/Application\ Support/Google/Chrome/Default/Extensions/ ``` Si usas varios perfiles de Chrome, sustituye `Default` por el nombre del perfil (por ejemplo, `Profile 1`). :::info Para extensiones alojadas fuera de Chrome Web Store, el ID se obtiene igual, pero en el Plist debes usar la URL de actualización de tu propio servidor en lugar de `https://clients2.google.com/service/update2/crx`. ::: ### Método recomendado: política con Plist #### Prepara el Plist El siguiente payload fuerza la instalación de una extensión. Sustituye `EXTENSION_ID` por el ID de tu extensión: ``` PayloadContent ExtensionInstallForcelist EXTENSION_ID;https://clients2.google.com/service/update2/crx PayloadDisplayName Google Chrome - Extensiones PayloadIdentifier com.google.Chrome.extensions.REEMPLAZAR-UUID PayloadType com.google.Chrome PayloadUUID REEMPLAZAR-UUID PayloadVersion 1 ``` Cada elemento de la lista tiene el formato `ID_DE_LA_EXTENSION;URL_DE_ACTUALIZACION`. Para instalar varias extensiones, añade una `` por extensión dentro del mismo ``. ##### Qué poner en los marcadores REEMPLAZAR-UUID Sustituye cada `REEMPLAZAR-UUID` por un UUID, un identificador único con este formato: `754C545B-75B5-4E50-927D-3BC06EBD47E0`. Hay dos sitios: - `PayloadUUID`: un UUID completo. - `PayloadIdentifier`: `com.google.Chrome.extensions.` seguido de un UUID. Puede ser el mismo que el de `PayloadUUID` o uno distinto. Para generar uno desde Terminal en un Mac (cada ejecución devuelve uno nuevo): ```bash uuidgen ``` Por ejemplo, si `uuidgen` devuelve `A1B2C3D4-E5F6-4A7B-8C9D-0E1F2A3B4C5D`: ```xml PayloadIdentifier com.google.Chrome.extensions.A1B2C3D4-E5F6-4A7B-8C9D-0E1F2A3B4C5D PayloadUUID A1B2C3D4-E5F6-4A7B-8C9D-0E1F2A3B4C5D ``` También sirve cualquier generador de UUID v4. ##### Cuándo generar un UUID nuevo

Situación

UUID

Añadir más extensiones al mismo Plist

No cambian: añade una <string> más al <array>

Editar un Plist que ya has importado

Mantén los mismos UUID

Crear un Plist distinto (otra política u otro payload)

Genera UUID nuevos, para que dos configuraciones no compartan identificador

No hace falta un Plist ni un UUID nuevo por cada extensión. :::warning Incluye **todas** las extensiones forzadas en un único Plist y una única política. Si repartes la clave `ExtensionInstallForcelist` entre varias configuraciones que apliquen al mismo dispositivo, no se garantiza que Chrome las combine y puede quedar activa solo una de ellas. ::: #### Impórtalo en una política de Applivery **Abre la política** En el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a cualquiera de tus **Políticas** 1 o [crea una nueva](https://docs.applivery.com/es/device-management/general-settings/create-policies/). **Importa el Plist** Haz clic en el botón **\+ Añadir configuración** en el menú lateral izquierdo y después en **\+ Importar** 2. ![import](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/f3b41af3-190e-4361-9dfb-c0b1a568514a.png) Pega el Plist o usa el botón **Subir XML** para subir el archivo. ![plist](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/417c6f5d-ffc2-46b2-9108-07b0ffa2194a.png) **Guarda** Guarda los cambios. #### Verifica el resultado Con la política sincronizada en el dispositivo, abre Chrome y comprueba: 1. `chrome://policy` → haz clic en **Recargar políticas** y confirma que aparece `ExtensionInstallForcelist` con estado **OK**. 2. `chrome://extensions` → la extensión debe aparecer instalada y marcada como gestionada por la organización. :::info Si Chrome estaba abierto cuando se aplicó la política, reinícialo para verificar que la configuración se ha aplicado. ::: ### Fijar la extensión en la barra de herramientas Una extensión instalada de forma forzosa queda disponible en el menú de extensiones de Chrome (el icono del puzle), pero no aparece fijada en la barra. Para que se muestre fijada desde el primer momento, usa la clave `ExtensionSettings` con la opción `toolbar_pin`. `ExtensionSettings` agrupa en un diccionario toda la configuración de cada extensión, identificada por su ID. Con ella puedes forzar la instalación y fijarla en la barra en el mismo bloque, por lo que **sustituye** a `ExtensionInstallForcelist` para esas extensiones: ``` PayloadContent ExtensionSettings aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa installation_mode force_installed update_url https://clients2.google.com/service/update2/crx toolbar_pin force_pinned PayloadDisplayName Google Chrome - Extensiones PayloadIdentifier com.google.Chrome.extensions.REEMPLAZAR-UUID PayloadType com.google.Chrome PayloadUUID REEMPLAZAR-UUID PayloadVersion 1 ```

Clave

Valor

Efecto

installation_mode

force_installed

Instala la extensión de forma forzosa

update_url

URL de actualización

Igual que en ExtensionInstallForcelist (la de Chrome Web Store, salvo extensiones alojadas fuera de la tienda)

toolbar_pin

force_pinned

Fija la extensión en la barra de herramientas

Para configurar varias extensiones, añade dentro del diccionario `ExtensionSettings` una clave por cada ID, cada una con su propio ``. Importa el Plist en la política igual que con `ExtensionInstallForcelist`. :::warning No declares la misma extensión a la vez en `ExtensionInstallForcelist` y en `ExtensionSettings`. Elige una de las dos claves para cada extensión. ::: :::info Si solo quieres instalar la extensión y dejar que cada usuario decida si la fija, usa `ExtensionInstallForcelist` y omite `toolbar_pin`. ::: La extensión queda instalada y fijada en la barra de herramientas de Google Chrome. ### Uso de scripts Los scripts de Applivery (Bash en macOS) no son necesarios para instalar la extensión con el método anterior, pero resultan útiles en dos casos. Tienes más detalles en [Scripts](https://docs.applivery.com/es/device-management/apple/macos/scripts/). #### Script de verificación Comprueba que el Plist con la extensión ha llegado al Mac. Pásale el ID de la extensión como argumento (entre comillas dobles). ```bash #!/bin/bash ## Uso: el primer argumento es el ID de la extensión de Chrome EXT_ID="$1" PLIST="/Library/Managed Preferences/com.google.Chrome.plist" if [ -z "$EXT_ID" ]; then echo "Falta el ID de la extensión como argumento." exit 2 fi if [ ! -f "$PLIST" ]; then echo "No existe $PLIST: la configuración de Chrome no está aplicada." exit 1 fi if /usr/libexec/PlistBuddy -c "Print :ExtensionInstallForcelist" "$PLIST" 2>/dev/null | grep -q "$EXT_ID"; then echo "OK: la extensión $EXT_ID está en ExtensionInstallForcelist." exit 0 else echo "La extensión $EXT_ID NO figura en ExtensionInstallForcelist." exit 1 fi ``` #### Script alternativo: instalación sin política (External Extensions) Si no puedes usar un Plist, Chrome admite registrar extensiones de forma externa mediante un archivo JSON por extensión en una ruta del sistema. Este script lo crea: ```bash #!/bin/bash ## Uso: el primer argumento es el ID de la extensión de Chrome EXT_ID="$1" DIR="/Library/Application Support/Google/Chrome/External Extensions" if ! [[ "$EXT_ID" =~ ^[a-p]{32}$ ]]; then echo "ID de extensión no válido: $EXT_ID" exit 2 fi mkdir -p "$DIR" cat > "$DIR/$EXT_ID.json" <

Síntoma

Posible causa

Qué hacer

chrome://policy no muestra ExtensionInstallForcelist

La política no se ha sincronizado o Chrome no se ha reiniciado

Comprueba que el dispositivo tiene la política asignada, fuerza la sincronización y reinicia Chrome

La clave aparece con error

ID mal escrito o formato incorrecto del elemento

Revisa que sea ID;URL y que el ID tenga 32 caracteres (a–p)

Solo una de varias extensiones se instala

Claves repartidas en varias configuraciones

Reúne todas las extensiones en un único Plist

El script de verificación indica que no existe el Plist

La configuración no ha llegado al Mac

Revisa la asignación de la política y el historial de ejecución del script

La extensión aparece pero está deshabilitada

Instalación por External Extensions pendiente de confirmación del usuario

Pasa al método con política (Plist)

--- ## Automatizar la creación de cuentas locales Source: https://docs.applivery.com/es/device-management/apple/macos/policies/local-account-automation/ Description: Automatiza la creación de cuentas locales macOS durante la inscripción Apple DEP usando Applivery. Agiliza el aprovisionamiento de dispositivos con integración SSO. TL;DR: Automatiza la creación de cuentas locales macOS durante la inscripción DEP usando la función de inscripción inteligente de Applivery y la integración SSO para un aprovisionamiento de dispositivos ágil. Answers: ¿En qué sistema operativo está disponible la creación automática de cuentas locales? · ¿Qué se necesita para automatizar la creación de cuentas locales en macOS? · ¿Dónde configuro las cuentas locales para las inscripciones inteligentes? · ¿Puedo configurar la contraseña de la cuenta primaria de forma remota? · ¿Qué campos de datos de usuario SSO se pueden usar para la creación automática de cuentas locales? · ¿Puedo combinar etiquetas de datos SSO para crear estructuras complejas? · ¿Las cuentas primarias se crean como cuentas de administrador por defecto? Key topics: Automatización macOS, Inscripción Apple DEP, Integración SSO, Apple DEP, Apple Business, Applivery, Single Sign-On :::info Esta función solo está disponible para macOS. ::: Al inscribir dispositivos a través del [Programa de inscripción de dispositivos (DEP) de Apple](https://docs.applivery.com/es/device-management/apple/enrollment/dep/), como parte de la integración de Apple Business, puedes automatizar la creación de cuentas locales durante el aprovisionamiento. A continuación puedes ver cómo automatizar la creación de cuentas locales en los siguientes casos de uso: - Configuración de cuenta predefinida por el administrador TI. - Creación de cuenta rellenada previamente con información de inicio de sesión único (SSO). - Creación automática de cuentas basada en información SSO. ### Configurar cuentas locales en inscripciones inteligentes El primer paso es [crear una nueva inscripción inteligente](https://docs.applivery.com/es/device-management/apple/enrollment/smart-enrollment/) y configurar la **Configuración de cuenta**. ![account configuration](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/7a824a70-c0d1-4eb3-8cd7-25a9f0f862e8.png) Durante la creación automática de cuentas locales, podrás configurar los **detalles de la cuenta de administrador** (incluyendo la contraseña) y los **detalles de la cuenta primaria**. La cuenta primaria se creará como cuenta de administrador por defecto, a menos que se _configure como cuenta estándar_ en el formulario. Puede bloquearse para que el usuario no pueda modificar los datos durante la configuración del dispositivo. :::warning Por diseño de Apple, la contraseña de la cuenta primaria no puede configurarse de forma remota. Debe ser establecida por el usuario durante la configuración del dispositivo. ::: ### Usar datos de usuario SSO en formularios Al integrar cualquier proveedor de inicio de sesión único en Applivery, podremos recuperar del directorio del proveedor de identidad algunos campos de datos de usuario como variables para que puedas usarlos para rellenar automáticamente algunos campos, por ejemplo, para la creación automática de cuentas locales en la gestión de dispositivos Apple para macOS. A continuación puedes ver la lista completa de campos que estarán disponibles: - `{{sso.firstname}}`: Nombre del usuario. - `{{sso.lastname}}`: Apellidos del usuario. - `{{sso.username}}`: Nombre de usuario. - `{{sso.email}}`: Dirección de correo electrónico completa del usuario. - `{{sso.email.username}}`: Nombre de usuario de la dirección de correo electrónico del usuario. Ten en cuenta que puedes combinar las etiquetas anteriores para crear estructuras complejas como la siguiente: `{{sso.firstname}}.{{sso.lastname}}` se traducirá automáticamente a `john.doe` si `{{sso.firstname}}` contiene el valor `john` y `{{sso.lastname}}` contiene el valor `doe`. --- ## Política de apagado remoto Source: https://docs.applivery.com/es/device-management/apple/macos/policies/remote-shutdown-policy/ Description: Configura una política de apagado remoto macOS en Applivery para garantizar que los dispositivos se apaguen en momentos definidos, mejorando la seguridad y la eficiencia energética. TL;DR: Configura una política de apagado macOS en Applivery para programar el apagado de dispositivos y mejorar la seguridad y la eficiencia energética. Answers: ¿Por qué es importante programar los apagados de los dispositivos macOS? · ¿Cómo configuro una política de apagado para dispositivos macOS con Applivery? · ¿Qué tipos de eventos puedo programar con la política de ahorro de energía de Applivery? · ¿Cómo se define la hora de apagado en el programa de energía de escritorio de Applivery? · ¿Cómo especifico en qué días de la semana debe aplicarse una política de apagado? · ¿Qué valor representa de lunes a viernes en la máscara de bits de días de la semana? · ¿Dónde puedo encontrar los ajustes de ahorro de energía en Applivery? Key topics: Gestión de dispositivos, Configuración de políticas, macOS, Applivery, Ahorro de energía Garantizar que los dispositivos macOS se apaguen correctamente en momentos o días definidos es fundamental en entornos donde la seguridad, la eficiencia energética y la disciplina operativa son prioritarias. Ya sea para evitar el acceso no autorizado fuera del horario laboral, preservar la salud de la batería o aplicar políticas de energía a nivel de empresa, un proceso de apagado controlado es esencial. Con Applivery, puedes configurar y desplegar de forma remota una política que inicia el apagado del dispositivo automáticamente. ### Configurar una política de apagado **Navega a Políticas** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io), dirígete a cualquiera de tus **Políticas** o [crea una nueva](https://docs.applivery.com/es/device-management/general-settings/create-policies/). En el menú lateral izquierdo, navega a la sección **\+ Añadir configuración** y elige **Ahorro de energía**. ![energy saver](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/b9e56d22-57a7-456b-94af-8101726a5754.png) **Configura el programa de energía de escritorio** Localiza el **Programa de energía de escritorio** y realiza la siguiente configuración: - **Tipo de evento**: En este caso, selecciona Apagado. Otras opciones disponibles incluyen Activación, Encendido, Activación/Encendido, Reposo y Reinicio. - **Hora**: La hora programada, expresada en minutos desde medianoche. Por ejemplo: `690 = 11:30 AM (11 x 60 + 30)`. - **Días de la semana**: Define los días en que se aplica el apagado, usando una máscara de bits: - 1 = Lunes. - 2 = Martes. - 4 = Miércoles. - 8 = Jueves. - 16 = Viernes. - 32 = Sábado. - 64 = Domingo. Puedes combinar valores para seleccionar varios días, por ejemplo, `1 + 2 + 4 + 8 + 16 = 31 → Lunes a viernes` --- ## Restablecer contraseña Source: https://docs.applivery.com/es/device-management/apple/macos/policies/reset-password/ Description: Restablece o cambia una contraseña de Mac usando Applivery — mediante Apple ID, clave de recuperación de FileVault o recuperación de macOS en dispositivos gestionados. TL;DR: Aprende a restablecer o cambiar tu contraseña de Mac usando métodos como Apple ID, recuperación de FileVault o recuperación de macOS. Answers: ¿Cuál es la diferencia entre cambiar y restablecer una contraseña de Mac? · ¿Cómo cambio mi contraseña de Mac si conozco la actual? · ¿Cómo puedo restablecer una contraseña de Mac usando otra cuenta de administrador? · ¿Cómo activo el restablecimiento de contraseña con Apple ID para un usuario de Mac? · ¿Cómo restablezco una contraseña de Mac usando mi Apple ID? · ¿Cómo puedo restablecer mi contraseña de Mac usando una clave de recuperación de FileVault? · ¿Dónde puedo encontrar la clave de recuperación de FileVault para un Mac? · ¿Cómo uso un script para restablecer la contraseña de un usuario de Mac? Key topics: Cambiar la contraseña de macOS, Restablecer la contraseña de macOS, Recuperación de FileVault, Recuperación de macOS, Restablecimiento de contraseña con Apple ID, macOS, Apple ID, FileVault, Applivery, Apple Gestionar una flota de dispositivos macOS a menudo significa tratar con problemas relacionados con contraseñas — ya sea credenciales olvidadas, incorporación de nuevos usuarios o aplicación de políticas de seguridad. Ya sea que estés dando soporte a un único usuario o a un gran entorno empresarial, estos métodos te ayudarán a garantizar un acceso seguro y fluido a los dispositivos macOS bajo tu gestión. Hay dos métodos principales para actualizar una contraseña en un Mac: **cambiar** la contraseña y **restablecerla**. Cada método tiene diferentes implicaciones dependiendo de si se conoce la contraseña original: - **Cambiar contraseña**: Si todavía conoces la contraseña actual, este es siempre el método preferido. Cambiar la contraseña puede hacerse directamente desde los **Ajustes del sistema** de la cuenta de usuario. Este enfoque garantiza que el **keychain de inicio de sesión**, que almacena las contraseñas guardadas y los elementos seguros, permanezca intacto y accesible. Como estás actualizando la contraseña mientras estás conectado, no hay ninguna interrupción en el keychain ni en los datos del usuario. - **Restablecer contraseña**: Restablecer la contraseña es una medida más drástica y solo debe usarse cuando la contraseña original se ha perdido y no puede recuperarse. Cuando restableces una contraseña, macOS no puede desbloquear el **keychain de inicio de sesión** original, que estaba cifrado con la contraseña anterior. Como resultado, se crea un **nuevo keychain de inicio de sesión** y el usuario puede perder acceso a las contraseñas guardadas y otros datos seguros a menos que tenga una copia de seguridad. :::info Tu contraseña de inicio de sesión es la contraseña que introduces para desbloquear tu Mac cuando lo enciendes o lo despiertas del reposo. No es tu contraseña de cuenta Apple, que te da acceso a la iTunes Store, App Store, Apple Books, iCloud y otros servicios de Apple. ::: ### Usar un script para cambiar la contraseña de inicio de sesión :::tip La **app agente de Applivery para macOS** debe estar activada en el dispositivo. Puedes obtener más información sobre el agente macOS [aquí](https://docs.applivery.com/es/device-management/apple/apple-policies/agent/). ::: :::info Para empezar, aprende a crear scripts siguiendo [este enlace](https://docs.applivery.com/es/device-management/apple/macos/scripts/). ::: :::warning **Limitaciones** - Las contraseñas no pueden restablecerse para usuarios bloqueados en la ventana de inicio de sesión. - Este procedimiento no se aplica a las cuentas gestionadas o creadas a través de [DEP](https://docs.applivery.com/es/device-management/apple/enrollment/dep/). ::: **Crea tu script** Copia y pega el siguiente script en el editor, luego ajusta los parámetros necesarios: - **USER\_LOCAL**: Nombre del usuario cuya contraseña quieres restablecer. - **NEW\_PASSWORD**: Nueva contraseña a asignar al usuario. - **USER\_ADMIN** y **ADMIN\_PASSWORD**: Credenciales de un usuario con permisos de administrador local. ``` #!/bin/bash USER_LOCAL="user" NEW_PASSWORD="NewPassword" USER_ADMIN="admin" ADMIN_PASSWORD="AdminPassword" sysadminctl -resetPasswordFor "$USER_LOCAL" -newPassword "$NEW_PASSWORD" -adminUser "$USER_ADMIN" -adminPassword "$ADMIN_PASSWORD" ``` **Asigna el script a una política** A continuación, dirígete a cualquiera de tus **Políticas** y selecciona la sección **Scripts** en el menú lateral izquierdo. Haz clic en el botón **\+ Añadir Script**. A continuación, elige el script, define el método de ejecución y añade los argumentos necesarios. Dependiendo del método seleccionado, el script puede ejecutarse automáticamente en modo **Loop** o **Once**, o puede **activarse manualmente** desde la sección **Acciones** del agente de Applivery cuando se configura como **On-demand**. ![actions agent](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/2c295465-c383-47a2-ba75-540a06ba71f0.png) ### Cambiar la contraseña de inicio de sesión Para cambiar tu contraseña en un Mac, empieza haciendo clic en el **menú Apple** y seleccionando **Ajustes del sistema**. Desde ahí, desplázate por la barra lateral y haz clic en **Usuarios y grupos**. Una vez en la sección Usuarios y grupos, localiza tu nombre de usuario y haz clic en el botón **Info** (i) 1 junto a él. Luego, selecciona **Cambiar** 2 para iniciar el proceso de actualización de contraseña. ![change-user-password-1](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/350c6d82-7cf9-4024-9a84-764d3c5b8aa9.png "change-user-password-1 | Applivery") Se te pedirá que introduzcas tu contraseña actual en el campo **Contraseña antigua**. A continuación, escribe la nueva contraseña deseada en el campo **Nueva contraseña** y vuelve a introducirla en el campo **Verificar** para confirmar. También se te pedirá que proporciones una **sugerencia de contraseña** — esta aparecerá después de tres intentos incorrectos de inicio de sesión o si haces clic en el icono de signo de interrogación en la ventana de inicio de sesión. Una vez rellenado todo, haz clic en **Cambiar contraseña** para completar la actualización. ![change-user-password-2](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/8d8813af-4a2a-4a76-b4f9-d1079d8f90cd.png "change-user-password-2 | Applivery") ### Restablecer la contraseña de Mac con otra cuenta de administrador Si hay una cuenta de administrador en el Mac, restablecer la contraseña de la cuenta bloqueada es sencillo. Ve a **Ajustes del sistema**, navega a la sección **Usuarios y grupos**. En la esquina inferior izquierda de la ventana, haz clic en el icono de candado e introduce tu contraseña de administrador para hacer cambios. A continuación, selecciona la cuenta que necesita restablecer la contraseña de la lista de la izquierda. En el panel derecho, haz clic en **Restablecer contraseña**. ### Restablecer la contraseña de Mac usando un Apple ID Primero, asegúrate de que la opción de restablecimiento de contraseña con la cuenta Apple esté activada para el usuario. Para ello, inicia sesión con una cuenta de administrador y abre **Ajustes del sistema**. Navega a **Usuarios y grupos**, luego haz clic en el botón Info (i) junto a la cuenta de usuario deseada. En las opciones que aparecen, activa el ajuste **Permitir al usuario restablecer contraseña usando la cuenta Apple**. ![allow-user-to-reset-password](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/24f00cfa-7f17-4768-a958-7f2ae10a3d5d.png "allow-user-to-reset-password | Applivery") En la pantalla de inicio de sesión, haz clic en el icono de tu cuenta de usuario. Los siguientes pasos dependerán de tu versión de macOS: - **En macOS Catalina y posterior**, aparecerá un campo de contraseña con un icono de signo de interrogación (?) a la derecha. Haz clic en el signo de interrogación. Aparecerá un mensaje que dice: _"Si olvidaste tu contraseña, puedes…"_ - **En macOS Mojave y anterior**, deberás introducir una contraseña incorrecta tres veces. Después del tercer intento, aparecerá un mensaje similar. El mensaje continuará: _"…restablecerla usando tu Apple ID."_ Haz clic en la flecha junto a **Reiniciar** para comenzar el proceso. ### Restablecer la contraseña de Mac con la clave de recuperación de FileVault FileVault es una función de cifrado de disco integrada en macOS que ayuda a proteger los datos de tu Mac cifrando todo el disco de inicio. Una vez activado, garantiza que solo los usuarios con las credenciales de inicio de sesión correctas o la clave de recuperación puedan acceder al contenido del dispositivo. Consulta nuestra [documentación](https://docs.applivery.com/es/device-management/apple/macos/policies/filevault/) para una guía paso a paso sobre cómo activar FileVault en macOS. ![macos-sequoia-login-window-password-entry](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/69ba1838-f482-41b9-8b77-55532489360a.png "macos-sequoia-login-window-password-entry | Applivery") En la pantalla de inicio de sesión, el mensaje dirá: _"…restablecerla usando tu clave de recuperación."_ Haz clic en la flecha e introduce la clave de recuperación (sin guiones — macOS los insertará automáticamente). Si la clave es correcta, la unidad se desbloqueará y podrás restablecer tu contraseña. Puedes encontrar la clave de recuperación en el [**panel de Applivery**](https://dashboard.applivery.io) seleccionando el dispositivo y navegando a **Ajustes > FileVault**. Haz clic en **Revelar** para mostrar la clave. ![recovery key](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/45c204ae-2c66-4346-b11a-0d0a84058e0a.png) Si ninguna de estas opciones está disponible o resulta exitosa, tu siguiente paso debería ser intentar usar la **recuperación de macOS**. ### Restablecer la contraseña de Mac mediante la recuperación de macOS Si ninguno de los métodos anteriores funciona para restablecer la contraseña del usuario, puedes probar una opción más avanzada: usar la **recuperación de macOS**. Para entrar en la recuperación de macOS en un Mac con procesador Apple silicon, primero asegúrate de que el dispositivo está completamente apagado. Luego, mantén pulsado el botón de encendido. Sigue manteniéndolo pulsado incluso después de que aparezca el logotipo de Apple, hasta que el Mac cargue las opciones de inicio. A continuación, haz clic en el icono **Opciones** y luego en **Continuar**. Espera a que se complete la barra de progreso. Al iniciar desde la recuperación, se te pedirá que selecciones una cuenta de usuario. Si no conoces la contraseña de ningún usuario listado, haz clic en **¿Olvidé todas las contraseñas?** para proceder con opciones de recuperación alternativas. ![](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/c2732291-c87b-45d3-85b7-495bc531664a.png "forgot-all-passwords | Applivery") Sigue las instrucciones en pantalla, que variarán según la configuración de tu Mac. Una vez que hayas proporcionado la información necesaria, se te pedirá que crees una nueva contraseña para tu cuenta. Después de establecer la nueva contraseña, haz clic en **Salir a la recuperación**, reinicia tu Mac e inicia sesión usando tus credenciales actualizadas. ![recovery-menu-options-restore-reinstall-safari-disk-utility](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/0aad8a97-9eda-4cba-a2b5-b4760ddc80bc.png "recovery-menu-options-restore-reinstall-safari-disk-utility | Applivery") En el menú **Utilidades** de la barra de menú en la parte superior de la pantalla, selecciona **Terminal**. En la ventana de Terminal que aparece, escribe `resetpassword` y pulsa **Retorno**. Se abrirá una nueva ventana que te presentará opciones de restablecimiento como _"Olvidé mi contraseña"_ o _"Mi contraseña no funciona al iniciar sesión."_ Selecciona la opción apropiada, haz clic en **Siguiente** y sigue las instrucciones en pantalla. ![](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/f31aceff-c542-4006-a9b2-615850c28ae4.gif "resetpassword | Applivery") --- ## Configuración de la página de inicio de Safari Source: https://docs.applivery.com/es/device-management/apple/macos/policies/safari-homepage-configuration/ Description: Configura la página de inicio del navegador Safari en dispositivos macOS usando un archivo Plist desplegado mediante las políticas de gestión de dispositivos de Applivery. TL;DR: Configura la página de inicio de Safari en macOS usando un archivo Plist importado en las políticas de gestión de dispositivos de Applivery. Answers: ¿Cómo establezco una URL de página de inicio para Safari? · ¿Cuál es la estructura del Plist de la página de inicio de Safari? · ¿Cómo cambio la URL de la página de inicio en el Plist? · ¿Dónde importo el Plist de la página de inicio de Safari? · ¿Cuál es la URL de página de inicio predeterminada en el Plist de ejemplo? · ¿Cómo verifico la configuración de la página de inicio de Safari? · ¿Qué controlan los ajustes "NewTabBehavior" y "NewWindowBehavior"? Key topics: Gestión de dispositivos, Configuración del navegador, Políticas macOS, Safari, Plist, Applivery Configurar la página de inicio permite a los administradores TI controlar el contenido que se muestra cuando los usuarios lanzan el navegador. Usa el siguiente Plist para establecer una URL de página de inicio para el navegador Safari. Copia el contenido de abajo e impórtalo en la política macOS relevante. ```html title="Safari Homepage Plist" PayloadContent HomePage https://www.applivery.com NewTabBehavior 1 NewWindowBehavior 0 PayloadDisplayName Safari PayloadIdentifier com.apple.Safari.5CF32BFB-0236-4247-BA28-B020EBB3DBFF PayloadType com.apple.Safari PayloadUUID 5CF32BFB-0236-4247-BA28-B020EBB3DBFF PayloadVersion 1 ``` Reemplaza la URL de la página de inicio con la URL que quieras usar en el payload anterior. Por ejemplo: ```xml HomePage https://www.applivery.io ``` Una vez en el [**panel de Applivery**](https://dashboard.applivery.io), dirígete a cualquiera de tus **Políticas** 1 o [crea una nueva](https://docs.applivery.com/es/device-management/general-settings/create-policies/). Haz clic en el botón **\+ Añadir configuración** en el menú lateral izquierdo, luego haz clic en el botón **\+ Importar** 2. ![import](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/7c94178b-e538-4189-88b0-68ae00016aee.png) Puedes copiar el Plist anterior o usar el botón **Subir XML** para subir uno nuevo. ![payload](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/62849c4b-add0-4217-8524-4dee3fd04d52.png) :::info Reinicia Safari para verificar que la configuración se ha aplicado correctamente. Asegúrate de que los ajustes adicionales, como `NewTabBehavior` y `NewWindowBehavior`, también estén correctamente configurados. ::: --- ## Acuerdo de licencia de software Source: https://docs.applivery.com/es/device-management/apple/macos/policies/software-license-agreement/ Description: Configura acuerdos de licencia de software (EULA) para dispositivos macOS en Applivery — aplica la aceptación antes del acceso a la app usando políticas. TL;DR: Aprende a subir y configurar acuerdos de licencia de software en Applivery para garantizar que los usuarios acepten los términos antes de usar el software. Answers: ¿Qué es un acuerdo de licencia de usuario final (EULA)? · ¿Quiénes son las partes involucradas en un EULA? · ¿Cómo subo un recurso de libro en Applivery? · ¿Cómo añado un recurso a una política en Applivery? · ¿Qué formatos de archivo se admiten para subir libros en Applivery? · ¿Qué alcance debo establecer para un recurso de libro en Applivery? · ¿Cuál es la ruta requerida para definir un recurso de libro en Applivery? · ¿Qué ocurre cuando un usuario inicia sesión en el dispositivo? Key topics: Licencias de software, Configuración de políticas, Gestión de dispositivos, Applivery, EULA, Acuerdo de licencia de software Los acuerdos de licencia de software varían en tipo, dependiendo de la naturaleza del software y la forma en que se licencia para su uso por terceros. Como el software está protegido por la ley de derechos de autor, el propietario debe licenciarlo para autorizar a terceros a usarlo. El software puede distribuirse directamente por el desarrollador o propietario o indirectamente a través de distribuidores externos. Un **Acuerdo de licencia de usuario final** (**EULA**) es una forma de licencia de software que concede a un usuario final el derecho a usar el software y define los términos y condiciones para su uso. Los EULA son típicamente acuerdos entre el propietario o desarrollador del software (el licenciante) y el individuo o entidad que usa el software (el licenciatario). ### Configuración **Cargar el archivo** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io), dirígete a la sección **Recursos** 1. En el menú lateral izquierdo, selecciona la pestaña **Libros** 2 y haz clic en el botón **\+ Cargar libro** 3. Aparecerá una vista modal que te permite subir archivos en formatos `.pdf`, `.epub`, `.rtf`, `.rtfd` y `.txt`. ![books](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/87de1bc7-1273-4f42-ad04-8bb5d8615994.png) **Configura tu política** Tras cargar el archivo, navega a cualquiera de tus **Políticas** 4 o [crea una nueva](https://docs.applivery.com/es/device-management/general-settings/create-policies/). Selecciona la sección **Recursos** 5 desde el menú lateral izquierdo y haz clic en el botón **\+ Añadir Recurso**. ![add book](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/2b42376e-3dd1-4551-bab3-955644adf52a.png) En la vista modal, cambia a la pestaña **Libro**, donde puedes seleccionar el archivo que subiste antes o subir uno nuevo. A continuación, establece el alcance como **Sistema**. La ruta a definir debe ser `/Library/Security/{assetName}.rtfd`. ![policy book](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/6eaa9674-8565-49c9-9204-c21a896e3feb.png) **Iniciar sesión en el dispositivo** Cuando el usuario intenta iniciar sesión en el dispositivo, se abrirá una nueva ventana que muestra el documento. El proceso de inicio de sesión quedará bloqueado hasta que el usuario acepte los términos. Solo después de aceptar los términos podrá continuar con el inicio de sesión. --- ## Actualizar contraseñas de usuario Source: https://docs.applivery.com/es/device-management/apple/macos/policies/update-user-passwords/ Description: Actualiza remotamente las contraseñas de usuario macOS usando scripts MDM de Applivery para una configuración consistente y una mayor seguridad del dispositivo. TL;DR: Usa Applivery para actualizar remotamente las contraseñas de usuario macOS mediante scripts asignados a políticas. Answers: ¿Cómo puede Applivery actualizar remotamente las contraseñas de usuario macOS? · ¿Qué se necesita para actualizar remotamente las contraseñas macOS con Applivery? · ¿Qué parámetros deben configurarse en el script de actualización de contraseñas? · ¿Cómo asigno el script de actualización de contraseñas a un dispositivo macOS? · ¿Qué métodos de ejecución están disponibles para el script de actualización de contraseñas? · ¿Dónde pueden los usuarios activar manualmente el script de actualización de contraseñas? · ¿Por qué es importante actualizar periódicamente las contraseñas de usuario macOS? Key topics: Gestión macOS, Mobile Device Management, Seguridad, Applivery, macOS, Script, Política La gestión eficaz de contraseñas es esencial para mantener la seguridad y la eficiencia operativa en entornos macOS corporativos. Usando Applivery, los equipos TI pueden actualizar remotamente las contraseñas de usuario en todos los dispositivos Mac gestionados, garantizando una configuración consistente, una mayor conformidad y una carga de trabajo manual reducida. :::warning El **agente macOS de Applivery** debe estar activado en el dispositivo. Puedes obtener más información sobre el agente macOS [aquí](https://docs.applivery.com/es/device-management/apple/apple-policies/agent/). ::: **Crea tu script** Para empezar, aprende a crear scripts siguiendo [este enlace](https://docs.applivery.com/es/device-management/apple/macos/scripts/). Asigna un nombre descriptivo al script y copia y pega el siguiente script en el editor, luego ajusta los parámetros necesarios: - **USERNAME** (`user`): Introduce el nombre de usuario de la cuenta macOS cuya contraseña quieres actualizar. - **NEWPASSWORD** (`new_password`): Establece la nueva contraseña para el usuario especificado. ``` #!/bin/bash ## Define the username and the new password USERNAME="username" # Replace 'username' with the actual username NEWPASSWORD="new_password" # Replace 'new_password' with the desired password ## Change the user's password using dscl dscl . -passwd /Users/"$USERNAME" "$NEWPASSWORD" ## Check if the change was successful if [ $? -eq 0 ]; then echo "The password for user $USERNAME has been successfully changed." else echo "There was an error trying to change the password for user $USERNAME." fi ``` **Asigna el script a una política** A continuación, dirígete a cualquiera de tus **Políticas** 1 o [crea una nueva](https://docs.applivery.com/es/device-management/general-settings/create-policies/). Selecciona la sección **Scripts** 2 desde el menú lateral izquierdo y haz clic en el botón **\+ Añadir Script** 3. ![policy script](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/d2d8cf0a-9084-49c6-84f6-555523c63c9a.png) A continuación, selecciona el script, elige el método de ejecución y añade los argumentos necesarios. Dependiendo del método de ejecución seleccionado, el script se ejecutará automáticamente en modo **Loop** o **Once**, o puede **activarse manualmente** desde la sección **Acciones** dentro del agente de Applivery cuando se configure como **On-demand**. ![add script to policy](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/daf8b8d1-d906-4e7b-b81e-956a2767b663.png) Actualizar periódicamente las contraseñas de usuario es una práctica crítica de ciberseguridad. Automatizar esta tarea a través de Applivery garantiza actualizaciones de credenciales rápidas, seguras y consistentes, reduciendo los riesgos asociados con contraseñas obsoletas y manteniendo todos los dispositivos macOS alineados con los estándares de seguridad corporativos. --- ## Configuración del fondo de pantalla Source: https://docs.applivery.com/es/device-management/apple/macos/policies/wallpaper-configuration/ Description: Configura el fondo de pantalla macOS en dispositivos gestionados usando las políticas MDM de Applivery para aplicar la identidad corporativa y bloquear los ajustes del fondo de pantalla. TL;DR: Configura el fondo de pantalla macOS mediante MDM para aplicar la identidad corporativa en dispositivos gestionados, garantizando una apariencia consistente en toda la organización. Answers: ¿Cómo puedo subir una imagen de fondo de pantalla a Applivery? · ¿Qué formatos de imagen se admiten para los fondos de pantalla macOS en Applivery? · ¿Cómo añado una imagen de fondo de pantalla a una política de dispositivo en Applivery? · ¿Qué opciones de alcance están disponibles al establecer una política de fondo de pantalla? · ¿Cómo evito que los usuarios cambien el fondo de pantalla en macOS? · ¿Dónde debo aplicar la configuración del fondo de pantalla para una aplicación consistente? · ¿Cómo configuro la ruta del fondo de pantalla en la política? · ¿Dónde puedo encontrar la sección Recursos en el panel de Applivery? Key topics: Configuración del fondo de pantalla macOS, Gestión de políticas MDM, Identidad corporativa, Gestión de dispositivos, Applivery, macOS, MDM, JPG, PNG Personalizar el fondo de pantalla del escritorio se considera a menudo una forma de reforzar la identidad corporativa en los dispositivos gestionados por la organización. Los ajustes del fondo de pantalla macOS permiten a las empresas garantizar que todos los dispositivos corporativos muestren el logotipo o la marca de la empresa. Los administradores pueden configurar el fondo de pantalla con el logotipo de la organización o cualquier imagen que elijan y aplicarlo a toda una flota de dispositivos. Esta personalización también les permite establecer fondos de pantalla para todos los usuarios de un dispositivo y decidir si deben actualizarse periódicamente. ### Configuración de la política **Cargar la imagen** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io), dirígete a la sección **Recursos** 1. Luego, dirígete a la pestaña **Imágenes** 2 y haz clic en el botón **\+ Cargar Imagen** 3. Aparecerá una vista modal que te permite subir imágenes en formatos `.jpg` y `.png`. ![upload image](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/47f23af5-4689-4678-a74e-604f746a7d78.png) **Configura tu política** Tras cargar la imagen, navega a cualquiera de tus **Políticas** 4 o [crea una nueva](https://docs.applivery.com/es/device-management/general-settings/create-policies/). Ve a la sección **Recursos** 5 desde el menú lateral izquierdo y haz clic en el botón **\+ Añadir Recurso**. En la vista modal, dirígete a la pestaña **Imagen** 6. Aquí puedes seleccionar una imagen que subiste anteriormente o subir una nueva. Luego, elige el alcance: **Usuario primario**, **Todos los usuarios** o **Sistema**. Haz clic en el botón **Usar ubicación recomendada** 7 para una configuración sugerida. ![add image to policy](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ef11ca2b-7bca-4c33-b8da-ed3dc1b33ab4.png) :::info Recomendamos aplicar la configuración a **Todos los usuarios** y usar la ruta predeterminada para garantizar que el fondo de pantalla se aplique de forma consistente en todo el sistema. ::: Una vez cargada la imagen, haz clic en el botón + **Añadir configuración** en el menú lateral izquierdo y selecciona **Escritorio** de las opciones de configuración disponibles. Solo necesitas añadir la ruta que estableciste al subir la imagen (ya sea que usaras la ruta recomendada o creaste una manualmente). ![desktop](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/4492929d-e164-4490-9e90-75eee58aa5b9.png) Adicionalmente, puedes activar el ajuste **Bloqueado** para evitar que los usuarios cambien el fondo de pantalla. Una vez configurado, solo necesitas **Guardar cambios**. ![desktop configuration](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/acb81c96-8182-46a1-82c5-a67c71f23ac9.png) ### ¿Qué ocurre en el dispositivo? Después de aplicar la política, el fondo de pantalla del dispositivo macOS se actualizará según las configuraciones que hayas establecido. Todos los usuarios del dispositivo verán el nuevo fondo de pantalla y, si la opción está bloqueada, no podrán cambiarlo. Esto garantiza que todos los dispositivos gestionados mantengan una apariencia consistente en línea con tu identidad corporativa. --- ## Soporte Remoto Source: https://docs.applivery.com/es/device-management/apple/macos/remote-support/ Description: Soporte remoto para dispositivos macOS gestionados en Applivery: conéctate a un Mac a través de TeamViewer sin salir del panel. TL;DR: Habilita TeamViewer Remote en una política de macOS y conéctate a cualquier Mac de esa política desde su menú Acción, sin configurar TeamViewer en el propio dispositivo. Answers: ¿Cómo controlo remotamente un Mac con Applivery? · ¿Applivery es compatible con TeamViewer en macOS? · ¿Cómo inicio una sesión remota en un dispositivo macOS? Key topics: Soporte remoto en macOS, Integración con TeamViewer, Sesiones remotas, Applivery, macOS, TeamViewer El soporte remoto te permite conectarte a un Mac gestionado directamente desde el panel de Applivery: para ver lo mismo que la persona que está delante, guiarla paso a paso o resolverlo tú mismo cuando no hay nadie. En macOS, el soporte remoto funciona con **TeamViewer**. Lo habilitas una vez en una política, Applivery instala de forma silenciosa la app TeamViewer Host y los perfiles que necesita en todos los Mac a los que se aplica esa política, y a partir de ahí inicias las sesiones desde el menú **Acción** del dispositivo. No hay que configurar TeamViewer en el propio dispositivo, ni nada que la persona que lo usa tenga que instalar. :::warning Esta es una función premium que puede no estar disponible en tu plan actual. Consulta la disponibilidad en nuestra [página de precios](https://www.applivery.com/device-management-pricing/). ::: --- ## Soporte Remoto con TeamViewer Source: https://docs.applivery.com/es/device-management/apple/macos/remote-support/teamviewer-remote-support/ Description: Habilita el soporte remoto con TeamViewer para dispositivos macOS en Applivery: instalación silenciosa, permisos de macOS, tipos de sesión, licencias y resolución de problemas. TL;DR: Habilita TeamViewer Remote en una política de macOS, deja que Applivery instale TeamViewer Host y sus perfiles, asegúrate de que se ha concedido Grabación de pantalla y audio, e inicia las sesiones desde el menú Acción del dispositivo. Answers: ¿Cómo habilito TeamViewer en dispositivos macOS con Applivery? · ¿Qué permisos necesita TeamViewer Host en un Mac? · ¿Cómo concedo el permiso de Grabación de pantalla y audio a TeamViewer Host? · ¿Cómo se contabilizan las licencias de TeamViewer en Applivery? · ¿Por qué mi Mac muestra "App not installed"? · ¿Qué diferencia hay entre una sesión atendida y una desatendida? · ¿Qué pasa si una política habilita TeamViewer y otra lo deshabilita? Key topics: Habilitar TeamViewer Remote en una política de macOS, Instalación silenciosa de TeamViewer Host, Perfiles y permisos de macOS (Escritorio remoto, Accesibilidad, Grabación de pantalla y audio), Tipos de sesión y licencias, Resolución de problemas de sesiones remotas, Applivery, TeamViewer, macOS :::warning Esta es una función premium que puede no estar disponible en tu plan actual. Consulta la disponibilidad en nuestra [página de precios](https://www.applivery.com/device-management-pricing/). ::: Al habilitar **TeamViewer Remote** en una política de macOS, Applivery instala de forma silenciosa la app TeamViewer Host en todos los Mac a los que se aplica esa política, aplica los perfiles que necesita y los registra en TeamViewer. A partir de ahí, inicias una sesión remota desde el menú **Acción** del dispositivo: sin configurar TeamViewer en el propio dispositivo, y sin que la persona que lo usa tenga que instalar nada de antemano. :::info ¿Buscas Windows? Consulta [Soporte remoto con TeamViewer para Windows](https://docs.applivery.com/es/device-management/windows/remote-support/teamviewer-remote-support/). ::: ### Antes de empezar En macOS, TeamViewer Host necesita algunos permisos del sistema para poder mostrar y controlar la pantalla. Applivery se encarga de la mayoría, pero uno hay que concederlo en el propio Mac:

Capa

Qué hace

Quién se encarga

Perfil de configuración de TeamViewer

Configura TeamViewer Host y registra el dispositivo para las sesiones remotas

Applivery: se aplica cuando la política está en Activado y se elimina cuando está en Desactivado

Perfil de permisos de Apple

Concede a TeamViewer Host los permisos de Escritorio remoto y Accesibilidad que necesita para controlar el Mac

Applivery: se aplica cuando la política está en Activado

Grabación de pantalla y audio

Permiso de privacidad de macOS que permite a TeamViewer Host compartir la pantalla durante una sesión

La persona que usa el Mac, sin necesidad de permisos de administrador

#### Grabación de pantalla y audio Este permiso es independiente del perfil de permisos de Apple y hay que aprobarlo en el Mac, pero la persona que lo usa puede hacerlo sin permisos de administrador. Hasta que se conceda, las sesiones pueden no llegar a iniciarse. Si ha descartado el aviso, o nunca le ha aparecido, pídele que: 1. Abra **Ajustes del Sistema** → **Privacidad y seguridad** → **Grabación de pantalla y audio**. 2. Active el interruptor junto a **TeamViewer Host**. ### Habilitar TeamViewer Remote **Abrir la política** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a **Políticas** 1 y abre la política de macOS en la que quieres habilitar el soporte remoto. **Ir a la sección TeamViewer Remote** En el menú lateral izquierdo, selecciona la sección **TeamViewer Remote** y busca la configuración **TeamViewer Remote** 2. **Ponerlo en Activado** Elige **Activado** y guarda los cambios. Todos los dispositivos a los que se aplica esa política recibirán ahora TeamViewer Host y sus perfiles de forma automática. ![macos remote support](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/f5582302-f09a-4bda-b362-cf8786d228e8.png) #### Los tres estados de configuración TeamViewer Remote usa el patrón **No configurado / Activado / Desactivado**. Esto importa porque un dispositivo puede tener [más de una política aplicada](https://docs.applivery.com/es/device-management/general-settings/policy-composition/): lo que llega realmente al dispositivo es el resultado compuesto de todas las políticas de su conjunto, no el valor de ninguna en concreto. Así que cada estado es, en realidad, lo que _esta_ política aporta a esa composición:

Estado

Qué aporta esta política

Activado

Activa TeamViewer Remote. Se instala TeamViewer Host, se aplican el perfil de configuración de TeamViewer y el perfil de permisos de Apple, el dispositivo se registra en TeamViewer y consume una licencia de tu pool

Desactivado

Desactiva TeamViewer Remote. Todo dispositivo que acabe sin la función activa se da de baja en TeamViewer, se elimina el perfil de configuración de TeamViewer y su licencia vuelve al pool

No configurado

No aporta nada. Esta política se mantiene al margen de la decisión, y el resultado lo determinan las demás políticas del conjunto

#### Qué política prevalece Las políticas se evalúan de forma **secuencial**, en el orden que marca su prioridad dentro de la composición. La primera política que fija un valor decide el resultado: `No configurado` se salta, y ninguna política posterior sobrescribe un valor que ya se ha fijado. Dicho de otro modo, ni `Activado` ni `Desactivado` gana al otro: **lo que decide es el orden**. Así queda en un dispositivo con dos políticas, donde la política 1 se evalúa primero:

Política 1

Política 2

Resultado compuesto

No configurado

Activado

Activado: la política 1 no fija nada, así que decide la política 2

Desactivado

Activado

No activo: la política 1 ha llegado antes, y la política 2 no la sobrescribe

Activado

Desactivado

Activado: la misma regla al revés, la política 1 ha llegado antes

Usa **No configurado** cuando una política no tenga por qué decidir sobre el soporte remoto, por ejemplo una que solo despliega apps. Usa **Desactivado** cuando quieras que una política mantenga el soporte remoto desactivado de forma activa, y comprueba que se evalúa **antes** que cualquier política que lo habilite, o no tendrá ningún efecto. #### Instalación automática Applivery despliega TeamViewer Host de forma silenciosa como `.pkg`: la persona que usa el Mac no tiene que instalar nada. Junto con la app, Applivery aplica el perfil de configuración de TeamViewer y el perfil de permisos de Apple (Escritorio remoto y Accesibilidad) que se describen en [Antes de empezar](#antes-de-empezar). El dispositivo aparece como **Listo** en cuanto TeamViewer Host está instalado y configurado. Recuerda que **Grabación de pantalla y audio** tiene que estar concedido en el Mac para que las sesiones puedan compartir la pantalla. #### Cómo se contabilizan las licencias Cada dispositivo con TeamViewer Remote activo en su configuración compuesta consume una licencia de TeamViewer de tu plan, **se conecte alguien a él o no**. Lo que cuenta es el número de dispositivos con la función activa, no el número de sesiones que abres. En cuanto un dispositivo deja de tener TeamViewer Remote activo a través de sus políticas, **se da de baja en TeamViewer y su licencia se libera** automáticamente. Da igual cómo haya cambiado la composición: poner una política en **Desactivado**, quitar la política que lo habilitaba o mover el dispositivo a otro sitio tienen el mismo efecto. ### Iniciar una sesión remota **Abrir el dispositivo** Dirígete a cualquiera de tus **dispositivos** macOS y haz clic en el botón **Acción** 1. Después, selecciona **TeamViewer Remote** 2. ![teamviewer device](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/a6fadbdf-d770-45aa-8c39-7d5d773dd9c7.png) **Elegir cómo quieres conectarte** Se abre la ventana **TeamViewer Remote Support**. Elige el **Tipo de control** y la opción **Abrir con** para esta sesión 3. ![teamviewer modal](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/675d0335-dc73-4e80-b4ce-a356193f9497.png) **Iniciar la sesión** Haz clic en **Iniciar sesión remota**. Si has elegido **Cliente de TeamViewer**, la sesión se entrega a la app de escritorio de TeamViewer de tu equipo, que se conecta al dispositivo. El tipo de sesión no se fija al habilitar la política: todas las opciones están disponibles siempre, y eliges en cada sesión.

Ajuste

Opciones

Tipo de control

Desatendido: se conecta sin que nadie tenga que aceptar en el dispositivo, para equipos que no está usando nadie. Atendido: alguien en el dispositivo tiene que aceptar la sesión entrante. View only: alguien en el dispositivo también tiene que aceptar, y tú ves la pantalla sin que se envíe ninguna entrada de teclado ni de ratón

Abrir con

Pestaña nueva: se ejecuta en el cliente web de TeamViewer, sin instalar nada en tu equipo. Cliente de TeamViewer: entrega la sesión a la app de escritorio de TeamViewer, con todas sus funciones

Puedes cambiar de opción tantas veces como quieras antes de hacer clic en **Iniciar sesión remota**: el valor que se muestra al hacer clic es el que se usa. #### Qué puedes hacer durante una sesión Una vez conectado, las funciones disponibles dependen del **Tipo de control** y de la opción **Abrir con** que hayas elegido, y de lo que admita el cliente de TeamViewer en esa sesión. En el propio Mac gestionado, TeamViewer Host aparece instalado junto al agente de Applivery (si el dispositivo lo tiene): lo ha puesto ahí la instalación automática descrita más arriba. ### Resolución de problemas La ventana **TeamViewer Remote Support** muestra una etiqueta de estado junto al dispositivo, para que sepas de un vistazo si se puede iniciar una sesión. Pasa el ratón por el icono ⓘ que hay al lado para ver una explicación breve. #### Listo TeamViewer Host está instalado y configurado en el dispositivo. Puedes iniciar una sesión. #### No activado en la política Las políticas que componen la configuración del dispositivo no tienen TeamViewer Remote en **Activado**. Vuelve a [Habilitar TeamViewer Remote](#habilitar-teamviewer-remote) y comprueba que estás editando la política a la que ese dispositivo está realmente asignado. ![not enabled](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/36b99cc1-2f9c-4d14-8888-d413e11339e9.png) #### App no instalada La política está habilitada, pero TeamViewer Host todavía no ha terminado de instalarse en ese dispositivo o no ha podido. Como la instalación es silenciosa, espera y vuelve a intentarlo. Si persiste, comprueba que se han aplicado al dispositivo el perfil de configuración de TeamViewer y el perfil de permisos de Apple (consulta [Antes de empezar](#antes-de-empezar)). Iniciar una sesión contra un dispositivo en este estado falla, elijas el Tipo de control y el Abrir con que elijas. #### La sesión no se inicia en un dispositivo Listo TeamViewer Host está instalado, pero la sesión no arranca bien o la persona que está delante del Mac ve un aviso de grabación. Normalmente significa que todavía no se ha concedido **Grabación de pantalla y audio**. Pídele que lo active para **TeamViewer Host** en **Ajustes del Sistema** → **Privacidad y seguridad** → **Grabación de pantalla y audio**: no necesita permisos de administrador para hacerlo. Si el control remoto sigue sin funcionar, comprueba que el perfil de permisos de Apple (Escritorio remoto y Accesibilidad) está en el dispositivo. Si la política está habilitada pero falta el perfil, espera a que termine de aplicarse y vuelve a intentarlo. #### El dispositivo se desconecta a mitad de sesión Si el dispositivo se desconecta justo después de hacer clic en **Iniciar sesión remota**, la ventana de la sesión remota se cierra sola. Espera a que el dispositivo vuelva a estar en línea e inicia una sesión nueva. #### No pasa nada al hacer clic en Iniciar sesión remota Dale un momento antes de volver a hacer clic: un doble clic en **Iniciar sesión remota** no abre dos sesiones, así que pulsar otra vez no acelera nada. --- ## Scripts Source: https://docs.applivery.com/es/device-management/apple/macos/scripts/ Description: Automatiza tareas en dispositivos macOS gestionados usando scripts en Applivery — crea, asigna y gestiona scripts para una gestión de dispositivos eficiente. TL;DR: Automatiza tareas repetitivas en dispositivos gestionados usando scripts en Applivery para una gestión de dispositivos eficiente. Key topics: gestión de dispositivos, automatización, scripting, Applivery, MDM, Administradores TI Un script informático es esencialmente una secuencia de instrucciones (comandos) que el ordenador ejecuta, lo que lo convierte en una excelente herramienta para automatizar tareas repetitivas. Los scripts son altamente escalables y versátiles. Dado que los scripts pueden desplegarse en los dispositivos de los usuarios a través de soluciones de gestión de dispositivos (como Applivery), son invaluables para los equipos TI. Te permiten realizar tareas complejas de forma rápida, precisa y sin esfuerzo: - **Rápidamente**: Usando scripts junto con Mobile Device Management, puedes automatizar procesos tediosos. Por ejemplo, puedes acceder a un programa en 100 dispositivos de empresa con cero clics en lugar de hacerlo manualmente 100 veces. - **Con precisión**: Un script bien escrito ejecutará siempre la misma acción definida, reduciendo el riesgo de errores que podría producirse si un administrador humano realizara la tarea manualmente, lo que puede llevar a inconsistencias y confusión. - **Fácilmente**: Puedes lograr tareas complejas y detalladas dividiéndolas en scripts más pequeños y manejables, lo que simplifica considerablemente el proceso general. **Crea tu primer script** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a la sección **Recursos** 1, luego navega a la sección **Scripts** 2 desde el menú lateral izquierdo y haz clic en **\+ Crear Script** 3. ![add script](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/7e25d712-6411-469b-8b27-cd63db3d3152.png) Aparecerá un editor de código en la pantalla. Dentro del editor, puedes crear un nuevo script o subir uno existente desde tu dispositivo, lo que te permite adaptar fácilmente los scripts a tus necesidades. Para crear un nuevo script, usa la interfaz del editor y empieza a escribir. Primero, selecciona el lenguaje deseado — **Bash** 4 en este caso. Para subir un script existente, haz clic en **Cargar desde archivo** 5, selecciona tu script y estará listo para usar. Por último, proporciona un **Nombre** 6 (y opcionalmente una descripción), luego haz clic en **Crear** 7. ![create macos scripts](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/44bcbef3-e542-4ccb-9fef-2eef0b5d8c4f.png) :::info Si necesitas ayuda para crear un script, también puedes usar nuestro **Asistente IA**. Haz clic en el botón correspondiente y aparecerá un cuadro de diálogo donde puedes describir el script que necesitas. Nuestro asistente lo generará por ti. ::: :::warning El Asistente IA es una función premium que puede no estar disponible en tu plan actual. Consulta la disponibilidad en nuestra [página de precios](https://www.applivery.com/device-management-pricing/). ::: **Asigna scripts a tus dispositivos** Ahora, navega a cualquiera de tus **Dispositivos**, selecciona la pestaña **Scripts** 8 y haz clic en el botón **\+ Asignar Script** 9. ![script device assignment](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/36316de5-af93-4600-ac22-6b1fcb76c6b4.png) Aparecerá una vista modal que te permite elegir un script de la sección Scripts o subirlo desde tu dispositivo. También tendrás la opción de seleccionar el método de ejecución y añadir los argumentos del script: - **Una vez**: El script se ejecutará una vez por dispositivo. También tendrás la opción de repetir la ejecución, aunque ya haya sido ejecutada anteriormente. - **Bucle**: El script se ejecutará cíclicamente en el intervalo de tiempo seleccionado. - **Bajo demanda**: El script nunca se ejecutará automáticamente y solo se ofrecerá como elemento opcional desde el Self-Service. A continuación, puedes encontrar la lista completa de interpolaciones con etiquetas mustache para los argumentos del script. Ten en cuenta que cada argumento debe estar separado por **comillas dobles** (**""**): - "`{{device.id}}`". - "`{{device.displayName}}`". - "`{{device.serialNumber}}`". - "`{{device.osVersion}}`". - "`{{device.chip}}`". - "`{{device.isAppleSilicon}}`". - "`{{device.hostName}}`". - "`{{user.id}}`". - "`{{user.email}}`". - "`{{user.name}}`". ![script form](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/7dab607d-f8e2-45f2-8d51-66fd4af7777b.png) Haciendo clic en el **botón de historial de ejecución** 10, puedes ver el historial de ejecución de todos tus scripts. También puedes acceder al historial de ejecución de un script específico haciendo clic en el propio script o en los tres puntos verticales al final del script. Al hacer clic en estos puntos también se mostrarán acciones adicionales: - **Editar**: Edita el script. - **Desasignar**: Desasigna el script del dispositivo. - **Ver**: Ve el script original en la sección de recursos. :::warning Para los scripts con el método de ejecución **Una vez**, también verás la opción **Repetir ejecución**. Además de permitir reintentar un script tras un fallo, esta opción también determina si un script con el mismo ID puede ejecutarse de nuevo en un dispositivo donde ya se ejecutó anteriormente. Esto garantiza que el script se enviará de nuevo, independientemente de su historial de ejecución previo en ese dispositivo. ::: ![execution history](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/902159c0-f7f6-4fcb-94d5-790ddd4ba32a.png) **Asignar scripts a tus políticas** Los scripts no tienen por qué asignarse dispositivo a dispositivo. Asignar uno a una política cubre todos los dispositivos a los que se aplica esa política, que es la vía práctica para cualquier cosa que deba ejecutarse en un parque entero en lugar de en una sola máquina. Desde cualquiera de tus **Políticas** 11, ve a la sección **Scripts** 12 del menú lateral izquierdo y haz clic en **\+ Añadir Script** 13. Aparecerá el mismo modal descrito en el paso anterior, con los mismos métodos de ejecución y argumentos. ![assign to policy](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/3b3ad093-d7ad-4b3d-be61-c35430a8637a.png) Una vez guardes los cambios, los scripts asignados a esa política se desplegarán en todos los dispositivos que la tengan asignada durante su próxima sincronización. ### ¡Hazlo tú mismo! Para ayudar a los administradores a acelerar las configuraciones comunes y las tareas operativas, Applivery proporciona un [Repositorio público de scripts](https://github.com/applivery/applivery-mdm-scripts) con scripts macOS listos para usar. Este repositorio incluye scripts útiles para acciones rápidas y configuraciones estándar, lo que permite a los equipos TI desplegar soluciones comunes sin tener que crear scripts desde cero. El objetivo de esta iniciativa es **no solo proporcionar recursos reutilizables, sino también fomentar la colaboración**. La comunidad puede contribuir activamente enviando scripts que abordan casos de uso del mundo real, ayudando a expandir y mejorar la biblioteca compartida a lo largo del tiempo. Aprovechando el **repositorio público de scripts**, las organizaciones pueden reducir el tiempo de implementación, estandarizar los procedimientos operativos y beneficiarse de la experiencia colectiva. --- ## Eliminar cuenta de usuario local Source: https://docs.applivery.com/es/device-management/apple/macos/scripts/delete-local-user/ Description: Script bash para macOS que elimina completamente una cuenta de usuario local borrando el registro de Directory Services, el directorio home y la entrada de grupo. Ideal para la baja de empleados. TL;DR: Automatiza tareas repetitivas en dispositivos gestionados usando scripts en Applivery para una gestión de dispositivos eficiente. Answers: ¿Qué hace el script de eliminación de usuarios macOS? · ¿Cuáles son los requisitos para usar el script de eliminación de usuarios macOS? · ¿Cómo proporciono el nombre de usuario al script de eliminación de usuarios macOS? · ¿Cómo creo el script de eliminación de usuarios en Applivery? · ¿Qué método de ejecución debo usar para el script de eliminación de usuarios? · ¿Es reversible el script de eliminación de usuarios macOS? · ¿Dónde puedo encontrar el script de eliminación de usuarios macOS? · ¿Qué ocurre si no se encuentra el directorio home del usuario? Key topics: gestión de dispositivos, automatización, scripting, Applivery, MDM, Administradores TI Eliminar correctamente una cuenta de usuario en macOS implica más que hacer clic en "Eliminar usuario" en Ajustes del sistema. Ese enfoque puede dejar datos del directorio home, registros de Directory Services y entradas de grupo huérfanas que se acumulan con el tiempo. Este script va más allá: elimina el registro de usuario de Directory Services, borra el directorio home del disco (`/Users/username`) y limpia la entrada de grupo asociada — una eliminación completa e irreversible que no deja datos residuales en el equipo. Está diseñado para flujos de trabajo de baja de empleados donde importa empezar desde cero. :::warning El agente de Applivery para macOS debe estar instalado y activo en el dispositivo. Obtén más información sobre el [agente macOS](https://docs.applivery.com/es/device-management/apple/apple-policies/agent/#app-agente-para-dispositivos-macos). ::: ### Requisitos | Requisito | Detalle | | --- | --- | | Plataforma | macOS | | Privilegios de ejecución | Root (predeterminado en Applivery) | | Nombre de usuario | El nombre corto de la cuenta a eliminar, pasado como argumento | :::warning Esta acción es irreversible. Una vez eliminado el directorio home, los datos del usuario no pueden recuperarse a menos que exista una copia de seguridad. Verifica siempre el nombre de usuario antes de desplegar. ::: * * * ### Configuración **Crear el script** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), sigue los pasos descritos [aquí](https://docs.applivery.com/es/device-management/apple/macos/scripts/index) para crear un script. Pega el siguiente script en el editor, selecciona **Bash** como lenguaje, dale un nombre descriptivo (por ejemplo, `Eliminar cuenta de usuario local`) y haz clic en **Crear**. ```bash #!/bin/bash ## --- ## Title: Delete Local User & Home Directory ## Description: Completely removes a local user account, its home directory, and its group record. ## Author: Applivery ## Version: 1.0.0 ## --- ## ========================================== ## CONFIGURATION ## ========================================== ## The username can be passed as an argument ($1) or hardcoded below USER_NAME=$1 ## ========================================== ## 1. INITIAL CHECKS ## ========================================== if [[ $EUID -ne 0 ]]; then echo "Error: This script must be run as root." exit 1 fi if [ -z "$USER_NAME" ]; then echo "Error: No username provided. Usage: $0 " exit 1 fi CURRENT_USER=$(stat -f "%Su" /dev/console) if [ "$USER_NAME" == "$CURRENT_USER" ]; then echo "Error: Cannot delete the currently logged-in user ($USER_NAME)." exit 1 fi id "$USER_NAME" &>/dev/null if [ $? -ne 0 ]; then echo "Error: User '$USER_NAME' does not exist." exit 1 fi ## ========================================== ## 2. DELETION PROCESS ## ========================================== echo "Starting deletion process for user: $USER_NAME..." dscl . -delete "/Users/$USER_NAME" if [ $? -eq 0 ]; then echo "[SUCCESS] User record removed from Directory Services." else echo "[FAILURE] Failed to remove user record." exit 1 fi if [ -d "/Users/$USER_NAME" ]; then rm -rf "/Users/$USER_NAME" echo "[SUCCESS] Home directory /Users/$USER_NAME has been deleted." else echo "[INFO] No home directory found at /Users/$USER_NAME." fi dscl . -delete "/Groups/$USER_NAME" &>/dev/null echo "Process complete. User '$USER_NAME' has been fully removed." exit 0 ``` **Asignar el script a un dispositivo** Ahora, navega a cualquiera de tus **Dispositivos**, selecciona la pestaña **Scripts**, haz clic en el botón **\+ Asignar Script** y selecciona el que acabas de crear. :::info También puedes asignar scripts a Políticas. Para ello, navega a la sección **Políticas**, selecciona la política deseada y haz clic en la pestaña **Scripts**. El proceso será el mismo que al asignarlo directamente a un dispositivo individual. ::: **Elegir el método de ejecución** Selecciona el método de ejecución que se adapte a tu caso de uso: | Método | Comportamiento | ¿Recomendado? | | --- | --- | --- | | **Once** | Se ejecuta una vez por dispositivo cuando se asigna la política. | ✅ Recomendado — la eliminación de cuenta es una acción de baja puntual. | | **Loop** | Se ejecuta repetidamente en el intervalo configurado (15m, 1h, 6h, 1d, 7d). | ❌ No recomendado — la eliminación es irreversible y no debe repetirse. | | **On demand** | Solo se ejecuta cuando se activa manualmente desde la app de Self-Service de Applivery o el panel. | ✅ También adecuado para bajas puntuales iniciadas por TI. | **Introducir el nombre de usuario como argumento** El script requiere el nombre corto de la cuenta a eliminar. Introdúcelo en el campo **Argumentos** (por ejemplo, `jsmith`). El campo también admite [interpolaciones de variables](https://docs.applivery.com/es/device-management/general-settings/dynamic-variables/), como `{{device.displayName}}`. Haz clic en **Añadir** para guardar la asignación. :::tip Como alternativa al campo Argumentos, puedes introducir el nombre de usuario directamente en el script reemplazando `USER_NAME=$1` con `USER_NAME="el_nombre_usuario"`. Esto es útil cuando necesitas eliminar la misma cuenta en toda una flota de dispositivos. ::: * * * ### Disponible en GitHub Este script es parte del [Repositorio público de scripts de Applivery](https://github.com/applivery/applivery-mdm-scripts/tree/main/Apple/Delete%20Admin%20User) — una colección de scripts macOS listos para usar para tareas comunes de gestión TI. Puedes usarlo tal cual o adaptarlo a tu flujo de trabajo específico de baja de empleados. --- ## Forzar reinicio Source: https://docs.applivery.com/es/device-management/apple/macos/scripts/force-reboot/ Description: Script macOS que monitoriza el tiempo de actividad y escala alertas con swiftDialog para forzar reinicios, con una cuenta regresiva de 10 minutos forzada tras 13 o más días sin reiniciar. TL;DR: Automatiza tareas repetitivas en dispositivos gestionados usando scripts en Applivery para una gestión de dispositivos eficiente. Answers: ¿Por qué es importante reiniciar periódicamente los dispositivos macOS? · ¿Cómo funciona el script de política de reinicio forzado? · ¿Qué ocurre si un dispositivo macOS lleva 9-12 días sin reiniciar? · ¿Qué ocurre cuando un dispositivo macOS lleva 13 o más días en funcionamiento? · ¿Se requiere un logotipo corporativo para el script de política de reinicio forzado? · ¿Qué versión de macOS se requiere para ejecutar el script de política de reinicio forzado? · ¿Con qué frecuencia debe ejecutarse el script de política de reinicio forzado? · ¿Qué es swiftDialog y es obligatorio? Key topics: gestión de dispositivos, automatización, scripting, Applivery, MDM, Administradores TI Los parches de seguridad solo surten efecto después de un reinicio. En la práctica, los usuarios posponen los reinicios indefinidamente — y cuanto más tiempo lleva un dispositivo sin reiniciar, más actualizaciones de seguridad se acumulan en estado pendiente. Los equipos que llevan semanas encendidos también tienden a mostrar un rendimiento degradado y presión de memoria que un simple reinicio resolvería. El problema de forzar un reinicio con un apagado abrupto es que causa interrupciones y frustración. Este script adopta un enfoque más gradual: monitoriza el tiempo de actividad y escala progresivamente, comenzando con una notificación discreta y solo forzando una cuenta regresiva cuando el dispositivo lleva 13 o más días en funcionamiento. Los usuarios tienen tiempo suficiente para guardar su trabajo; TI tiene la garantía de que los reinicios realmente ocurren. Las alertas se muestran usando swiftDialog (instalado automáticamente si no está presente) con la marca de tu empresa, para que los usuarios las reconozcan como comunicaciones TI legítimas. :::warning El agente de Applivery para macOS debe estar instalado y activo en el dispositivo. Obtén más información sobre el [agente macOS](https://docs.applivery.com/es/device-management/apple/apple-policies/agent/#app-agente-para-dispositivos-macos). ::: ### Requisitos | Requisito | Detalle | |---|---| | Plataforma | macOS 11.0 (Big Sur) o posterior | | Privilegios de ejecución | Root (predeterminado en Applivery) | | Marca corporativa | `/var/root/CompanyAssets/logo.png` (opcional, para diálogos con marca) | | swiftDialog | Se instala automáticamente si no está presente | --- ### Niveles de escalada El script calcula el tiempo de actividad actual del sistema en días y aplica una política de escalada de cuatro niveles: | Tiempo de actividad | Acción | |---|---| | 0–4 días | Sin acción | | 5–8 días | Notificación de macOS con alerta sonora | | 9–12 días | Ventana de diálogo con opciones **Reiniciar ahora** y **Posponer** (24h). Se cierra automáticamente después de 14 minutos | | 13+ días | Advertencia a pantalla completa seguida de una cuenta regresiva de 10 minutos. El Mac se reinicia cuando llega a cero, o el usuario hace clic en **Reiniciar ahora** | --- ### Configuración **Desplegar el logotipo corporativo (opcional)** Antes de desplegar este script, asegúrate de que tu logotipo corporativo esté disponible en `/var/root/CompanyAssets/logo.png` en cada dispositivo gestionado. El script redimensiona y copia el logotipo a la carpeta de recursos de swiftDialog automáticamente. Usar el logotipo corporativo garantiza que los usuarios reconozcan las alertas como comunicaciones TI y no las descarten como ruido. Puedes distribuir el archivo usando la [gestión de archivos de Applivery](https://docs.applivery.com/es/device-management/apple/macos/policies/file-management/). **Crear el script** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), sigue los pasos descritos [aquí](https://docs.applivery.com/es/device-management/apple/macos/scripts/index) para crear un script. Pega el siguiente script en el editor, selecciona **Bash** como lenguaje, dale un nombre descriptivo (por ejemplo, `Política de reinicio forzado`) y haz clic en **Crear**. ```bash #!/bin/bash ## --- ## Title: Force Reboot Policy (Uptime Enforcement) ## Description: Monitors macOS uptime and triggers escalating alerts via swiftDialog to force a restart. ## Author: Applivery ## Version: 1.2.0 ## --- ## ========================================== ## 1. CLEANUP OLD INSTALLATIONS ## ========================================== DIALOG_OLD="/Applications/Dialog.app" if [ -d "$DIALOG_OLD" ]; then echo "→ Old Dialog.app found" pgrep -if "Dialog.app" && { echo " → Quitting Dialog..." pkill -if "Dialog.app" 2>/dev/null sleep 1 } if sudo rm -rf "$DIALOG_OLD" 2>/dev/null; then echo " → Removed successfully" else echo " → Failed to remove legacy app." fi else echo "→ No old Dialog.app present" fi ## ========================================== ## 2. PRE-FLIGHT & BRANDING SETUP ## ========================================== PATH=/usr/bin:/bin:/usr/sbin:/sbin DIALOG_CLI="/usr/local/bin/dialog" DIALOG_APP="/Library/Application Support/Dialog/Dialog.app" DIALOG_ICON_DIR="/Library/Application Support/Dialog" DIALOG_ICON="$DIALOG_ICON_DIR/Dialog.png" BRAND_ICON="/var/root/CompanyAssets/logo.png" needs_install=0 needs_reinstall=0 CURRENT_USER=$(stat -f %Su /dev/console) USER_ID=$(id -u "$CURRENT_USER" 2>/dev/null || true) ## [... resto del script de instalación de swiftDialog y cálculo de tiempo de actividad ...] ## ========================================== ## 4. UPTIME CALCULATION ## ========================================== current_unix_time="$(date '+%s')" boot_time_unix="$(sysctl -n kern.boottime | awk -F 'sec = |, usec' '{ print $2; exit }')" uptime_seconds="$(( current_unix_time - boot_time_unix ))" uptime_days="$(( uptime_seconds / 86400 ))" ## TEST_UPTIME_DAYS="7" # Uncomment for testing ## ========================================== ## 5. ESCALATION LOGIC ## ========================================== if [ "$uptime_days" -le 4 ]; then echo "Uptime: $uptime_days days. No action needed." exit 0 elif [ "$uptime_days" -ge 5 ] && [ "$uptime_days" -le 8 ]; then echo "Uptime: $uptime_days days. Showing Notification." run_as_user "$DIALOG_CLI" --notification \ --title "$uptime_days days without a reboot!" \ --message "Your Mac needs to restart to regain performance and apply security updates." afplay "/System/Library/Sounds/Sosumi.aiff" exit 0 elif [ "$uptime_days" -ge 9 ] && [ "$uptime_days" -le 12 ]; then echo "Uptime: $uptime_days days. Showing Dialog with Postpone." run_as_user "$DIALOG_CLI" \ --title "Restart Required" \ --message "*${uptime_days} days without a reboot!* \n\nPlease save your work and restart." \ --button1text "Restart now" \ --button2text "Postpone" \ --timer 840 --width 650 --height 280 --position bottomright --ontop dialog_results=$? elif [ "$uptime_days" -ge 13 ]; then echo "Uptime: $uptime_days days. Final warning." run_as_user "$DIALOG_CLI" \ --title "Restart Required" \ --message "*${uptime_days} days without a reboot!* \n\n*After pressing I Understand, you will have 10 minutes to save your work.*" \ --button1text "I Understand" --width 650 --height 230 --blurscreen --ontop run_as_user "$DIALOG_CLI" \ --title none --message "Computer will restart when the timer reaches zero." \ --button1text "Restart now" --timer 600 --width 320 --height 110 --position bottomright --icon none --ontop dialog_results=$? fi ## ========================================== ## 6. REBOOT EXECUTION ## ========================================== if [ "$dialog_results" = "0" ] || [ "$dialog_results" = "4" ]; then echo "Rebooting now..." shutdown -r now sleep 2 reboot elif [ "$dialog_results" = "2" ]; then echo "User postponed the restart." fi exit 0 ``` **Asignar el script a un dispositivo** Ahora, navega a cualquiera de tus **Dispositivos**, selecciona la pestaña **Scripts**, haz clic en el botón **\+ Asignar Script** y selecciona el que acabas de crear. :::info También puedes asignar scripts a Políticas. Para ello, navega a la sección **Políticas**, selecciona la política deseada y haz clic en la pestaña **Scripts**. El proceso será el mismo que al asignarlo directamente a un dispositivo individual. ::: **Elegir el método de ejecución** | Método | Comportamiento | ¿Recomendado? | |---|---|---| | **Once** | Se ejecuta una vez por dispositivo. | ❌ No adecuado — este script necesita ejecutarse continuamente para monitorizar el tiempo de actividad. | | **Loop** | Se ejecuta repetidamente en el intervalo configurado (15m, 1h, 6h, 1d, 7d). | ✅ Recomendado — selecciona el intervalo diario (`1d`) para comprobar el tiempo de actividad cada 24 horas y escalar las alertas progresivamente. | | **On demand** | Solo se ejecuta cuando se activa manualmente. | ❌ No adecuado para la aplicación automática del tiempo de actividad. | Este script no requiere ningún argumento. El tiempo de actividad del sistema se calcula automáticamente en tiempo de ejecución. Haz clic en **Añadir** para guardar la asignación. --- ### Qué verán los usuarios **Nivel 2 — Notificación (días 5–8):** Aparece una notificación de macOS no intrusiva en la esquina superior derecha con una alerta sonora. El usuario puede descartarla y continuar trabajando. **Nivel 3 — Diálogo con opción de posponer (días 9–12):** Aparece una ventana de diálogo en la esquina inferior derecha. El usuario puede hacer clic en **Reiniciar ahora** o **Posponer**. El diálogo se cierra automáticamente después de 14 minutos. **Nivel 4 — Cuenta regresiva forzada (día 13+):** Primero aparece una advertencia a pantalla completa desenfocada. Después de que el usuario la confirme, comienza una cuenta regresiva de 10 minutos en la esquina inferior derecha. Cuando llega a cero — o el usuario hace clic en **Reiniciar ahora** — el Mac se reinicia. --- ### Probar el script Para probar un nivel de escalada específico sin esperar el tiempo de actividad real, descomenta la línea `TEST_UPTIME_DAYS` en el script y establécela en el número de días deseado: ```bash TEST_UPTIME_DAYS="7" # Uncomment for testing ``` Recuerda comentarlo de nuevo antes de desplegarlo en producción. --- ### Disponible en GitHub Este script es parte del [Repositorio público de scripts de Applivery](https://github.com/applivery/applivery-mdm-scripts/tree/main/Apple/Force%20Reboot%20Policy). Un dispositivo sin reiniciar es un parche sin efecto — esta política de escalada progresiva mantiene tu flota actualizada sin interrumpir a nadie. --- ## Restringir permisos de administrador (mínimo privilegio) Source: https://docs.applivery.com/es/device-management/apple/macos/scripts/restrict-admin-rights/ Description: Script macOS que rebaja todas las cuentas de administrador local a usuario estándar excepto una cuenta TI protegida, aplicando el mínimo privilegio en toda tu flota. TL;DR: Automatiza tareas repetitivas en dispositivos gestionados usando scripts en Applivery para una gestión de dispositivos eficiente. Answers: ¿Qué hace el script "Restringir derechos de administrador"? · ¿Cuál es el requisito principal para ejecutar el script "Restringir derechos de administrador"? · ¿Cómo especifico qué cuenta de usuario debe conservar los derechos de administrador? · ¿Qué ocurre si el EXCLUDE_USER especificado no existe o no es administrador? · ¿Cuáles son los métodos de ejecución recomendados para el script "Restringir derechos de administrador"? · ¿En qué orden debo ejecutar los scripts al inscribir un nuevo dispositivo? · ¿Dónde puedo encontrar el script "Restringir derechos de administrador"? · ¿Requiere el script "Restringir derechos de administrador" algún argumento? Key topics: gestión de dispositivos, automatización, scripting, Applivery, MDM, Administradores TI En la mayoría de los entornos corporativos, los privilegios de administrador se conceden durante la configuración inicial del dispositivo y nunca se revocan. Con el tiempo — nuevas contrataciones, reinscripciones e instalaciones de software — los usuarios acumulan privilegios que ya no necesitan. Esos privilegios se convierten en una superficie de ataque: instalaciones de software no autorizadas, controles de seguridad de endpoints eludidos, cambios accidentales en la configuración del sistema. Este script aplica una base de mínimo privilegio en toda tu flota macOS. Rebaja automáticamente todas las cuentas de usuario locales a usuario estándar — excepto una cuenta TI de gestión designada que conserva sus privilegios de administrador. El script es seguro para ejecutar silenciosamente en todos los dispositivos y está diseñado para ser idempotente: ejecutarlo varias veces siempre produce el mismo resultado. :::warning El agente de Applivery para macOS debe estar instalado y activo en el dispositivo. Obtén más información sobre el [agente macOS](https://docs.applivery.com/es/device-management/apple/apple-policies/agent/#app-agente-para-dispositivos-macos). ::: ### Requisitos | Requisito | Detalle | |---|---| | Plataforma | macOS | | Privilegios de ejecución | Root (predeterminado en Applivery) | | Cuenta protegida | Una cuenta de administrador local debe existir en el dispositivo antes de ejecutar este script | :::warning Antes de desplegar este script, asegúrate de que la cuenta de gestión protegida (`EXCLUDE_USER`) existe en el dispositivo y ya tiene privilegios de administrador. Si no existe o no es administrador, el script se abortará como medida de seguridad para evitar bloquear el acceso al sistema. ::: --- ### Configuración **Crear el script** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), sigue los pasos descritos [aquí](https://docs.applivery.com/es/device-management/apple/macos/scripts/index) para crear un script. Pega el siguiente script en el editor. Antes de guardar, establece la variable `EXCLUDE_USER` con el nombre corto de tu cuenta TI de gestión. | Variable | Descripción | Valor predeterminado | |---|---|---| | `EXCLUDE_USER` | El nombre de usuario que debe conservar los derechos de administrador | `admin` | Selecciona **Bash** como lenguaje, dale un nombre descriptivo (por ejemplo, `Restringir derechos de administrador`) y haz clic en **Crear**. ```bash #!/bin/bash ## --- ## Title: Demote all local admins to standard (except EXCLUDE_USER) ## Description: Ensures only a specific local account has administrator privileges. ## Author: Applivery ## Version: 1.0.0 ## --- ## ======== CONFIGURATION ======== EXCLUDE_USER="admin" ADMIN_GROUP="admin" ## ======== FUNCTIONS ======== is_admin() { local user="$1" dseditgroup -o checkmember -m "$user" "$ADMIN_GROUP" &>/dev/null return $? } ## ======== INITIAL CHECKS ======== if [[ $EUID -ne 0 ]]; then echo "Error: This script must be run with sudo" exit 1 fi if ! id "$EXCLUDE_USER" &>/dev/null; then echo "Error: User '$EXCLUDE_USER' does not exist on this system." exit 1 fi if ! is_admin "$EXCLUDE_USER"; then echo "WARNING: '$EXCLUDE_USER' is NOT an administrator. Aborting for safety." exit 1 fi ## ======== GET HUMAN USERS ======== users=$(dscl . list /Users | grep -v '^_' | while read -r user; do uid=$(dscl . read "/Users/$user" UniqueID | awk '{print $2}') if [[ "$uid" =~ ^[0-9]+$ && "$uid" -ge 501 ]]; then echo "$user" fi done) ## ======== PROCESS EACH USER ======== echo "Processing local users..." echo "──────────────────────────────────────────────" count_changed=0 count_skipped=0 while IFS= read -r username; do [[ -z "$username" ]] && continue if [[ "$username" == "$EXCLUDE_USER" ]]; then echo "[SKIP] $username (intentionally excluded)" ((count_skipped++)) continue fi if ! is_admin "$username"; then echo "[OK] $username → already standard (non-admin)" continue fi echo -n "[PROC] $username → removing admin rights... " if dseditgroup -o edit -d "$username" -t user "$ADMIN_GROUP" 2>/dev/null; then echo "SUCCESS" ((count_changed++)) else echo "FAILED" echo " → Could not remove admin rights (directory service issue?)" fi done <<< "$users" echo "──────────────────────────────────────────────" echo "Summary:" echo " Users processed : $(echo "$users" | wc -l | xargs)" echo " Demoted to standard : $count_changed" echo " Skipped (excluded) : $count_skipped" echo "" echo "Protected user (should remain admin): $EXCLUDE_USER" if is_admin "$EXCLUDE_USER"; then echo "✓ User '$EXCLUDE_USER' still has administrator privileges." else echo "⚠ ATTENTION: '$EXCLUDE_USER' is NO LONGER an administrator." echo " Restore admin rights manually:" echo " sudo dseditgroup -o edit -a \"$EXCLUDE_USER\" -t user admin" fi exit 0 ``` **Asignar el script a un dispositivo** Ahora, navega a cualquiera de tus **Dispositivos**, selecciona la pestaña **Scripts**, haz clic en el botón **\+ Asignar Script** y selecciona el que acabas de crear. :::info También puedes asignar scripts a Políticas. Para ello, navega a la sección **Políticas**, selecciona la política deseada y haz clic en la pestaña **Scripts**. El proceso será el mismo que al asignarlo directamente a un dispositivo individual. ::: **Elegir el método de ejecución** | Método | Comportamiento | ¿Recomendado? | |---|---|---| | **Once** | Se ejecuta una vez por dispositivo. | ✅ Adecuado para una remediación puntual en una flota existente. | | **Loop** | Se ejecuta repetidamente en el intervalo configurado (15m, 1h, 6h, 1d, 7d). | ✅ Recomendado para una aplicación continua — detecta nuevas cuentas de administrador a medida que aparecen. | | **On demand** | Solo se ejecuta cuando se activa manualmente. | ✅ Útil para auditorías puntuales iniciadas por TI. | La configuración recomendada es **Loop** con un intervalo diario o semanal para detectar y rebajar continuamente cualquier nueva cuenta de administrador. Usa **Once** para una remediación puntual en una flota existente. Este script no requiere ningún argumento. La cuenta protegida se configura directamente en la variable `EXCLUDE_USER` dentro del script. Haz clic en **Añadir** para guardar la asignación. --- ### Orden de despliegue recomendado Al inscribir un nuevo dispositivo, la secuencia recomendada es: 1. El dispositivo se inscribe en Applivery. 2. El script [Crear usuario administrador oculto](https://github.com/applivery/applivery-mdm-scripts) se ejecuta para crear la cuenta TI de gestión. 3. Este script se ejecuta para rebajar todos los demás usuarios locales a usuario estándar. Esto garantiza que TI siempre conserve el acceso de gestión mientras los usuarios finales no pueden realizar cambios no autorizados en el sistema. :::tip Ejecuta este script combinado con el script Crear usuario administrador oculto para garantizar que la cuenta de gestión siempre existe antes de aplicar la restricción. ::: --- ### Disponible en GitHub Este script es parte del [Repositorio público de scripts de Applivery](https://github.com/applivery/applivery-mdm-scripts/tree/main/Apple/Restrict%20Admin%20Rights). El mínimo privilegio es la primera línea de defensa — este script aplica esa política en toda tu flota en segundos. --- ## Sincronizar nombre del dispositivo Source: https://docs.applivery.com/es/device-management/apple/macos/scripts/sync-device-name/ Description: Script macOS que lee el ComputerName local y actualiza el nombre de visualización del dispositivo en el panel de Applivery mediante la API, manteniendo sincronizados todos los nombres de dispositivos. TL;DR: Automatiza tareas repetitivas en dispositivos gestionados usando scripts en Applivery para una gestión de dispositivos eficiente. Answers: ¿Qué hace este script? · ¿Por qué debería sincronizar el nombre del ordenador macOS con Applivery? · ¿Cuáles son los requisitos para ejecutar este script? · ¿Cómo obtengo el ID de organización de Applivery? · ¿Cómo obtengo un token Bearer para la API de Applivery? · ¿Cómo configuro el script después de crearlo en Applivery? · ¿Con qué frecuencia debería ejecutar este script? · ¿Dónde puedo encontrar el código fuente completo de este script? Key topics: gestión de dispositivos, automatización, scripting, Applivery, MDM, Administradores TI Cada Mac tiene un nombre de ordenador local — el que el usuario estableció durante la configuración inicial, o que cambió más tarde por algo personal como "MacBook de Juan". En el panel de Applivery, sin embargo, los dispositivos suelen mostrar el nombre genérico asignado en el momento de la inscripción. A escala, esto hace que identificar máquinas específicas por nombre sea casi imposible: acabas con una lista de entradas `MacBook-Pro-7` sin forma fácil de saber a quién pertenece cada una. Este script cierra esa brecha. Lee el `ComputerName` local de cada Mac y lo actualiza en el panel de Applivery mediante la API, manteniendo ambos sincronizados. Ejecútalo periódicamente y podrás identificar siempre cualquier dispositivo de un vistazo. :::warning El agente de Applivery para macOS debe estar instalado y activo en el dispositivo. Obtén más información sobre el [agente macOS](https://docs.applivery.com/es/device-management/apple/apple-policies/agent/#app-agente-para-dispositivos-macos). ::: ### Requisitos | Requisito | Detalle | | --- | --- | | Plataforma | macOS | | Privilegios de ejecución | Root (predeterminado en Applivery) | | Acceso a internet | El dispositivo debe poder acceder a `api.applivery.io` | | Token Bearer | Un token válido de una cuenta de servicio con rol de Editor o superior | | ID de organización | El slug/ID de tu organización de Applivery | * * * ### Antes de empezar — Obtén tu token Bearer y tu ID de organización **ID de organización** — Tu ID de organización es el slug visible en la URL del panel de Applivery (por ejemplo, `mi-empresa`). **Token Bearer (mediante cuenta de servicio)** — Applivery usa [cuentas de servicio](https://docs.applivery.com/es/platform/api/service-accounts/) para representar usuarios no humanos que pueden acceder a la API de administración de Applivery. Cada cuenta de servicio tiene un token Bearer asociado que se usa como cabecera `Authorization` en las llamadas a la API. * * * ### Configuración **Crear el script** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), sigue los pasos descritos [aquí](https://docs.applivery.com/es/device-management/apple/macos/scripts/index) para crear un script. Pega el siguiente script en el editor, reemplazando los valores de marcador de posición que se muestran en la tabla a continuación. | Variable | Descripción | Ejemplo | | --- | --- | --- | | `ID_ORG` | Tu slug/ID de organización de Applivery | `mi-empresa` | | `API_TOKEN` | Token Bearer de una cuenta de servicio con rol de Editor o superior | `wfkj2Gi...` | Selecciona **Bash** como lenguaje, dale un nombre descriptivo (por ejemplo, `Sincronizar nombre del dispositivo`) y haz clic en **Crear**. ```bash #!/bin/bash ## --- ## Title: Sync Device Name with Applivery API ## Description: Automatically updates the Device Display Name in Applivery Dashboard to match the local macOS ComputerName. ## Author: Applivery ## Version: 1.0.0 ## --- ## ========================================== ## CONFIGURATION ## ========================================== ID_ORG="your-org-id" API_TOKEN="your-api-token" BASE_URL="https://api.applivery.io/v1/organizations/$ID_ORG/mdm/apple/enterprise/devices" ## ========================================== ## 1. LOCAL DATA GATHERING ## ========================================== SERIAL_NUMBER=$(system_profiler SPHardwareDataType | grep "Serial Number" | awk '{print $4}') NEW_DEVICE_NAME=$(scutil --get ComputerName) if [ -z "$NEW_DEVICE_NAME" ]; then echo "Error: Local ComputerName is empty. Please set a hostname on the Mac." exit 1 fi echo "Syncing Device Name for Serial: $SERIAL_NUMBER" echo "Target Name: $NEW_DEVICE_NAME" ## ========================================== ## 2. API INTERACTION ## ========================================== ## GET Device Info to find the internal Device ID response=$(curl -s -X GET "$BASE_URL/$SERIAL_NUMBER" \ -H "Authorization: Bearer $API_TOKEN" \ -H "Content-Type: application/json") if echo "$response" | grep -q '"admDevice"'; then DEVICE_ID=$(echo "$response" | grep -o '"admDevice":"[^"]*"' | sed 's/"admDevice":"\([^"]*\)"/\1/') if [ -n "$DEVICE_ID" ]; then echo "Found internal DeviceID: $DEVICE_ID" update_response=$(curl -s -X PUT "$BASE_URL/$DEVICE_ID" \ -H "Authorization: Bearer $API_TOKEN" \ -H "Content-Type: application/json" \ -d "{\"displayName\": \"$NEW_DEVICE_NAME\"}") if echo "$update_response" | grep -q '"status":200' || echo "$update_response" | grep -q '"displayName"'; then echo "SUCCESS: Display name updated to: $NEW_DEVICE_NAME" else echo "FAILURE: Error updating name: $update_response" fi else echo "ERROR: Could not find DeviceID for Serial Number $SERIAL_NUMBER" fi else echo "ERROR: Could not fetch device info from API. Check Token and Org ID." echo "Response: $response" fi exit 0 ``` **Asignar el script a un dispositivo** Ahora, navega a cualquiera de tus **Dispositivos**, selecciona la pestaña **Scripts**, haz clic en el botón **\+ Asignar Script** y selecciona el que acabas de crear. :::info También puedes asignar scripts a Políticas. Para ello, navega a la sección **Políticas**, selecciona la política deseada y haz clic en la pestaña **Scripts**. El proceso será el mismo que al asignarlo directamente a un dispositivo individual. ::: **Elegir el método de ejecución** | Método | Comportamiento | ¿Recomendado? | | --- | --- | --- | | **Once** | Se ejecuta una vez por dispositivo. | ✅ Útil para establecer el nombre de visualización desde el primer día de inscripción. | | **Loop** | Se ejecuta repetidamente en el intervalo configurado (15m, 1h, 6h, 1d, 7d). | ✅ Recomendado para sincronización continua — mantiene el panel actualizado a medida que los usuarios renombran sus equipos. | | **On demand** | Solo se ejecuta cuando se activa manualmente. | ✅ Útil para una actualización puntual activada por TI. | La configuración recomendada es usar **Loop** con un intervalo semanal (`7d`) para mantener el panel sincronizado sin generar tráfico API innecesario, combinado con **Once** durante la inscripción para establecer el nombre desde el primer día. Este script no requiere ningún argumento. El nombre del dispositivo y el número de serie se obtienen automáticamente del sistema local. Haz clic en **Añadir** para guardar la asignación. * * * ### Disponible en GitHub Este script es parte del [Repositorio público de scripts de Applivery](https://github.com/applivery/applivery-mdm-scripts/tree/main/Apple/Sync%20Device%20Name%20%28API%29). El código fuente completo está disponible allí para revisión, adaptación y contribución. --- ## Permisos de administrador temporales (elevación JIT) Source: https://docs.applivery.com/es/device-management/apple/macos/scripts/temporary-admin-rights/ Description: Script bash macOS que concede privilegios de administrador temporales durante 3 minutos a usuarios estándar mediante elevación JIT, con registro de motivo y revocación automática de privilegios. TL;DR: Automatiza tareas repetitivas en dispositivos gestionados usando scripts en Applivery para una gestión de dispositivos eficiente. Answers: ¿Qué hace el script de derechos de administrador temporales? · ¿Cómo solicitan los usuarios derechos de administrador temporales? · ¿Cuánto tiempo duran los derechos de administrador temporales por defecto? · ¿Puedo personalizar la duración de los derechos de administrador temporales? · ¿Cuáles son los requisitos para usar el script de derechos de administrador temporales? · ¿Cómo despliego el logotipo corporativo en la ventana de elevación? · ¿Cómo asigno el script a los usuarios? · ¿Dónde puedo encontrar el script de derechos de administrador temporales? Key topics: gestión de dispositivos, automatización, scripting, Applivery, MDM, Administradores TI El principio de mínimo privilegio es el valor predeterminado correcto — pero hay momentos en que un usuario estándar necesita legítimamente realizar una tarea de administrador: instalar software aprobado, cambiar un ajuste de red, ejecutar una herramienta de diagnóstico. La solución incorrecta es conceder privilegios de administrador permanentes. La solución correcta es dar a los usuarios exactamente lo que necesitan, durante exactamente el tiempo que lo necesitan, y revocarlo automáticamente. Este script implementa elevación Justo-a-Tiempo (JIT): el usuario lo activa desde el Self-Service de Applivery, un diálogo con marca corporativa solicita un motivo y, si el usuario confirma, recibe privilegios de administrador durante exactamente 3 minutos. Cuando expira el tiempo, el script revoca el acceso automáticamente y elimina todos sus rastros — sin LaunchDaemons residuales, sin archivos temporales. :::warning El agente de Applivery para macOS debe estar instalado y activo en el dispositivo. Obtén más información sobre el [agente macOS](https://docs.applivery.com/es/device-management/apple/apple-policies/agent/#app-agente-para-dispositivos-macos). ::: ### Requisitos | Requisito | Detalle | |---|---| | Plataforma | macOS | | Privilegios de ejecución | Root (predeterminado en Applivery) | | swiftDialog | Se instala automáticamente si no está presente | | Marca corporativa | `/var/root/CompanyAssets/logo.png` (opcional, para el diálogo con marca) | --- ### Configuración **Desplegar el logotipo corporativo (opcional)** Para una experiencia con marca corporativa, despliega tu logotipo en cada dispositivo gestionado antes de ejecutar este script. El archivo debe estar en `/var/root/CompanyAssets/logo.png`. Puedes distribuirlo usando la [gestión de archivos de Applivery](https://docs.applivery.com/es/device-management/apple/macos/policies/file-management/). Si el archivo no está presente, el diálogo usará el icono predeterminado de swiftDialog en su lugar. **Crear el script** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), sigue los pasos descritos [aquí](https://docs.applivery.com/es/device-management/apple/macos/scripts/index) para crear un script. Pega el siguiente script en el editor, selecciona **Bash** como lenguaje, dale un nombre descriptivo (por ejemplo, `Derechos de administrador temporales`) y haz clic en **Crear**. ```bash #!/bin/bash ## --- ## Title: Temporary Admin Rights (JIT Elevation) ## Description: Grants local admin privileges to a standard user for 3 minutes with mandatory reason logging. ## Author: Applivery ## Version: 1.1.0 ## --- ## ========================================== ## 1. PRE-FLIGHT & PREREQUISITES ## ========================================== if [ "$(id -u)" -ne 0 ]; then echo "ERROR: This script must be run with sudo." >&2 exit 1 fi ## [... instalación de swiftDialog y detección del usuario actual ...] currentUser=$(/bin/ls -l /dev/console | /usr/bin/awk '{ print $3 }') [ "$currentUser" = "loginwindow" ] && exit 0 if id -Gn "$currentUser" | grep -qw admin; then "$DIALOG_CLI" --title "Temporary Admin Rights" --message "You are already an administrator." --button1text "OK" --icon "$brandIconPath" --height 220 --width 480 exit 0 fi ## ========================================== ## 4. ELEVATION DIALOG ## ========================================== message="You are about to be granted administrator privileges for 3 minutes. Use them responsibly." dialogRaw=$("$DIALOG_CLI" \ --json \ --title "Temporary Admin Rights" \ --message "$message" \ --textfield "Reason,name=reason,prompt=\"Reason (optional)\"" \ --button1text "MAKE ME ADMIN" \ --button2text "CANCEL" \ --icon "$brandIconPath" \ --height 280 --width 720 2>&1) [ $? != 0 ] && exit 0 ## ========================================== ## 5. EXECUTION & AUTO-REVOKE ## ========================================== scriptDir="/Users/Shared/AdminTime" scriptFile="$scriptDir/admin_privileges.sh" launchDaemonFile="/Library/LaunchDaemons/com.applivery.adminprivileges.plist" mkdir -p "$scriptDir" cat << EOF > "$scriptFile" #!/bin/bash currentUser=\$(/bin/ls -l /dev/console | /usr/bin/awk '{ print \$3 }') dseditgroup -o edit -a "\$currentUser" -t user admin sleep 180 dseditgroup -o edit -d "\$currentUser" -t user admin rm -rf "$scriptDir" rm -f "$launchDaemonFile" EOF chmod +x "$scriptFile" ## [... crear LaunchDaemon y cargar ...] echo "Success: User $currentUser elevated for 3 minutes." ``` **Asignar el script como acción On-demand** Ahora, navega a cualquiera de tus **Dispositivos**, selecciona la pestaña **Scripts**, haz clic en el botón **\+ Asignar Script** y selecciona el que acabas de crear. :::info También puedes asignar scripts a Políticas. Para ello, navega a la sección **Políticas**, selecciona la política deseada y haz clic en la pestaña **Scripts**. El proceso será el mismo que al asignarlo directamente a un dispositivo individual. ::: Selecciona **On demand** como método de ejecución — esto hace que el script aparezca como acción en el Self-Service de Applivery que los usuarios pueden activar cuando necesiten acceso de administrador temporal. | Método | Comportamiento | ¿Recomendado? | |---|---|---| | **Once** | Se ejecuta una vez por dispositivo. | ❌ No adecuado — el script está diseñado para ser activado bajo demanda por el usuario. | | **Loop** | Se ejecuta automáticamente en un intervalo recurrente. | ❌ No recomendado — esto concedería privilegios de administrador automáticamente y repetidamente sin interacción del usuario. | | **On demand** | Solo se ejecuta cuando el usuario lo activa desde el Self-Service. | ✅ Recomendado — el usuario activa la elevación cuando la necesita. | Este script no requiere ningún argumento. El usuario activo se detecta automáticamente en tiempo de ejecución. Haz clic en **Añadir** para guardar la asignación. --- ### Qué verán los usuarios Una vez asignado como acción On-demand, el script aparece como un elemento en el Self-Service de Applivery. Cuando el usuario lo activa, se abre una ventana de diálogo con marca corporativa que muestra un mensaje sobre el límite de 3 minutos. El usuario introduce un motivo opcional y hace clic en **MAKE ME ADMIN** para confirmar, o en **CANCEL** para cancelar. Tras la confirmación, el usuario se añade al grupo `admin`. Después de 3 minutos, el script revoca los privilegios automáticamente y elimina el LaunchDaemon auxiliar y el script auxiliar del dispositivo, sin dejar rastro. ### Personalizar la ventana de elevación Por defecto, la elevación dura 3 minutos (180 segundos). Para cambiar esto, edita el valor `sleep 180` en el bloque de script auxiliar integrado: ```bash sleep 180 # Change this value (in seconds) to adjust the duration ``` Por ejemplo, `sleep 600` concedería 10 minutos de acceso de administrador. --- ### Disponible en GitHub Este script es parte del [Repositorio público de scripts de Applivery](https://github.com/applivery/applivery-mdm-scripts/tree/main/Apple/Temporary%20Admin%20Rights). Puedes usarlo tal cual o adaptar la marca, la duración y el contenido del diálogo a las necesidades de tu organización. --- ## Resolución de problemas Source: https://docs.applivery.com/es/device-management/apple/macos/troubleshooting/ Description: Resuelve problemas comunes de gestión de dispositivos macOS en Applivery — soluciona errores de inscripción, problemas de configuración y problemas de seguridad. TL;DR: Encuentra soluciones para problemas comunes de gestión de dispositivos macOS en Applivery. Answers: ¿Qué implica la resolución de problemas de gestión de dispositivos macOS en Applivery? · ¿Qué tipos de problemas cubre la resolución de problemas macOS de Applivery? · ¿Cómo ayuda esta guía con la gestión de dispositivos macOS? · ¿Cuáles son algunos problemas comunes de inscripción de dispositivos macOS en Applivery? · ¿Qué errores de configuración se abordan en la guía de resolución de problemas de Applivery? · ¿Qué problemas de conectividad cubre la resolución de problemas macOS de Applivery? Key topics: Resolución de problemas macOS, Applivery, Problemas de inscripción, Problemas de configuración, Conectividad, macOS Diagnostica y resuelve problemas comunes de gestión de dispositivos macOS en Applivery — incluyendo fallos de inscripción, problemas con perfiles MDM, errores de instalación de apps, conflictos de políticas y problemas de conectividad. Cada artículo explica la causa probable y los pasos para resolverlo, para que puedas volver a tener los dispositivos bajo gestión lo antes posible. --- ## Requisitos de código de apps Source: https://docs.applivery.com/es/device-management/apple/macos/troubleshooting/app-code-requirements/ Description: Recupera el requisito de código de una app macOS usando el comando codesign — necesario para configurar perfiles PPPC y preferencias de privacidad. TL;DR: Aprende a usar el comando `codesign` para recuperar el requisito de código de una app macOS, que es esencial para una configuración MDM segura. Answers: ¿Qué es un requisito de código? · ¿Por qué son importantes los requisitos de código? · ¿Cómo encuentro el requisito de código de una app en macOS? · ¿Dónde encuentro el requisito de código en la salida de `codesign`? · ¿Qué hace el comando `codesign`? · ¿Puedo usar los requisitos de código para proteger las preferencias de privacidad? · ¿Qué debo hacer antes de usar un script con requisitos de código en masa? Key topics: Requisitos de código, Seguridad de macOS, Configuración MDM, Comando codesign, macOS, MDM, codesign, Apple, Maps.app Un **requisito de código** es una restricción que debe cumplirse para que el código sea considerado válido para un propósito específico. Define las condiciones necesarias para que el sistema evalúe la firma del código y determine si puede considerarse seguro. Si el código no cumple estos requisitos durante la evaluación, la validación de la firma de código fallará. Puedes incluir el requisito de firma de código y el bundle ID de una app para permitir el acceso a los datos protegidos del usuario. Especificar el bundle ID y el requisito de código refuerza la seguridad del payload de preferencias de privacidad. Puedes recuperar el requisito de firma de código de la app ejecutando los comandos `codesign`. ### Encontrar el requisito de código de una app Para encontrar el requisito de código de una app instalada en el Mac, ejecuta el siguiente comando en el Terminal: ``` codesign -dr - "ruta/Bundle ID" ``` Por ejemplo: ``` codesign -dr - /System/Applications/Maps.app ``` Reemplaza `ruta/Bundle ID` con la ruta o el identificador de bundle de la app. Puedes encontrar el requisito de código empezando después del texto `designated =>`. Ejemplo de salida: ``` Executable=/System/Applications/Maps.app/Contents/MacOS/Maps designated => identifier "com.apple.Maps" and anchor apple ``` :::warning Es recomendable validar manualmente la ejecución del script en un sistema antes de realizar una acción masiva. ::: --- ## Forzar la reinscripción DEP Source: https://docs.applivery.com/es/device-management/apple/macos/troubleshooting/force-dep-enrollment/ Description: Activa la reinscripción Apple DEP en un Mac ya configurado — omite un restablecimiento de fábrica usando un comando de Terminal con Apple Business. TL;DR: Puedes activar la inscripción Apple DEP en un Mac ya configurado sin restablecimiento de fábrica añadiéndolo a Apple Business y ejecutando `sudo profiles renew -type enrollment` en el Terminal. Answers: ¿Cómo puedo inscribir un Mac en DEP si se configuró antes de Apple Business? · ¿Qué comando de Terminal activa la inscripción DEP en un Mac existente? · ¿Qué pasos de Apple Business se necesitan antes de ejecutar el comando de inscripción DEP? · ¿Funciona completamente la inscripción inteligente con este método de inscripción DEP? · ¿Qué ocurre después de ejecutar el comando `profiles renew` para la inscripción DEP? · ¿Es posible inscribir un Mac en DEP sin un restablecimiento de fábrica si perdió el check-in inicial? Key topics: Omisión de inscripción DEP, Inscripción MDM Mac, Integración de Apple Business, Comandos de Terminal para macOS, Evitar el restablecimiento de fábrica, Mac, Apple Business, DEP, Applivery, MDM, Terminal, Inscripción inteligente Cuando un Mac se enciende y pasa por la configuración inicial antes de añadirse a Apple Business, pierde el check-in DEP que normalmente ocurre en el primer arranque. En la mayoría de los casos, la solución estándar es un restablecimiento de fábrica — pero si necesitas evitar borrar el dispositivo, existe una alternativa. Añadiendo el Mac a Apple Business y ejecutando un único comando de Terminal, puedes activar la inscripción DEP en un dispositivo que ya está configurado. :::warning Este método activa la inscripción MDM, pero **la inscripción inteligente no se aplica completamente**. Las automatizaciones que se ejecutan en el primer arranque — como la creación automática de cuentas de administrador — no se ejecutarán. Configura esos ajustes manualmente después de la inscripción si es necesario. ::: **Añade el Mac a Apple Business** En [Apple Business](https://business.apple.com/), añade el dispositivo y asígnalo a Applivery como servidor MDM. Asegúrate de que hay un perfil DEP asignado al dispositivo en Applivery antes de continuar. Si necesitas ayuda con esto, consulta la [configuración DEP en Applivery](https://docs.applivery.com/es/device-management/apple/enrollment/dep/). **Ejecuta el comando de inscripción** En el Mac, abre el **Terminal** y ejecuta el siguiente comando: ```bash sudo profiles renew -type enrollment ``` Introduce la contraseña de administrador cuando se solicite. Esto activa el check-in DEP y envía el perfil de inscripción MDM al dispositivo. **Completa la inscripción** Aparecerá una solicitud del sistema pidiendo al usuario que permita la gestión del dispositivo. Sigue los pasos en pantalla para completar la inscripción. Una vez hecho, el dispositivo aparecerá en **Dispositivos** en el panel de Applivery. --- ## Firmar PKG Source: https://docs.applivery.com/es/device-management/apple/macos/troubleshooting/sign-macos-pkg/ Description: Firma paquetes PKG de macOS usando la línea de comandos o Xcode con un certificado Developer ID Installer para garantizar que las apps son de confianza y verificables. TL;DR: Firma tus paquetes PKG de macOS usando el comando `productsign` en el Terminal o automáticamente a través de Xcode con un certificado Developer ID Installer para una distribución segura. Answers: ¿Qué tipo de certificado se necesita para firmar paquetes macOS? · ¿Cómo obtengo un certificado Developer ID Installer? · ¿Cómo firmo un paquete macOS usando la línea de comandos? · ¿Dónde encuentro el nombre común de mi certificado para firmarlo? · ¿Cómo verifico que mi paquete macOS está firmado? · ¿Puede Xcode firmar automáticamente mi paquete macOS? · ¿Qué ajuste de certificado de firma debo usar en Xcode? · ¿Son aceptables los certificados de terceros para firmar paquetes macOS? Key topics: Firma de PKG macOS, Certificado Developer ID Installer, Firma con línea de comandos (productsign), Proceso de firma con Xcode, macOS, PKG, Xcode, Apple Developer, Terminal, Acceso a Llaveros Para firmar paquetes macOS, necesitarás un certificado apropiado, como un certificado TLS/SSL con uso de firma, que debe ser verificable en el cliente. Típicamente, se usa un certificado **Developer ID Installer** para este propósito, obtenido desde una cuenta de desarrollador de Apple. Sin embargo, los certificados de terceros que cumplen estos criterios también son aceptables. Si no tienes un certificado y tienes intención de usar una cuenta de desarrollador de Apple, puedes comenzar el proceso de registro en el sitio web de Apple. Si usas una cuenta de desarrollador de Apple, los certificados pueden generarse vinculando tu cuenta de desarrollador a Xcode y exportando el archivo de certificado desde Xcode. Alternativamente, puedes iniciar sesión en tu cuenta de desarrollador de Apple en línea y descargar el certificado a través de un navegador web. Al crear el certificado, asegúrate de que el tipo de certificado se designe como certificado Developer ID Installer y confirma que se guarda en tu Llavero de macOS. Una vez que obtienes tu certificado, hay varios métodos disponibles para firmar el PKG de macOS. ### Firma de PKGs con Terminal y línea de comandos En este ejemplo, deberás usar el comando `productsign`. **Abrir el Acceso a Llaveros** Primero, abre el **Acceso a Llaveros** en macOS y encuentra el certificado. Si usas un certificado de Apple, debería comenzar con **Developer ID Installer: …** seguido de tu nombre de cuenta de desarrollador de Apple, y terminar con un número de serie entre paréntesis. **Abrir el Terminal y ejecutar el comando** A continuación, abre el Terminal. El comando para firmar el paquete debería ser algo así: ```bash productsign --sign "Developer ID Installer: Your Developer Name (1A2B3C4D5E)" ~/Desktop/example.pkg ~/Desktop/signed-example.pkg ``` El texto entre comillas después de `--sign` debe ser el nombre común de tu certificado. El primer argumento (`~/Desktop/example.pkg`) indica la ubicación actual del paquete sin firmar en tu ordenador, mientras que el segundo argumento (`~/Desktop/signed-example.pkg`) es donde quieres guardar tu paquete firmado. **Verificar el paquete firmado** Una vez hecho, ejecuta el comando. Si funciona, deberías ver algo similar a lo siguiente impreso en el Terminal: ```bash productsign: using timestamp authority for signature productsign: signing product with identity "Developer ID Installer: Your Developer Name (1A2B3C4D5E)" from keychain /Users/sdeveloper/Library/Keychains/login.keychain-db productsign: adding certificate "Developer ID Certification Authority" productsign: adding certificate "Apple Root CA" productsign: Wrote signed product archive to /Users/sdeveloper/Downloads/munkitools_signed-3.2.0.3476.pkg ``` Verifica que el paquete firmado se encuentra en el destino que especificaste. ### Firma usando Xcode Supón que estás compilando tu PKG de macOS en Xcode y tu cuenta de desarrollador de Apple está vinculada. En ese caso, Xcode puede solicitar automáticamente un certificado desde tu cuenta de desarrollador e incluirlo en el certificado de firma del paquete durante las fases de compilación y archivo. Recomendamos consultar la [documentación de Apple](https://help.apple.com/xcode/mac/current/#/dev3a05256b8) para obtener instrucciones más detalladas. :::tip Asegúrate de elegir **Developer ID Installer** en la lista desplegable para el ajuste de **Certificado de firma** al usar este enfoque. Esta opción se puede encontrar en la sección Firma de la pestaña de Ajustes generales. ::: --- ## Renovar el certificado Push de Apple Source: https://docs.applivery.com/es/device-management/apple/renew-push-certificate/ Description: Renueva el certificado Push de Apple con la cuenta que lo creó, y averigua cuál era ese Apple ID cuando nadie lo recuerda. TL;DR: Renueva con el mismo Apple ID que creó el certificado. Otra cuenta significa perder el control de todos los dispositivos inscritos. Key topics: Renovar con el Apple ID original, Identificar una cuenta olvidada, Verificar que es el certificado correcto, Applivery, Apple, Certificado Push de Apple, Apple ID El certificado Push de Apple es lo que permite a Applivery comunicarse con tus dispositivos Apple. Caduca cada año y renovarlo es rutina, siempre que lo renueves con la cuenta que lo creó. :::warning **El certificado debe renovarse con el mismo Apple ID con el que se creó.** Iniciar sesión con otra cuenta no renueva tu certificado: crea uno distinto. El original caduca, Applivery deja de poder gestionar tus dispositivos inscritos, y recuperarlos implica reinscribir toda la flota. ::: Para la configuración inicial, consulta [Primeros pasos](https://docs.applivery.com/es/device-management/apple/get-started/). ### Averiguar con qué Apple ID se creó **Si se rellenó el campo Apple ID durante la configuración**, la cuenta está registrada en tu workspace, en **Ajustes → Configuración de Apple**. Para eso existe el campo. **Si se dejó vacío**, Applivery no tiene constancia. La cuenta solo existe del lado de Apple, así que hay que identificarla desde fuera de la plataforma: - **Correos antiguos de Apple.** Los recibos, los avisos de renovación y las alertas de caducidad llegan a la cuenta propietaria del certificado. Busca también en los buzones compartidos, no solo en los personales. - **Quien configurara el MDM en su momento.** A menudo es un administrador que ha cambiado de puesto o ya no está, así que conviene preguntar más allá del equipo de IT actual. - **El portal de certificados Push de Apple.** Inicia sesión con cada cuenta corporativa que sospeches y comprueba si el certificado aparece listado. La cuenta que lo muestre es la propietaria. Si nada de eso funciona, contacta con el **soporte de Apple**. El certificado pertenece al Apple ID que lo creó, y Applivery no puede transferirlo ni recuperarlo. ### Comprobar que estás renovando el certificado correcto Antes de renovar, confirma que el identificador del certificado que muestra Applivery coincide con el del portal de certificados Push de Apple. Si no coinciden, estás mirando dos certificados distintos, y renovar el equivocado deja que el bueno caduque en su fecha. ### Evitarlo el año que viene Rellena el campo **Apple ID** de tu workspace. Cuesta un minuto durante la configuración, deja registrada la cuenta donde la va a buscar el siguiente administrador, y es la diferencia entre una renovación rutinaria y reinscribir todos los dispositivos que gestionas. --- ## Información de seguridad Source: https://docs.applivery.com/es/device-management/apple/security-info/ Description: Consulta el estado de seguridad de un dispositivo Apple en Applivery — cifrado, presencia de código y conformidad — y entiende qué significa cada valor. TL;DR: Consulta el cifrado y el estado del código de un dispositivo Apple en Detalles > Security info. En iOS el cifrado se verifica, no se activa: Apple exige capacidades de hardware 3 más un código para que los datos estén protegidos. Key topics: Data Protection en iOS, Conformidad del código, Reporte de FileVault, Verificación de seguridad del dispositivo, Applivery, Apple, iOS, macOS, FileVault "¿Está cifrado este iPhone?" es una pregunta que sale en toda auditoría de seguridad, y en los dispositivos Apple tiene una respuesta poco habitual: **el cifrado no se activa**. En iOS e iPadOS, Data Protection es una capacidad del hardware y está siempre presente. No hay ningún ajuste de política para habilitarlo, porque no hay nada que habilitar. Lo que sí hay es una forma de **verificarlo**, y para eso está el panel de información de seguridad. ### Dónde consultarlo Abre un dispositivo desde el listado en el [**panel de Applivery**](https://dashboard.applivery.io) y ve a **Detalles** → **Info de seguridad**. ![security info](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/c03ec296-aa2b-4d95-ab51-bc931d8fc1c2.png) ### Verificar el cifrado en iPhone y iPad El cifrado en iOS depende de dos cosas a la vez, y Apple enuncia el criterio de forma explícita: :::info **Para que un dispositivo tenga Data Protection, las capacidades de cifrado del hardware deben ser** `3` **y debe haber un código de acceso presente.** Las dos condiciones, no una u otra. :::

Valor

Qué significa

Capacidades de cifrado del hardware

1 — cifrado solo a nivel de bloque · 2 — solo a nivel de fichero · 3 — ambos

Código presente

Si el dispositivo tiene un código establecido

Por eso la [configuración de Código](https://docs.applivery.com/es/device-management/apple/apple-policies/passcode/) importa tanto en los dispositivos Apple. El hardware hace el cifrado, pero **el código es la llave**. Un dispositivo con todas las capacidades de hardware y sin código es, en la práctica, un dispositivo desprotegido, y aquí lo reportará tal cual. Si estás rellenando un checklist de cumplimiento que pregunta _"¿está cifrado el dispositivo?"_, esta pareja de valores es tu evidencia. ### Conformidad del código Dos valores indican si el código es lo bastante bueno, y la diferencia entre ellos importa:

Valor

Qué comprueba

Código conforme

El código cumple todos los requisitos del dispositivo, incluidos los que llegan desde Exchange y otras cuentas.

Código conforme con los perfiles

El código cumple solo los requisitos que llegan desde los perfiles MDM.

Cuando estés investigando _"¿por qué está marcado este dispositivo?"_, normalmente el que te interesa es el segundo: te dice si **tu** política se cumple, sin el ruido de los requisitos que fija una cuenta de correo que tú no gestionas. :::warning **Ninguno de los dos valores aplica a dispositivos inscritos mediante User Enrollment.** Apple no reporta la presencia de código ni la conformidad con perfiles en dispositivos personales, así que un valor vacío en un dispositivo BYOD no es un fallo: es el comportamiento esperado. Sumado a que [Apple ignora la mayoría de los ajustes de código en User Enrollment](https://docs.applivery.com/es/device-management/apple/apple-policies/passcode/), los dispositivos personales sencillamente no se pueden verificar por esta vía. ::: ### Cifrado en Mac macOS funciona al revés: el cifrado **sí** es un ajuste real, y es FileVault.

Valor

Qué reporta

FileVault activado

Si el cifrado de disco completo está encendido.

Tiene clave de recuperación institucional

Si existe una clave de recuperación de la organización.

Tiene clave de recuperación personal

Si existe una clave de recuperación personal.

Las claves de recuperación merecen revisarse junto al propio estado del cifrado. Un Mac cifrado sin clave de recuperación custodiada es un Mac al que no podrás ayudar cuando el usuario olvide su contraseña. FileVault se trata en [su propio artículo](https://docs.applivery.com/es/device-management/apple/macos/policies/filevault/). ### iPhone y iPad funcionan al revés que el Mac Los dos reportan aquí, pero la pregunta que respondes en cada uno es distinta:

iPhone / iPad

Mac

¿El cifrado es un ajuste?

No — está siempre en el hardware

Sí — FileVault

Qué haces con él

Verificarlo

Activarlo y después verificarlo

Qué lo hace efectivo

El código de acceso

Que FileVault esté activo

Qué comprobar

Capacidades de hardware 3 + código presente

FileVault activado + que exista clave de recuperación

La consecuencia práctica: en un iPhone, "sin cifrar" en realidad significa "sin código", y se resuelve con una [configuración de Código](https://docs.applivery.com/es/device-management/apple/apple-policies/passcode/). En un Mac es un problema de FileVault y se resuelve ahí. ### Qué no te dice la información de seguridad **No existe ningún estado de jailbreak ni de integridad para iOS.** El protocolo MDM de Apple sencillamente no lo expone: ningún MDM del mercado puede reportarlo, Applivery incluido. Los dos valores relacionados con la integridad que existen en esta respuesta, Secure Boot y System Integrity Protection, son **exclusivos de macOS** y no devuelven nada en un iPhone o iPad. Si tus requisitos incluyen detectar dispositivos Apple comprometidos, eso tiene que venir de una solución **Mobile Threat Defense** de terceros. --- ## Supervisión Source: https://docs.applivery.com/es/device-management/apple/supervision/ Description: El modo de supervisión de Apple en Applivery — ventajas, cómo activarlo y por qué desbloquea funciones MDM avanzadas para dispositivos de empresa. TL;DR: El modo de supervisión de Apple mejora la gestión de dispositivos iOS con funciones avanzadas, más adecuado para dispositivos de empresa y requiere un restablecimiento de fábrica para su activación. Answers: ¿Qué es el modo de supervisión de Apple? · ¿Cómo activar la supervisión de Apple? · ¿Cuáles son las ventajas del modo de supervisión? · ¿Se recomienda el modo de supervisión para BYOD? · ¿Cómo inscribir dispositivos en el DEP? Key topics: Modo de supervisión, Programa de inscripción de dispositivos, Apple Configurator, Gestión iOS, Funciones MDM, Apple, iOS, Applivery, Apple Business ### ¿Qué es la supervisión? La **supervisión** fue introducida por Apple en iOS 5. Es un modo de funcionamiento especial que permite a los administradores tener un mayor control sobre los dispositivos Apple. El modo de supervisión requiere un restablecimiento de fábrica o dispositivos nuevos configurados mediante [Apple Configurator](https://docs.applivery.com/es/device-management/apple/enrollment/apple-configurator/) o el [Programa de inscripción de dispositivos Apple (DEP)](https://docs.applivery.com/es/device-management/apple/enrollment/dep/). :::tip La supervisión es muy recomendable para los dispositivos de empresa, ya que desbloquea potentes funciones de gestión. ::: ### ¿Por qué debo usar la supervisión? La supervisión habilita muchas funciones y funcionalidades adicionales en Applivery. A continuación se muestran algunas de las más utilizadas: | Función | Descripción | | --- | --- | | **Modo perdido** | Activa el modo perdido en cualquier dispositivo. También conocido como **Buscar**. | | **Omisión del bloqueo de activación** | Evita quedar bloqueado fuera de un dispositivo por el bloqueo de activación del Apple ID. | | **Instalación silenciosa de apps** | Despliega apps en los dispositivos de forma silenciosa sin mostrar ningún mensaje al usuario. | | **Distribución de la pantalla de inicio** | Define cómo se muestran las apps en la distribución de la pantalla de inicio entre páginas y el dock. | | **Cambio de fondo de pantalla** | Configura remotamente la imagen de fondo de pantalla para las pantallas de bloqueo e inicio. | | **Restricciones de apps** | Crea una lista blanca o negra de apps. | | **Proxy HTTP global** | Fuerza que todo el tráfico pase por un proxy web. | | **Filtrado de contenido web** | Crea una lista blanca o negra de sitios web en Safari. Bloquea contenido para adultos. Consulta [Bloquear o permitir URLs en Safari](https://docs.applivery.com/es/device-management/apple/ios-ipados/policies/web-content-filter/). | | **Gestión de actualizaciones** | Gestiona y envía actualizaciones del OS. | | **Gestión del bloqueo de activación** | Desactiva el bloqueo de activación y gestiona los códigos de omisión del bloqueo de activación. | | **Restricciones adicionales** | Bloquea cambios en el Apple ID y cuentas de correo. Bloquea la instalación y desinstalación de apps. Bloquea cambios de código de acceso y mucho más. | ### ¿Cuándo debo usar la supervisión? La supervisión se recomienda principalmente cuando la organización es propietaria de los dispositivos que se gestionan y, normalmente, **no se recomienda** en escenarios de BYOD (Bring Your Own Device) por dos razones principales: 1. La mayoría de los usuarios no estarán muy cómodos concediendo un nivel de control tan avanzado sobre sus dispositivos. 2. La supervisión requiere un restablecimiento de fábrica de los dispositivos, por lo que todo el contenido (apps y contenido multimedia) se borrará del dispositivo, y estos datos no pueden restaurarse sin desactivar el modo de supervisión. ### ¿Cómo activo el modo de supervisión? Hay tres formas principales de activar la supervisión: - Conecta el dispositivo mediante USB a un ordenador Apple y ejecuta **Apple Configurator**. - Inscribe los dispositivos a través del **Programa de inscripción de dispositivos Apple (DEP)** en Apple Business. - Específicamente para dispositivos con chip de seguridad T2 o Apple Silicon, usa la **app Apple Configurator para iPhone** que inscribirá el dispositivo en Apple Business. :::warning En **macOS 11 o posterior**, todos los Mac inscritos mediante Inscripción de dispositivos o Inscripción automatizada de dispositivos (DEP) están supervisados. ::: Todas estas opciones también inscribirán el dispositivo en Applivery tras el proceso, para que puedas empezar a gestionarlo de inmediato. --- ## Ajustes generales Source: https://docs.applivery.com/es/device-management/general-settings/ Description: Configuración general de la Gestión de Dispositivos de Applivery: inscripción, políticas, Reglas de automatización, Segmentos y distribución de recursos. TL;DR: Los ajustes generales de Applivery permiten a los administradores gestionar y configurar dispositivos de forma centralizada, incluyendo ajustes del sistema y políticas de seguridad. Answers: ¿Qué se puede gestionar en los ajustes generales de Applivery? · ¿Quién puede utilizar los ajustes generales de Applivery? · ¿Dónde se accede a los ajustes generales de Applivery? · ¿Cuál es el propósito de los ajustes generales en Applivery? · ¿Se pueden aplicar políticas de seguridad con los ajustes generales de Applivery? Key topics: Gestión de dispositivos, Plataforma Applivery, Aplicación de políticas de seguridad, Configuración de dispositivos, Applivery, Dispositivos Los ajustes generales contienen las opciones de configuración multiplataforma que se aplican en todo tu Workspace — como segmentos, audiencias de dispositivos, atributos inteligentes, reglas de automatización y distribución de recursos. Estos ajustes te permiten estructurar tu organización dentro de Applivery, definir cómo se componen y aplican las políticas, y automatizar tareas rutinarias de gestión de dispositivos a escala. --- ## Auth Connector Source: https://docs.applivery.com/es/device-management/general-settings/auth-connector/ Description: Despliega el Auth Connector de Applivery para gestionar contraseñas SCEP y certificados NDES en Docker. TL;DR: El Auth Connector de Applivery, un contenedor Docker, gestiona contraseñas de desafío SCEP para certificados NDES en redes privadas. Answers: ¿Cómo desplegar el Auth Connector de Applivery? · ¿Qué es el Auth Connector de Applivery? · ¿Cómo configurar un proveedor de certificados en Applivery? · ¿Cuáles son las variables de entorno necesarias para el Auth Connector? · ¿Cómo solucionar errores del Auth Connector? · ¿Cómo funciona el Auth Connector de Applivery con NDES? · ¿Qué es una contraseña de desafío SCEP? Key topics: Auth Connector de Applivery, Configuración de proveedores de certificados, Despliegue de contenedores Docker, Integración SCEP y NDES, Monitorización del servicio, Applivery, Auth Connector, SCEP, NDES, Docker, PKI, AMD64, ARM64, Windows El **Auth Connector de Applivery** es un servicio auxiliar que suministra a tu Workspace de Applivery contraseñas de desafío SCEP válidas, las cuales se entregan a los dispositivos para que puedan solicitar certificados. Esto suele ser necesario cuando los servicios de la Autoridad de Certificación NDES se alojan en redes privadas. Applivery distribuye el Auth Connector como un **contenedor Docker** para arquitecturas **AMD64** y **ARM64**. Desde una perspectiva de infraestructura, el Auth Connector establece conexiones salientes con el servidor PKI que ejecuta el servicio NDES, recupera los desafíos SCEP y los reporta al panel de Applivery para su uso en las configuraciones de dispositivos. **Configurar el proveedor de certificados** Antes de desplegar el Auth Connector, deberás configurar un nuevo proveedor de certificados. Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), navega a la sección **Recursos** 1. Desde el menú lateral izquierdo, selecciona **Proveedores de certificados** 2 y haz clic en el botón **\+ Crear Proveedor de certificado** 3. ![configure certificate provider](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/bf34c055-be42-44ce-b532-730efc0ea20b.png) Rellena la configuración general, del servidor y del desafío del proveedor, y al menos un perfil de certificado con su nombre de autoridad, su clave y su sujeto. Tienes todos los campos explicados en [Proveedores de certificados](https://docs.applivery.com/es/device-management/general-settings/certificate-providers/). :::info Un Auth Connector, un Connector Token y un desafío sirven a todos los perfiles de certificado de ese proveedor. No tienes que desplegar un conector por perfil. ::: Haz clic en **Guardar** y vuelve a abrir la configuración para copiar el **Connector Token** 4 que aparece en la parte superior. ![auth connector token](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/06f0d79a-cf20-4c9f-b578-ec4ac2db686b.png) **Desplegar el Auth Connector** Despliega el Auth Connector como un **contenedor Docker**. El servicio se empaqueta como una imagen Docker, que puedes descargar del **registro Docker de Applivery**: ``` europe-southwest1-docker.pkg.dev/applivery/public/auth-connector ``` #### Versiones disponibles | Arquitectura | Etiquetas | | --- | --- | | linux/amd64 | `latest`, `0.1.2` | | linux/arm64 | `latest-arm`, `0.1.2-arm` | #### Cómo configurar el contenedor Necesitas proporcionar algunos datos importantes para que el contenedor se ejecute: - **CONNECTOR\_TOKEN**: El token obtenido del proveedor de certificados en el paso anterior. - **LOG\_LEVEL**: El nivel de detalle del registro. Las opciones son `debug`, `info`, `error` o `silent`. El valor predeterminado es `info`. - **LOG\_JSON**: Establece en `true` para generar registros en formato JSON, o `false` para registros de texto plano. El valor predeterminado es `false`. Puedes proporcionar estas configuraciones de **dos maneras**: 1. Usando un archivo `.env`: Un archivo que contiene todas las variables de entorno. 2. Directamente como variables de entorno en tu **comando Docker run** o en tu **archivo Docker Compose**. #### Ejemplo de archivo de configuración ``` ## Token del Auth Connector del proveedor de certificados. (obligatorio) CONNECTOR_TOKEN= ## Requerido para despliegues de instancias privadas. ## TENANT= ## El nivel de registro puede ser debug, info, error o silent. (predeterminado: info) LOG_LEVEL=info ## Registrar como json. (predeterminado: false) LOG_JSON=false ## Puerto de escucha para el servidor de informes. (predeterminado: 3000) PORT=3000 ``` :::info Solo necesitas establecer la variable **TENANT** para **Instancias Privadas**. ::: #### Ejemplos con Docker run ```bash ## Variables de entorno docker run \ -e CONNECTOR_TOKEN=YOUR_AUTH_TOKEN \ -p 3000:3000 \ europe-southwest1-docker.pkg.dev/applivery/public/auth-connector:latest ``` ```bash ## Archivo de configuración docker run \ -v .env:/app/.env \ -p 3000:3000 \ europe-southwest1-docker.pkg.dev/applivery/public/auth-connector:latest ``` #### Ejemplos con Docker Compose ```yaml services: # Archivo de configuración applivery-auth-connector: image: europe-southwest1-docker.pkg.dev/applivery/public/auth-connector:latest volumes: - .env:/app/.env ports: - 3000:3000 ``` ```yaml services: applivery-auth-connector: image: europe-southwest1-docker.pkg.dev/applivery/public/auth-connector:latest-arm environment: CONNECTOR_TOKEN: YOUR_AUTH_TOKEN #TENANT: LOG_LEVEL: info ports: - 3000:3000 ``` ### Informe de estado Un servicio HTTP se ejecuta en el puerto 3000 dentro del contenedor del Auth Connector, exponiendo un informe de estado con información como: - Número de desafíos solicitados. - Recuento total de errores. - Métricas operacionales adicionales. La misma información de estado también está disponible directamente en la configuración del proveedor de certificados en el panel de Applivery a través del icono de estado del conector. Una **marca de verificación verde** indica que el conector ha informado correctamente en los **últimos 20 minutos**. :::info Errores como **La caché de contraseñas está llena** indican que **el servidor NDES ha alcanzado su límite de solicitudes**. Ajusta los valores de registro correspondientes del servidor Windows para aumentar este límite. ::: --- ## Reglas de automatización Source: https://docs.applivery.com/es/device-management/general-settings/automation-rules/ Description: Las reglas de automatización de Applivery orquestan la gestión del ciclo de vida de dispositivos aplicando configuraciones y políticas automáticamente. TL;DR: Las reglas de automatización de Applivery automatizan la gestión de dispositivos, activando acciones según criterios de audiencia. Esto simplifica la configuración y aplicación de políticas. Answers: ¿Qué son las reglas de automatización de Applivery? · ¿Cómo se crea una regla de automatización en Applivery? · ¿Cómo funcionan las audiencias de dispositivos en Applivery? · ¿Cómo se establece una política usando reglas de automatización? · ¿Cómo gestiona Applivery los conflictos entre reglas de automatización? · ¿Qué ocurre cuando un dispositivo deja de cumplir los criterios de una regla de automatización? · ¿Qué metadatos de dispositivo se pueden usar para las reglas de automatización? Key topics: reglas de automatización, audiencia de dispositivos, acciones, aplicación de políticas, configuración de dispositivos, Applivery, iOS, Android, Windows, iPhone, Tableta Las **reglas de automatización** de Applivery son un mecanismo de **orquestación de dispositivos** que permite a los administradores definir lógica de negocio automatizada para la **gestión del ciclo de vida** y la configuración de dispositivos móviles y de escritorio. Una regla de automatización consiste en la definición de una **audiencia de dispositivos** que, al cumplirse, activa automáticamente una o más acciones en los dispositivos que satisfacen los criterios. Esto permite aplicar dinámicamente configuraciones, políticas de seguridad o despliegues de apps sin intervención manual. ### Crear una regla de automatización Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a la sección **Automatización** 1. Selecciona **Reglas de automatización** 2 y haz clic en el botón + **Crear Regla de automatización** 3. ![crear regla de automatización](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/7186c787-af11-464f-97f2-eb4f97fef29c.png) El formulario de configuración incluye las siguientes secciones: #### Configuración - **Nombre**: Un identificador único y descriptivo para la regla. - **Descripción** (Opcional): Una breve explicación del propósito de la regla. #### Audiencia de dispositivos La **audiencia de dispositivos** define qué dispositivos se verán afectados por las acciones de la regla. Los dispositivos se seleccionan basándose en: - **Etiquetas de dispositivo**: Metadatos asociados a los dispositivos, como la ubicación (_Madrid_, _Enfermería_), el sistema operativo (_iOS_, _Android_, _Windows_) o el tipo de dispositivo (_iPhone_, _Tablet_). - **Etiquetas de empleado**: Metadatos asociados al usuario asignado al dispositivo. - **Números de serie**: Selección explícita de dispositivos individuales por sus números de serie únicos. - **Añadir dispositivo / Añadir empleado**: Incluir manualmente dispositivos o usuarios específicos. :::info La regla se aplica a todos los dispositivos que cumplen **todos** los criterios definidos en la audiencia de dispositivos (lógica AND entre tipos de selección). ::: Puedes obtener más información sobre las [**audiencias de dispositivos**](https://docs.applivery.com/es/device-management/general-settings/device-audiences/) siguiendo este enlace. #### Acciones Las **acciones** definen lo que el sistema ejecutará en los dispositivos que coincidan con la audiencia definida. Hay dos: - **Establecer una política** 4 — aplica una política de configuración previamente definida a los dispositivos seleccionados. - **Añadir un Smart Attribute** — asigna el valor de un [Smart Attribute](https://docs.applivery.com/es/device-management/general-settings/smart-attributes/) a los dispositivos seleccionados. Como los Smart Attributes alimentan a su vez las [audiencias de dispositivos](https://docs.applivery.com/es/device-management/general-settings/device-audiences/), esto permite construir automatizaciones encadenadas: una regla etiqueta los dispositivos y otra actúa sobre esa etiqueta. :::info **Estas son las dos únicas acciones disponibles.** Las reglas de automatización configuran dispositivos, no envían comandos. No existe una acción para bloquear, borrar o desinscribir un dispositivo desde una regla. Para llegar automáticamente a esos resultados, aplica con la regla una política restrictiva y deja que las [Policy Enforcement Rules](https://docs.applivery.com/es/device-management/android/policies/enforcement-rules/) de esa política (solo Android) se encarguen del bloqueo y el borrado. Si no, usa los comandos remotos de forma manual. ::: Al configurar la acción **Establecer una política**, especificas la **plataforma de destino** 5, como Apple, Android o Windows, para determinar a qué dispositivos se aplica la política. También asignas un valor numérico de **prioridad** 6, por ejemplo, 100. Si varias reglas afectan al mismo dispositivo, el sistema aplica la política asociada a la regla que tiene la **prioridad más alta** (los números más bajos indican mayor prioridad). Esto garantiza un comportamiento consistente y predecible en toda la flota. ![actions for automation rules](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/22df9f53-edd4-4342-829c-3659fad0fcf3.png) Las reglas de automatización evalúan continuamente los dispositivos para determinar si cumplen los criterios de audiencia definidos. Cuando un dispositivo coincide, las acciones especificadas —como aplicar una política— se ejecutan automáticamente. Si el dispositivo deja de cumplir los criterios, las acciones pueden revertirse o actualizarse según la configuración de la regla. Esto garantiza que los dispositivos siempre reflejen la configuración deseada y simplifica la gestión de la flota al permitir la segregación y configuración automáticas basadas en metadatos. --- ## Inscripción masiva Source: https://docs.applivery.com/es/device-management/general-settings/bulk-enrollment/ Description: Invita a varios usuarios a inscribir sus dispositivos a la vez en Applivery, en lugar de crear las inscripciones una a una. TL;DR: Ve a Dispositivos, abre el desplegable junto a + Inscribir dispositivo y selecciona + Inscribir múltiples dispositivos para invitar a toda una lista de empleados en una sola acción. Key topics: Inscripción masiva, Empleados, Onboarding masivo, Caducidad de las inscripciones, Applivery, Apple, Android, AOSP Una vez tengas tus políticas configuradas, puedes empezar a inscribir dispositivos. Crearlos de uno en uno está bien para un puñado de personas, pero para dar de alta a todo un equipo, abrir una oficina nueva o renovar el parque, Applivery te permite invitar a todo el mundo a la vez. Vamos a verlo. La inscripción masiva crea **una inscripción por empleado**: añades una lista de personas y cada una obtiene su propia inscripción en el listado de dispositivos, con sus instrucciones y su caducidad. Funciona en Apple, Android, AOSP y Windows — el formulario es el mismo que ya conoces, solo que pide una lista de empleados en lugar de uno solo. ### Crear una inscripción masiva Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a **Dispositivos** 1. Junto al botón **\+ Inscribir dispositivo**, abre el desplegable y selecciona **\+ Inscribir múltiples dispositivos** 2. ![enroll multiple devices](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/d5eead26-c31e-4763-a9ab-52375f06d6d0.png) **Configurar los ajustes de la inscripción** Rellena el formulario de la siguiente manera: - **Plataforma**: elige la plataforma de los dispositivos que vas a inscribir. - **Modo de gestión**: en Android, elige cómo se gestionarán los dispositivos. - **Empleados**: las personas a las que quieras invitar. Empieza a escribir para buscar entre tus empleados existentes, o introduce una nueva dirección de correo directamente — **se creará una inscripción para cada empleado que añadas**. - **Política**: la política que tendrán aplicada los dispositivos una vez inscritos. :::info Si no se encuentra el correo de un empleado, se crea un nuevo empleado automáticamente. No necesitas dar de alta a nadie en tu directorio previamente. ::: **Revisar los ajustes opcionales** Despliega **Más opciones** para el resto: - **Etiquetas**: organiza, agrupa y filtra los dispositivos resultantes. - **Nombre de visualización**: un nombre descriptivo para identificar los dispositivos entre los demás. - **Expirar después de**: cuánto tiempo siguen siendo válidas las inscripciones. Una vez transcurrido el plazo, dejan de funcionar. - **Ubicación VPP** _(Apple)_: las licencias de apps se asociarán automáticamente a los dispositivos desde esa ubicación de Apple Business. - **Omitir información personal** _(Apple)_: se salta los pasos de información personal durante la configuración. - **Enviar instrucciones email al empleado**: notifica a cada persona con los pasos para inscribirse. Al activarlo puedes definir también el **idioma de las instrucciones** y añadir un **mensaje** personalizado. **Crear las inscripciones** Haz clic en **Crear inscripciones** — el botón muestra cuántas se van a crear, una por empleado. Cada inscripción se añade después al listado de dispositivos con estado pendiente, la política asignada y su cuenta atrás de caducidad. Haz clic en cualquiera de ellas para ver sus detalles e instrucciones, igual que harías con una inscripción individual. :::warning **Todas las inscripciones que crees a la vez comparten la misma política.** Si distintas personas necesitan políticas distintas, repite la operación una vez por cada política — o asígnalas de forma condicional mediante los [Atributos inteligentes](https://docs.applivery.com/es/device-management/general-settings/smart-attributes/). ::: ### Qué recibe el empleado Si elegiste enviar el correo de instrucciones, cada empleado recibe su propio mensaje con los pasos correspondientes a su plataforma y modo de gestión. Desde su punto de vista nada indica que formaba parte de un grupo: la inscripción es individual, y también lo es el código o el QR que recibe. Las instrucciones de inscripción varían según la plataforma y se explican en el artículo de inscripción de cada una: - [Apple](https://docs.applivery.com/es/device-management/apple/enrollment/enrollment-methods/) - [Android](https://docs.applivery.com/es/device-management/android/enrollment/manual-enrollment/) - [Windows](https://docs.applivery.com/es/device-management/windows/enrollment/enrollment-methods/) --- ## Proveedores de certificados Source: https://docs.applivery.com/es/device-management/general-settings/certificate-providers/ Description: Configura una sola vez un proveedor de certificados SCEP y añade un perfil por cada certificado que necesites; después, elige el perfil desde las políticas de Apple y Android. TL;DR: Configura una sola vez el servidor SCEP y el desafío en un proveedor de certificados, añade un perfil por cada certificado que necesites y elige el proveedor y el perfil desde un payload SCEP de Apple, una red Wi-Fi WPA-EAP de Android o una asignación de una política Android hecha por API. Key topics: Ajustes del proveedor y del perfil, Configuración del proveedor de certificados, Modos del desafío, Perfiles de certificado y alias del par de claves, Reemisión de certificados, Payload SCEP de Apple, Wi-Fi WPA-EAP de Android con EAP-TLS, Asignaciones de políticas Android por API, Certificados del dispositivo e informe de certificados, Proveedores existentes y perfil Default, API de proveedores de certificados, Applivery, SCEP, NDES, Auth Connector, Apple, Android Un **proveedor de certificados** es un recurso que guarda una conexión SCEP, es decir, el servidor al que los dispositivos piden los certificados y el desafío con el que demuestran que pueden hacerlo. Sobre esa conexión, cada proveedor tiene uno o varios **perfiles de certificado**: el nombre de autoridad, la configuración de la clave y el sujeto de un tipo de certificado. Cuando necesitas un certificado distinto, añades un perfil en lugar de crear otro proveedor. Después, tus políticas eligen el proveedor y el perfil que necesitan, desde un payload **SCEP** de Apple o una red Wi-Fi **WPA-EAP** de Android. Un mismo servidor y un mismo desafío pueden emitir identidades distintas, por ejemplo, una para la Wi-Fi y otra para la VPN, sin duplicar la configuración ni sus secretos. :::info Un [Auth Connector](https://docs.applivery.com/es/device-management/general-settings/auth-connector/), un Connector Token y un desafío sirven a todos los perfiles de un proveedor. No tienes que desplegar un conector por perfil. ::: ### Ajustes del proveedor y del perfil Cada campo del formulario pertenece a uno de dos niveles. El nivel decide dónde se guarda el valor y a cuántos dispositivos afecta cambiarlo.

Nivel

Qué describe

Campos

Proveedor

Cómo hablan los dispositivos con el servidor SCEP. Lo defines una vez y lo usan todos los perfiles.

Type, URL del servidor, Huella digital de la CA, Retries, Retry Delay y la configuración del desafío

Perfil

Qué contiene el certificado. Cada perfil puede tener valores distintos.

Nombre del perfil, Nombre de la autoridad, la configuración de la clave y la configuración del sujeto

**Name** y **Description** también pertenecen al proveedor, pero solo lo identifican en el listado y nunca llegan al certificado. El listado de **Proveedores de certificados** muestra, para cada proveedor, su segmento, su servidor SCEP, sus perfiles y su modo de desafío. ### Crear o editar un proveedor de certificados El formulario tiene cuatro bloques numerados: **General Configuration**, **Server Configuration**, **Certificate Profiles** y **Challenge Configuration**. **Abre Proveedores de certificados** En el [**panel de Applivery**](https://dashboard.applivery.io/), ve a **Recursos** 1. En el menú lateral izquierdo, selecciona **Proveedores de certificados** 2 y haz clic en **\+ Crear Proveedor de certificado** 3, o abre un proveedor existente. ![configurar proveedor de certificados](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/bf34c055-be42-44ce-b532-730efc0ea20b.png) **Rellena la configuración general** - **Name**: el nombre que verás en el listado y al elegir el proveedor desde una política. - **Description**: opcional. - **Type**: **SCEP**. En un proveedor existente, esta sección muestra también su **ID** y su **Connector Token**. ![scep creation](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/c76e99e7-7c15-4039-99c7-ea1b29a63bb0.png) **Rellena la configuración del servidor** - **URL del servidor** (obligatorio): la URL del servidor SCEP. Para NDES, por ejemplo: `https:///certsrv/mscep/mscep.dll`. - **Huella digital de la CA** (opcional): la huella SHA-1 de la CA emisora, para que el dispositivo valide la CA antes de confiar en su respuesta. Para obtenerla, abre el certificado de la CA que usa el servidor NDES, ve a la sección **Extensiones** y copia la entrada **Huella digital de la CA**. - **Retries**: cuántas veces se reintenta la solicitud si falla. - **Retry Delay**: el tiempo, en segundos, entre reintentos. Ajusta **Retries** y **Retry Delay** al comportamiento de tu CA: son el único control que tienes sobre una solicitud que falla en el dispositivo. **Configura los perfiles de certificado** Rellena el perfil que ya viene creado con su nombre de autoridad, su clave y su sujeto. Mientras no le pongas nombre, aparece como **Untitled profile** con la marca **Default**: es el perfil que usan las asignaciones que no eligen ninguno. Todos los campos, y cómo añadir más perfiles, están en [Perfiles de certificado](#perfiles-de-certificado). **Rellena la configuración del desafío** Elige el **Modo**, es decir, cómo obtienen el desafío los dispositivos:

Modo

Campos

Cuándo usarlo

None

—

Tu CA no exige desafío.

Manual

Challenge value

Un secreto estático que pegas tú. Es el mismo para todas las solicitudes.

NDES

URL, Nombre de usuario, Contraseña, Challenge pool size

Applivery pide desafíos de un solo uso al endpoint mscep_admin de NDES y mantiene una reserva preparada. El tamaño de la reserva va de 10 a 10 000.

Para **NDES**: - **URL**: `https:///certsrv/mscep_admin`. - **Nombre de usuario**: un usuario de dominio con permisos para la plantilla de certificado configurada en el servidor NDES. - **Contraseña**: la contraseña de ese usuario. - **Challenge pool size**: cuántos desafíos mantiene preparados Applivery, de 10 a 10 000. Aunque en el formulario aparece después de los perfiles, el desafío pertenece al proveedor y lo usan todos los perfiles. **Guarda y copia el Connector Token** Haz clic en **Guardar**. El proveedor recibe su propio ID, visible en la URL y en la parte superior de su detalle, y las políticas usan ese ID para referirse a él. Vuelve a abrir el proveedor para copiar el **Connector Token** que aparece en la parte superior. Lo necesitarás para [desplegar el Auth Connector](https://docs.applivery.com/es/device-management/general-settings/auth-connector/). ### Perfiles de certificado Cada perfil define la autoridad, la clave y el sujeto de los certificados solicitados, y comparte la configuración del servidor y del desafío. Las políticas eligen el perfil que usan. La sección **Certificate Profiles** muestra un contador con el número de perfiles del proveedor, y cada perfil tiene su propia pestaña. - Uno de los perfiles es el perfil **Default**: su pestaña muestra **(Default)** y su nombre lleva la etiqueta **Default**. Un proveedor siempre tiene uno, y es el perfil que se usa cuando una asignación no elige ninguno. - **\+ Add profile** añade otra pestaña. Cada pestaña es un perfil independiente, con su propio sujeto, su propia clave y su propio alias del par de claves. - Los perfiles que no son el Default tienen un icono de papelera para eliminarlos. No puedes eliminar el perfil Default ni un perfil que una política siga usando. ![Certificate profiles](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/b8871659-2f68-4a55-8ab4-02b904c261e0.png) #### Nombre del perfil y nombre de autoridad - **Nombre del perfil**: la etiqueta que verás en el panel y al elegir el perfil desde una política. - **Nombre de la autoridad**: identifica el perfil o la plantilla que se solicita, por ejemplo `mycompany-pki`. Introduce el nombre de la CA intermedia o emisora exactamente como aparece en el certificado de la CA. #### Configuración de la clave - **Key Usage**: los usos permitidos de la clave: **Both**, **Signing** o **Encryption**. - **Tamaño de la clave**: el tamaño de la clave generada: **1024**, **2048** o **4096**. Normalmente **2048** o **4096**, según tu política de seguridad. - **Tipo de clave**: RSA, el valor por defecto. - **Key Is Extractable**: si la clave privada se puede extraer del almacén de claves del dispositivo. - **Allow All Apps Access**: si todas las apps del dispositivo pueden usar la clave. #### Configuración del sujeto Los campos con el botón `{}` admiten [etiquetas de interpolación](https://docs.applivery.com/es/device-management/general-settings/dynamic-variables/), marcadores que Applivery sustituye por datos del dispositivo o del empleado al desplegar el certificado. Los campos sin el botón no las admiten. :::info Haz clic en `{}` para abrir la lista de etiquetas disponibles e insértalas desde ahí en lugar de escribirlas a mano. Conviven dos sintaxis, `%…%` y la sintaxis `{{…}}` de los proveedores antiguos, y el selector inserta siempre la correcta. ::: - **Subject**: el sujeto del certificado. Admite etiquetas de interpolación, por ejemplo `CN={{user.email}}`. - **NT Principal**: el User Principal Name (UPN) en formato NT, por ejemplo `john.doe@MYCOMPANY`. Admite etiquetas de interpolación. - **URI**: URL o URN asociadas. Haz clic en **Add** para cada una. - **Email**: el nombre RFC822. Haz clic en **Add** para cada uno. - **DNS**: nombres de dominio válidos. Haz clic en **Add** para cada uno. Si guardas metadatos propios en tus empleados, como una clave `cn` o `upn`, puedes usarlos con `{{user.metadata.PROPERTY}}`, por ejemplo `CN={{user.metadata.cn}}` o `{{user.metadata.upn}}`. ![subject configuration](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/58e41dc3-0980-4beb-b243-677216e2bc6b.png) #### Alias del par de claves Cada perfil tiene un alias del par de claves (`keyPairAlias`): el nombre con el que el dispositivo guarda el par de claves en su almacén. Applivery lo genera siguiendo un patrón fijo. No aparece en el formulario y no puedes cambiarlo.

Perfil

Alias del par de claves

Default

apl-scep-<providerId>

Cualquier otro perfil

apl-scep-<providerId>-<profileId>

El alias del perfil Default no lleva sufijo: es el mismo alias que usaban los proveedores antes de que existieran los perfiles. El sufijo con el ID del perfil garantiza que dos perfiles del mismo proveedor nunca sobrescriban el par de claves del otro en el dispositivo. Usa el alias para cruzar lo que muestra el panel con lo que informa el dispositivo, como se explica en [Comprobar los certificados de un dispositivo](#comprobar-los-certificados-de-un-dispositivo). ### Qué pasa cuando cambias un proveedor Editar la configuración del servidor o del desafío no cambia los perfiles: su configuración y sus alias se quedan exactamente como estaban. Cambiar un campo dentro de la pestaña de un perfil solo afecta a ese perfil. Aun así, cambiar un proveedor provoca la reemisión de certificados. Cuántos dispositivos reciben un certificado nuevo depende del nivel del campo que cambies:

Si cambias…

Se reemiten los certificados de…

Ejemplo

Un campo del perfil

Solo los dispositivos asignados a ese perfil.

Cambiar el Subject de un perfil de VPN reemite los certificados de los dispositivos de ese perfil. Los dispositivos del perfil de Wi-Fi conservan su número de serie y su desafío.

Un campo del proveedor

Los dispositivos de todos los perfiles del proveedor.

Cambiar Retry Delay reemite los certificados de todos los dispositivos. Los sujetos no cambian, porque solo has cambiado la conexión.

Un certificado reemitido tiene un número de serie nuevo y un desafío nuevo. Si el número de serie se mantiene, el certificado no se ha reemitido. :::info Los dispositivos Android no se sincronizan uno a uno: el cambio se aplica en el siguiente ciclo de informe, que puede tardar hasta unos 60 minutos. Cuando cambies un campo del proveedor, cuenta con que todos los dispositivos de ese proveedor renueven su certificado dentro de ese plazo. ::: ### Usar un perfil en una política de Apple El payload **SCEP** (`com.apple.security.scep`) configura los ajustes de Simple Certificate Enrollment Protocol (SCEP). Su tarjeta indica iOS 10.0, macOS 10.12 Sierra, tvOS 10.0, watchOS 3.0 y visionOS 1.1. El selector **Fuente** del payload tiene dos opciones: - **Manual**: escribes tú los ajustes SCEP en el payload. No hay ningún proveedor detrás, así que los cambios en **Recursos** no se aplican a este payload. - **Proveedor de certificados**: el payload guarda una referencia a un proveedor y a un perfil, y Applivery rellena los ajustes reales al entregar el payload al dispositivo. **Elige el origen** En el payload SCEP de tu política de Apple, pon la **Fuente** en **Proveedor de certificados**. Los campos manuales desaparecen. La tarjeta muestra el proveedor seleccionado, con las opciones **Cambiar** y **Ver detalles**. **Elige el perfil** En **Perfil**, selecciona el perfil que necesitas de ese proveedor. El perfil por defecto aparece como **(Default)**. La lista solo muestra los perfiles del proveedor seleccionado. Para usar un perfil de otro proveedor, haz clic en **Cambiar**, selecciona ese proveedor y vuelve a elegir el perfil. ![scep](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/48bcc8fe-e8de-45bc-b9c6-3d9695f6149f.png) Cada configuración SCEP elige un proveedor y un perfil. #### Qué recibe el dispositivo El dispositivo nunca recibe las referencias al proveedor y al perfil. Recibe el payload SCEP con la URL del servidor, el desafío y el sujeto del perfil elegido ya rellenos. En la pestaña **Profiles** del dispositivo, el payload `com.apple.security.scep` aparece instalado junto al payload de CA raíz `com.apple.security.root`, que permite al dispositivo confiar en el emisor. Si un payload apunta a un perfil que no existe, por ejemplo, cuando lo construyes por API, Applivery lo rechaza al guardar y el perfil de configuración no se guarda. ### Usar un perfil en una red Wi-Fi de Android Desde una política Android, ve a **WiFi** → **\+ Añadir red Wi-Fi**, como se explica en [Configurar redes Wi-Fi](https://docs.applivery.com/es/device-management/android/policies/configure-wifi-networks/), y después: 1. Pon **Seguridad** en **WPA-EAP**. 2. En la configuración EAP, pon **Outer** en **EAP-TLS**. 3. Pon **Certificate Type** en **Certificate Provider**. 4. Elige el proveedor de certificados y después el perfil. El [agente de Android](https://docs.applivery.com/es/device-management/android/policies/agent/#gesti%C3%B3n-de-recursos) instala en el almacén de claves del dispositivo el certificado solicitado por SCEP. :::warning Si tienes previsto bloquear los cambios manuales de Wi-Fi en el dispositivo, asegúrate de que al menos una red válida y probada ya esté declarada en la política — de lo contrario, el dispositivo podría perder el acceso Wi-Fi por completo. ::: ### Asignar un perfil a una política de Android por API Además de las redes Wi-Fi, una política Android puede pedir certificados con su lista `certificateProviderAssignments`. El editor de políticas del panel no incluye estas asignaciones, así que se configuran por la [API de Applivery](https://docs.applivery.com/en/api/android/policies/put-policy/). Cada asignación de la lista tiene estos campos:

Campo

Descripción

certificateProviderId

Obligatorio. El proveedor al que se pide el certificado.

profileId

Opcional. El perfil que se usa, como cadena. Si no lo incluyes, la política usa el perfil Default del proveedor. El perfil tiene que pertenecer a ese proveedor.

storeCredentials

Obligatorio. Si las credenciales emitidas se guardan en el dispositivo. Acepta un booleano o una cadena.

La asignación más corta tiene dos claves y usa el perfil Default: ```json "certificateProviderAssignments": [ { "certificateProviderId": "", "storeCredentials": false } ] ``` - Si envías el `profileId` del perfil Default, Applivery guarda la asignación sin él. Al leer una política, un `profileId` ausente siempre significa el perfil Default. - La política también tiene una lista `certificateProviderIds`. Applivery la rellena a partir de las asignaciones, así que no hace falta enviarla, y escribirla no tiene ningún efecto. - En el dispositivo, una asignación sin perfil entrega el sujeto del perfil Default y el alias sin sufijo. Una asignación con perfil entrega el sujeto de ese perfil y el alias con su sufijo. Si el `profileId` no pertenece al proveedor, Applivery rechaza el guardado con un error `400` que nombra los dos: ```text Profile not found in certificate provider ``` Toma siempre el `profileId` de la lista `profiles` de ese mismo proveedor. :::warning Applivery descarta sin avisar cualquier clave que no reconozca en una asignación. Una errata en el nombre de un campo no devuelve error: el campo simplemente no se guarda. Después de escribir por API, vuelve a leer la política y comprueba que se guardó lo que esperabas. ::: ### Comprobar los certificados de un dispositivo La pestaña **Certificates** de un dispositivo lista los certificados instalados, con su **Subject**, su **Issuer**, su **Serial number** y su periodo de validez. La etiqueta **Identity** marca los certificados que incluyen clave privada. #### Informe de certificados de Android En los dispositivos Android, el detalle completo está en el campo `config.certificateReport[]` del dispositivo, que obtienes por la [API de Applivery](https://docs.applivery.com/en/api/android/devices/get-device/). Úsalo para comprobar que lo que recibió el dispositivo coincide con lo que configuraste:

Campo

Qué comprobar

originId

Que es el ID del proveedor esperado.

commonName

Que corresponde al Subject del perfil asignado, no al del perfil Default.

keyPairAlias

Que sigue el patrón del perfil y coincide con el alias del log del agente.

certificateInfo.serialNumber

Solo cambia cuando el certificado se reemite.

certificateInfo.issuer

Es el mismo en todos los perfiles de un proveedor, porque la CA es la misma.

certificateInfo.subject

Contiene el mismo CN que commonName.

state

Es installed cuando el certificado está en el dispositivo.

numFailedRetries

Es 0 en una solicitud correcta. Un valor mayor indica que se agotaron los reintentos.

updatedAt

Cuadra con el momento en que el agente informó de la instalación.

#### Log del agente de Android El agente de Applivery en Android tiene una **Log Console**. Filtra por `SCEP` para ver las entradas `I/SCEPEnrollment` y una línea `Certificate reporting completed` que nombra el alias usado. Ese alias y el `keyPairAlias` de la API tienen que ser el mismo. Si no coinciden, el panel y el dispositivo no están de acuerdo sobre qué clave se ha emitido. :::warning El desafío aparece en claro en el informe. Para documentar o reportar una incidencia, comparte su hash SHA-256, nunca el desafío. ::: ### Ejemplo Tienes un servidor NDES y necesitas dos certificados distintos: 1. Crea un proveedor de certificados con la **URL del servidor** NDES y el desafío, usando tus propios valores de ``. 2. En el primer perfil, introduce el nombre de autoridad tal como aparece en el certificado de la CA emisora, **Tamaño de la clave** 2048, **Key Usage** **Both** y **Subject** `CN={{user.email}}`. 3. Haz clic en **\+ Add profile** y crea un segundo perfil, con su propio nombre de autoridad y su propio sujeto, para otro destino de tu política. Tu payload SCEP de Apple y tu red WPA-EAP de Android eligen cada uno el perfil que necesitan, sin un segundo proveedor de certificados. ### Proveedores creados antes de los perfiles de certificado Si creaste un proveedor de certificados antes de que existieran los perfiles, ábrelo: su nombre de autoridad, su clave y su sujeto forman ahora el perfil **Default**. El nombre de autoridad, que antes estaba en la configuración del servidor, está ahora en ese perfil, y la configuración del servidor solo conserva los campos compartidos. La conversión garantiza que: - El perfil resultante es el perfil Default, y su ID coincide con el ID del proveedor. - El sujeto, los nombres alternativos del sujeto, el tamaño, el tipo y el uso de la clave conservan sus valores exactos, ahora dentro del perfil. El sujeto mantiene sus etiquetas `{{…}}` originales. - La configuración propia del proveedor deja de incluir esos campos. - El alias del par de claves sigue siendo `apl-scep-`, sin sufijo. Por eso los dispositivos no notan el cambio: conservan su certificado con el mismo número de serie y el mismo alias. La conversión no reemite certificados. Las políticas que ya usaban el proveedor siguen usando su perfil Default, así que no tienes que volver a crear nada. El Connector Token sigue en el proveedor, y puedes añadir más perfiles con **\+ Add profile**. ### Gestionar proveedores de certificados por API Todas las operaciones usan la ruta base `/organizations/{organizationId}/certificate-providers`:

Operación

Descripción

GET /

Lista los proveedores de la organización.

POST /

Crea un proveedor. Los objetos de profiles no pueden incluir id.

GET /{id}

Devuelve config y profiles, cada perfil con su config y su keyPairAlias.

PUT /{id}

Reemplaza el proveedor. Si no incluyes un perfil, se elimina.

:::warning Applivery asigna los ID de los perfiles. Si incluyes un `id` en un perfil al crear un proveedor, la solicitud se rechaza con un error `4xx` y el proveedor no se crea. ::: #### Editar un proveedor con PUT Un `PUT` no modifica la lista `profiles`, la sustituye. Cualquier perfil que no incluyas en el cuerpo de la solicitud se elimina: ```json // Proveedor con P-ONE y P-TWO. Este PUT deja solo P-ONE: { "config": { …sin cambios… }, "profiles": [ { "id": "", … } ] } // Resultado: un solo perfil. P-TWO ya no existe. ``` Para editar un proveedor de forma segura, sigue siempre el mismo patrón: haz un `GET` del proveedor, modifica la respuesta y haz un `PUT` con el objeto completo. Los ID de los perfiles que mantienes no cambian. - Si no incluyes un perfil que usa una política, el `PUT` se rechaza con un error `4xx` y el proveedor se queda como estaba, con todos sus perfiles y sus ID. Primero quita el perfil de la política, o elimina la política, y después edita el proveedor. - No envíes `keyPairAlias` en un `PUT`: es de solo lectura. Un `GET` posterior siempre devuelve el alias correcto. #### Formato de la respuesta ```json { "id": "", "name": "Certificados Corporativos SCEP", "config": { "type": "scep", "serverUrl": "https://scep.miempresa.com/scep", "CAFingerprint": "A789E5…AB18", "retries": 3, "retryDelay": 10, "challenge": { "mode": "ndes", … } }, "profiles": [ { "id": "", "keyPairAlias": "apl-scep-", "config": { "name": "Wi-Fi corporativo", "subject": "CN=%UserName%,O=MiEmpresa", "subjectAltName": { … }, "keySize": 2048, "keyType": "RSA", "keyUsage": "both", "keyIsExtractable": true, "allowAllAppsAccess": false } }, { … } ] } ``` El `config` del proveedor contiene los ajustes compartidos, y cada `profiles[].config` contiene los ajustes de ese perfil. `retries` y `retryDelay` aparecen una sola vez, a nivel de proveedor, mientras que `subject`, `keySize`, `keyUsage` y `keyType` aparecen solo dentro de `profiles[].config`. --- ## Comprobaciones de conformidad Source: https://docs.applivery.com/es/device-management/general-settings/compliance-checks/ Description: Interpreta las comprobaciones de conformidad de un dispositivo en Applivery. Entiende los colores del escudo, qué reporta cada plataforma y cómo resolver cada comprobación. TL;DR: Las comprobaciones de conformidad listan qué falla en un dispositivo, en su Overview. Los escudos verde, gris y rojo lo resumen en el listado. Apple reporta perfiles, apps y libros pendientes; Android añade los fallos de ajustes y la postura de seguridad. Answers: ¿Qué son las comprobaciones de conformidad en Applivery? · ¿Dónde encuentro las comprobaciones de conformidad de un dispositivo? · ¿Qué significan los colores del escudo en el listado de dispositivos? · ¿Que la lista de comprobaciones esté vacía significa que algo va mal? · ¿Todas las plataformas muestran las mismas comprobaciones de conformidad? · ¿Qué significa "La versión de la política aún no se ha enviado al dispositivo"? · ¿Por qué una app aparece como no instalada en un dispositivo Apple? · ¿Dónde veo por qué un ajuste no se ha podido aplicar en Android? Key topics: Conformidad del dispositivo, Motivos de no conformidad, Instalaciones pendientes, Postura de seguridad, Applivery, Android, Apple, AOSP Asignar una política a un dispositivo es solo la mitad del trabajo. La otra mitad es saber si el dispositivo ha hecho realmente lo que le pediste y, si no lo ha hecho, por qué. A eso responden las **comprobaciones de conformidad**. Funcionan como una lista de incidencias abiertas. Cada entrada es un problema, titulada con lo que falla y desplegable para ver el detalle que hay detrás. :::info **Las comprobaciones solo aparecen cuando hay algo que reportar.** Un dispositivo con la lista vacía es un dispositivo sin nada pendiente: no hay entradas en verde confirmando que cada punto se supera. Aquí el silencio es la buena noticia. ::: ### Dónde consultarlas Abre un dispositivo desde el listado y ve a la sección **Overview**, donde encontrarás los **Compliance checks**. El **escudo** que aparece junto al campo de la política en el listado de dispositivos es el resumen de esa misma información, así que puedes triar el parque sin abrir los dispositivos uno a uno: | Escudo | Qué significa | | --- | --- | | 🟢 **Verde** | El dispositivo es conforme. Nada que hacer. | | ⚪ **Gris** | Hay al menos una comprobación abierta, y no es un problema de seguridad. | | 🔴 **Rojo** | La [postura de seguridad](https://docs.applivery.com/es/device-management/android/security-posture/) es **En riesgo** o **Potencialmente comprometido**. | La diferencia entre gris y rojo merece interiorizarse. **El gris es operativo**: algo no ha llegado todavía, o un ajuste no está soportado. **El rojo es un problema de confianza**: el propio sistema operativo puede haber sido modificado. Piden respuestas completamente distintas. ### Qué reporta cada plataforma Las comprobaciones de conformidad son una vista común, pero cada dispositivo reporta solo lo que **expone su propio sistema operativo**. Que un bloque no aparezca no significa que falten datos: esa plataforma no tiene ese concepto. | Comprobación | Apple | Android | AOSP | | --- | --- | --- | --- | | Versión de la política sin enviar | — | ✅ actual + deseada | ✅ actual | | Perfil de configuración pendiente | ✅ | — | — | | Apps pendientes | ✅ | — | — | | Libros pendientes | ✅ | — | — | | Fallos a nivel de ajuste | — | ✅ | ✅ | | Postura de seguridad | — | ✅ | — | Dos consecuencias que conviene tener claras antes de prometer nada a un cliente: - **En Apple no obtienes fallos a nivel de ajuste.** Ves lo que sigue pendiente, no un motivo por ajuste. Si una restricción no está surtiendo efecto en un iPhone, esta vista no te dirá por qué. - **En AOSP no hay postura de seguridad**, porque depende de la Play Integrity API. Se explica en [Postura de seguridad del dispositivo](https://docs.applivery.com/es/device-management/android/security-posture/). ### Comprobaciones en Apple #### Perfil de la política **El perfil de la política no está actualizado** significa que el dispositivo no ha aplicado la versión actual del perfil de la política. Cuando lo que corresponde es retirarlo, la comprobación dice **El perfil de la política debe ser desinstalado**. #### Apps Cada app genera una comprobación, y el título te dice en cuál de las tres situaciones estás: | Título | Qué significa | | --- | --- | | **App no instalada** | El dispositivo aún no tiene la app. | | **App no actualizada** | La app está instalada, pero en una versión anterior a la desplegada. | | **La app debe desinstalarse** | La app está en el dispositivo y no debería. | Cada una muestra el **Bundle ID**, etiquetado con su origen — *Applivery* para las apps subidas a la plataforma, *VPP* para las licenciadas a través de Apple Business —, además de la **versión** esperada y, cuando la app ya está, la **versión instalada**. Comparar esas dos es lo que distingue una instalación fallida de una desactualizada. #### Libros Los libros funcionan igual: **Libro no instalado** o **El libro debe ser desinstalado**, mostrando el **nombre del recurso** si el libro se subió como asset, o el **nombre de la App Store** si se distribuye desde la tienda. ### Comprobaciones en Android y AOSP #### Versión de la política **La versión de la política aún no se ha enviado al dispositivo** significa que el dispositivo sigue funcionando con una versión anterior a la asignada. En Android la comprobación muestra la **política actual** y la **política deseada**, cada una con su versión, así que la diferencia se ve de un vistazo. En AOSP solo se muestra la actual. Normalmente se resuelve solo en la siguiente sincronización. Si persiste, el dispositivo está desconectado o no puede aplicar alguno de los ajustes — en cuyo caso verás además una comprobación a nivel de ajuste indicando cuál. #### Fallos a nivel de ajuste Este es el bloque que responde a *"qué ajuste ha fallado y por qué"*. Cada comprobación está **titulada con el motivo** y se despliega con el detalle: | Campo | Qué te dice | | --- | --- | | **Paquete** | La app a la que afecta el problema, cuando afecta a alguna. | | **Campo** | El ajuste exacto, o la ruta precisa del campo dentro de él en los ajustes con campos anidados. | | **Motivo** | Una explicación más concreta cuando existe: un fallo de instalación de app, o un motivo específico de contraseña o de Wi-Fi. Se muestra en naranja. | | **Valor actual** | Lo que el dispositivo tiene realmente, cuando el ajuste no se ha podido aplicar. | | **WiFi GUID** | La configuración de red concreta afectada, en los problemas de Wi-Fi. | Esa combinación es la que hace útil el bloque en soporte: no obtienes *"el dispositivo no es conforme"*, sino el campo, el motivo y lo que el dispositivo tiene en su lugar. Dos de ellos merecen una nota: - **Los problemas de contraseña** añaden el ámbito entre paréntesis: si el requisito aplica a todo el dispositivo o solo al perfil de trabajo. En dispositivos donde ambos van por separado, esa es la diferencia entre que el usuario cambie la contraseña correcta o la equivocada. - **Los fallos de instalación de apps** son donde el campo *Motivo* se gana su sitio. Distingue una instalación aún en curso de una app que no está aprobada, que se ha quedado sin licencias, que no está disponible en el país del usuario o que no es compatible con el dispositivo — y cada una se resuelve de forma completamente distinta. #### Postura de seguridad En Android, un dispositivo cuya postura esté en riesgo aparece como una comprobación en rojo, titulada **En riesgo** o **Potencialmente comprometido**, con el riesgo detectado y el consejo de Google para mitigarlo. Es la comprobación que hay detrás del escudo rojo y la única que no trata sobre tu configuración. Consulta [Postura de seguridad del dispositivo](https://docs.applivery.com/es/device-management/android/security-posture/). ### Las comprobaciones informan, no aplican Nada de esta vista bloquea un dispositivo ni lo borra por sí solo. Actuar sobre lo que encuentres es una decisión aparte: - **Comandos remotos** desde el panel, para una respuesta puntual sobre un dispositivo concreto. - **[Policy Enforcement Rules](https://docs.applivery.com/es/device-management/android/policies/enforcement-rules/)** en Android, para bloquear y después borrar automáticamente pasados unos días. Reaccionan justo a los fallos a nivel de ajuste de más arriba, y no tienen equivalente en Apple. - **[Reglas de automatización](https://docs.applivery.com/es/device-management/general-settings/automation-rules/)**, para aplicar automáticamente una política distinta a una [audiencia de dispositivos](https://docs.applivery.com/es/device-management/general-settings/device-audiences/). --- ## Creación de políticas Source: https://docs.applivery.com/es/device-management/general-settings/create-policies/ Description: Las políticas de dispositivos en Applivery definen cómo configurar, proteger y controlar dispositivos Apple, Android y Windows de forma centralizada. TL;DR: Crea y gestiona políticas de dispositivos en Applivery para configurar, proteger y controlar tu flota de dispositivos Apple, Android y Windows. Answers: ¿Qué son las políticas de dispositivos de Applivery? · ¿Qué plataformas soportan las políticas de dispositivos de Applivery? · ¿Cómo se crea una nueva política de dispositivos en Applivery? · ¿Qué tipos de configuraciones se pueden establecer en una política de Applivery? · ¿Se puede usar una plantilla para crear una política de dispositivos en Applivery? · ¿Cómo se asigna una política de dispositivos a un dispositivo en Applivery? · ¿Cuáles son los beneficios de usar políticas de dispositivos en Applivery? Key topics: Creación de políticas de dispositivos, Configuración de políticas MDM, Asignación de políticas a dispositivos, Gestión unificada de dispositivos, Seguridad y control de flotas, Applivery, Apple, Android, Windows, MDM, Modo quiosco Las **políticas de dispositivos** son el elemento central de la gestión de MDM en Applivery. Definen cómo se configuran, protegen y controlan los dispositivos, permitiendo a las organizaciones aplicar de forma centralizada **ajustes**, **restricciones**, **apps** y **medidas de seguridad** en toda su flota. Aunque cada sistema operativo tiene sus propias capacidades y limitaciones, el flujo de trabajo de creación de políticas sigue la misma lógica para Apple, Android y Windows. Este enfoque unificado facilita la gestión de entornos heterogéneos, al tiempo que aprovecha las características específicas de cada plataforma. ### Qué es una política Una política es un conjunto de configuraciones que definen cómo se comporta un dispositivo una vez que está gestionado. Dependiendo de la plataforma, una política puede incluir restricciones del sistema, ajustes de seguridad como códigos de acceso o cifrado, reglas de instalación de apps, scripts o acciones automatizadas, integraciones con servicios de seguridad e incluso configuraciones de modo quiosco. Las políticas se asignan a dispositivos individuales o a grupos de dispositivos, lo que permite una gestión escalable, flexible y dinámica a medida que tu entorno crece o cambia. ### Plataformas compatibles Applivery soporta políticas específicas de plataforma para los siguientes sistemas operativos: - Apple (iOS, iPadOS, macOS). - Android. - Windows. Cada política se dirige a una única plataforma, ya que las capacidades de gestión y las opciones de configuración difieren entre los sistemas operativos. ### Cómo crear una nueva política Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), navega a la sección **Políticas** 1 y haz clic en el botón **\+ Crear Política** 2. ![create policy](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/2bd75ccd-14d3-4e59-8620-bda5c3bd38a3.png) Elige el **sistema operativo** 3 al que se aplicará la política: Apple, Android o Windows. **Una política solo puede asociarse a una plataforma**. Asigna a la política un **nombre claro y descriptivo** 4 que refleje su propósito o público objetivo. Las convenciones de nomenclatura coherentes facilitan mucho el mantenimiento y la escalabilidad a largo plazo. Applivery te permite crear políticas de dos 5 maneras diferentes: - Una política vacía, que comienza desde cero y es ideal para entornos altamente personalizados. - Una política basada en plantilla, disponible para Apple, Android y Windows. Las plantillas cubren casos de uso comunes como el modo quiosco de una o varias apps, la aplicación de contraseñas seguras, la configuración de Wi-Fi o las configuraciones de dispositivos restringidos. El uso de plantillas acelera la creación de políticas y aplica los ajustes predeterminados recomendados. ![policy form](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/e635edde-ca09-4ec4-9fdd-c1268f173959.png) #### Configuración de la política Después de crear la política, puedes añadir configuraciones basadas en la plataforma seleccionada. Para dispositivos Apple, esto incluye ajustes de código de acceso y bloqueo automático, restricciones del sistema, perfiles de configuración, scripts, apps y libros, ajustes de red y controles de seguridad. Para Android, las políticas pueden incluir configuraciones de modo quiosco, restricciones del sistema, acciones de configuración, apps gestionadas, ajustes de seguridad y configuraciones de red. Para Windows, las opciones disponibles incluyen scripts, instalación de apps, configuraciones de seguridad, restricciones del sistema y gestión de actualizaciones. #### Asignación de una política a dispositivos Una vez configurada la política, se puede asignar directamente desde el panel de políticas. Haz clic en **\+ Asignar a un dispositivo** 6, selecciona el dispositivo o los dispositivos de destino y confirma la asignación. La política se aplicará automáticamente. ![assign policy to device](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/dd7a4886-edeb-43ea-a18f-adec64d00793.png) Las políticas de Applivery proporcionan una forma unificada, flexible y escalable de gestionar dispositivos Apple, Android y Windows. Definir cuidadosamente la plataforma, seleccionar el tipo de política adecuado y asignar las políticas a los dispositivos correctos es esencial para mantener un entorno seguro, fiable y fácil de gestionar. Una estrategia de políticas bien diseñada reduce los errores operativos, refuerza la seguridad y apoya el crecimiento a largo plazo de tu implementación de MDM. :::tip El uso de plantillas de políticas puede acelerar significativamente el proceso de creación de políticas y garantizar que se sigan las mejores prácticas. ::: --- ## Audiencias de dispositivos Source: https://docs.applivery.com/es/device-management/general-settings/device-audiences/ Description: Crea audiencias de dispositivos dinámicas en Applivery con grupos de filtros ALL/ANY basados en etiquetas, dispositivos, empleados, números de serie, atributos inteligentes y segmentos. TL;DR: Crea audiencias de dispositivos con un árbol de filtros ALL/ANY, grupos anidados y operadores de exclusión, y comprueba el resultado en la vista previa de dispositivos coincidentes. Answers: ¿Qué es una audiencia de dispositivos en Applivery? · ¿Qué diferencia hay entre ALL y ANY en una audiencia de dispositivos? · ¿Puedo combinar lógica Y y O en la misma audiencia de dispositivos? · ¿Cómo excluyo dispositivos de una audiencia de dispositivos? · ¿Qué tipos de filtro puedo usar en una audiencia de dispositivos? · ¿Cómo compruebo qué dispositivos coinciden con mi audiencia antes de guardar? · ¿Qué pasa con las audiencias de dispositivos creadas antes del editor de árbol de filtros? · ¿Tengo que cambiar mis reglas de automatización con el nuevo editor de audiencias? Key topics: Creación de audiencias de dispositivos, Grupos ALL y ANY, Tipos de filtro y operadores, Grupos anidados, Vista previa de dispositivos coincidentes, Audiencias migradas, Integración con reglas de automatización, Applivery, Audiencias de dispositivos, Reglas de automatización, Atributos inteligentes, Segmentos Una **audiencia de dispositivos** es un grupo guardado de dispositivos. Define quién forma parte de ella mediante filtros, y su pertenencia se actualiza automáticamente a medida que cambian los datos de dispositivos y empleados. Las audiencias de dispositivos te permiten dirigir **políticas**, **configuraciones** y **despliegues** exactamente a los dispositivos adecuados **a través de las reglas de automatización**. :::info Puedes obtener más información sobre las **reglas de automatización** siguiendo este [enlace](https://docs.applivery.com/es/device-management/general-settings/automation-rules/). ::: ### Cómo funcionan las audiencias de dispositivos Una audiencia de dispositivos se define mediante un árbol de **filtros** y **grupos**: - Un **filtro** es una única condición, por ejemplo _Tag de dispositivo es alguna de madrid_ - Un **grupo** es un conjunto de filtros y/o grupos anidados, unidos por **TODAS** o **ALGUNA**.

Etiqueta

Lógica

Qué significa

Qué ves en el árbol

TODAS

Y (AND)

Deben cumplirse todos los filtros o grupos anidados de este grupo.

Una insignia TODAS en la cabecera del grupo y conectores Y entre sus elementos.

ALGUNA

O (OR)

Debe cumplirse al menos un filtro o grupo anidado de este grupo.

Una insignia ALGUNA en la cabecera del grupo y conectores O entre sus elementos.

Este enfoque flexible y basado en reglas garantiza que las audiencias se ajusten automáticamente a medida que cambian los atributos de los dispositivos o los empleados, manteniendo tus configuraciones actualizadas sin intervención manual. #### Grupos anidados Añade un grupo dentro de otro cuando una parte de tu lógica necesite una unión distinta a la de su grupo padre; por ejemplo, un grupo exterior **ALGUNA** que contiene un grupo interior **TODAS**. Los grupos anidados siguen visibles en el árbol, así que ves toda la lógica de un vistazo. ![nested operators](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/72d44108-d2ba-43d1-abab-a1eb773a1bea.png) - **Grupo exterior**: une sus filtros y grupos anidados. - **Grupo anidado**: tiene su propia unión **TODAS** o **ALGUNA**. - **+**: añade filtros u otros grupos dentro del grupo anidado. No hay límite en el número de grupos que puedes anidar. Aun así, intenta que el árbol sea lo más plano posible y anida solo cuando necesites mezclar Y y O: la audiencia será más fácil de leer y mantener. ### Creación de una audiencia de dispositivos Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), navega a la sección de **Automatización** 1. Selecciona **Audiencias de dispositivos** 2 y haz clic en el botón **\+ Crear Audiencia de dispositivos** 3, o abre una audiencia existente para editarla. ![device audiences](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/e93dbd52-8d9b-44d0-8907-9cbcadb6c109.png) El formulario de configuración incluye las siguientes secciones, todas en la misma página: ![configuration](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/f54b8a20-58d6-40d4-aaf2-0ebc7a7edf19.png) #### Configuración - **Nombre**: introduce un nombre descriptivo para la audiencia. - **Descripción** (opcional): añade contexto sobre el propósito de la audiencia. #### Selección de dispositivos **Selección de dispositivos** es el editor en árbol donde añades filtros y grupos. Empieza con un único grupo raíz configurado como **TODAS** o **ALGUNA debe cumplirse**. 1. Usa el control **TODAS / ALGUNA** para elegir cómo se unen los elementos del grupo raíz. 2. Haz clic en **Nuevo filtro** o en el control **+**. 3. En el menú **+**, selecciona **Añadir filtro** para añadir una condición o **Añadir grupo** para añadir un grupo anidado. ![popover](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/72ec26c2-0167-434c-a847-1a9cbe668ca0.png) 4. En **Elige por qué filtrar**, elige un tipo de filtro: **Tag de dispositivo**, **Tag de empleado**, **Dispositivo**, **Empleado de dispositivo**, **Número de serie**, **Atributo inteligente** o **Segment**o. ![filter by](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/f765fa16-f4af-46e2-b083-dffc56a68be0.png) 5. En el panel **Editar filtro**, define la condición (operador) y los valores. Puedes hacer clic en cualquier filtro para volver a abrir **Editar filtro**. Si has elegido un tipo de filtro equivocado, haz clic en **Cambiar tipo**, arriba a la derecha de **Editar filtro**, para cambiar esa fila a otro tipo sin tener que borrarla y empezar de cero. ![change type](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/e8a8d7db-ef91-4da3-bcaa-e5b12cc96955.png) :::info El pie bajo **Selección de dispositivos** te recuerda que solo pueden coincidir los dispositivos del segmento en el que se crea la audiencia y de sus segmentos hijos. Este es el ámbito de la propia audiencia y es independiente del filtro **Segment** que puedes añadir dentro del árbol. ::: #### Vista previa de dispositivos coincidentes Mientras editas, el panel **Matched devices preview** de la derecha muestra una lista en directo, con recuento, de los dispositivos que cumplen en ese momento todo el árbol de la audiencia. ![any with two filters](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/c6eaaa30-4ad3-4d3a-871b-561aaeb95f57.png) - **Filtros**: las condiciones que has creado en **Selección de dispositivos**. - **Recuento**: el número total de dispositivos que coinciden en este momento. - **Seleccionado por**: columna que indica qué filtro hizo que cada dispositivo coincidiera. Usa esta vista previa para confirmar que tus filtros funcionan como esperas antes de guardar. Si no aparece ningún dispositivo, revisa los operadores y los valores. ### Trabajar con grupos y filtros #### Grupos Selecciona la fila de un grupo para mostrar su barra de herramientas en la cabecera. Desde ahí puedes: ![preview matched devices](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/7d61ae05-1a4b-4246-99ac-1a1c1bf477cc.png) - **Mover**: arrastra el grupo o usa la flecha para subirlo o bajarlo dentro de su grupo padre. - **Cambiar TODAS / ALGUNA**: cambia cómo se unen los elementos de ese grupo. - **Visualizar**: haz clic en el icono del ojo para ver los dispositivos que cumplen solo este grupo. No sustituye a la vista previa de toda la audiencia. - **Eliminar**: haz clic en el icono de la papelera para borrar el grupo. Cuando aparece el control para contraer, también puedes contraer el grupo para ocultar sus elementos. #### Filtros Selecciona la fila de un filtro para mostrar su barra de herramientas. Desde ahí puedes: ![preview matched devices device employee](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/0c11b1c7-9bf4-4baf-a65e-9acfcfe158d1.png) - **Editar**: haz clic en el filtro para abrir **Edit filter** y cambiar el campo, el operador o los valores. - **Mover**: sube o baja el filtro entre los demás elementos del mismo grupo. - **Visualizar**: haz clic en el icono del ojo para ver los dispositivos que cumplen este filtro. - **Eliminar**: haz clic en el icono de la papelera para borrar el filtro. ### Tipos de filtro y operadores Los operadores de exclusión, como **is none of**, te permiten dejar dispositivos fuera de la audiencia directamente desde el árbol. #### Tag de dispositivo Selecciona dispositivos según sus etiquetas. - **Es alguno de**: el dispositivo tiene al menos una de estas etiquetas. - **No es ninguno de**: el dispositivo no tiene ninguna de estas etiquetas. - **Contiene**: alguna etiqueta del dispositivo contiene este texto. ![device tag condition](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/2d4bedec-f92e-4bd9-82b8-db7b71cdb95c.png) #### Tag de empleado Selecciona dispositivos según las etiquetas del empleado asignado. - **Es alguno de**: el empleado tiene al menos una de estas etiquetas. - **No es ninguno de**: el empleado no tiene ninguna de estas etiquetas. ![employee tag](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/c2296e00-bae0-44fe-a81a-6d5724e31d26.png) #### Dispositivo Selecciona dispositivos concretos. Primero elige la plataforma (**Apple**, **Android**, **AOSP** o **Windows**) y después la condición: - **Es alguno de**: el dispositivo es uno de los seleccionados. - **No es ninguno de**: el dispositivo no es ninguno de los seleccionados. ![apple is](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/3fca86a1-c352-4c06-8117-ddea04f6f24c.png) #### Empleado del dispositivo Selecciona dispositivos según el empleado asignado. - **Es alguno de**: el dispositivo pertenece a uno de estos empleados. - **No es ninguno de**: el dispositivo no pertenece a ninguno de estos empleados. ![device employee](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/d6d3b441-757c-45ef-a4d7-22f77789fade.png) #### Número de serie Selecciona dispositivos por número de serie. - **Es alguno de**: el número de serie es uno de los valores que introduces. - **No es ninguno de**: el número de serie no es ninguno de esos valores. Los números de serie deben coincidir **exactamente y distinguen entre mayúsculas y minúsculas**, tal y como se indica en **Editar filtro**. ![serial number](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/b1fab5c1-9845-4ef4-a709-f96b02835eb4.png) #### Atributo inteligente Selecciona dispositivos según el valor de un [atributo inteligente](https://docs.applivery.com/es/device-management/general-settings/smart-attributes/). Elige primero el atributo: las opciones del desplegable **Condición** dependen del tipo de atributo (texto, número, fecha, booleano o enumerado), así que no todos los atributos ofrecen los mismos operadores. ![smart attribute](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ad9a1c53-5331-462f-863c-615cab2b7e55.png) Segmento Selecciona dispositivos según el [segmento](https://docs.applivery.com/es/device-management/general-settings/segments/) al que pertenecen. - **Es solo este segmento:** el dispositivo está en este segmento, no solo en uno de sus segmentos hijos. - **Es uno de**: el dispositivo está en uno de los segmentos seleccionados. ![segment](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/de4d74e9-7f4a-416d-b548-d48b7ee7cd8f.png) ### Ejemplos #### Dispositivos con una etiqueta Un grupo sencillo de dispositivos por ubicación o plataforma: - **TODAS** raíz - **Device tag** is any of `madrid` #### Despliegue con una exclusión Dirígete a los dispositivos etiquetados para un despliegue, pero deja fuera los dispositivos VIP: - **TODAS** raíz - **Tag de dispositivo** es alguna de `shipping` - **Tag de dispositivo** es alguna de `vip` Puedes usar el mismo patrón con **Dispositivo** no es ninguno para dejar fuera de la audiencia dispositivos concretos. #### Lógica combinada con segmento Incluye los dispositivos de un empleado concreto, todos los dispositivos con la etiqueta Android, o una lista de dispositivos Apple que estén directamente en el segmento Global: - **ALGUNA** raíz - **Tag de empleado** es alguna de `user@company.com` - **Tag de empleado** es alguna de `android` - **TODAS** anidado - **Dispositivo** (Apple) es uno de _\[tu lista de dispositivos\]_ - **Segmento** es solo este segmento `Global` ### Audiencias migradas Las audiencias de dispositivos creadas antes del editor de árbol de filtros se **migran automáticamente**. No tienes que volver a crearlas. Al abrir una audiencia migrada, su pertenencia aparece como filtro en **Selección de dispositivos**; por ejemplo, **Tag de dispositivo es** `windows` dentro del ámbito del segmento Windows. La **vista previa de dispositivos coincidentes** funciona igual que en las audiencias nuevas. ![migrated audience](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/7fb84372-5d71-41f4-9996-821a485f8778.png) La migración conserva la pertenencia original de la audiencia. Si una audiencia es crítica, revisa la **vista previa de dispositivos coincidentes** la primera vez que la abras. ### Audiencias de dispositivos y reglas de automatización Las [reglas de automatización](https://docs.applivery.com/es/device-management/general-settings/automation-rules/) siguen seleccionando una audiencia de dispositivos exactamente igual que antes, igual que otras funciones que usan audiencias, como la asignación de atributos inteligentes. No hay ningún paso nuevo que configurar dentro de las reglas de automatización: defines y actualizas la pertenencia en la propia audiencia, y todas las reglas que la usan recogen el cambio. :::info Las audiencias de dispositivos son dinámicas: una vez creadas, se actualizan continuamente según los datos más recientes de dispositivos y empleados. Así, tus políticas y configuraciones se mantienen alineadas con la estructura actual de tu organización. ::: --- ## Estados de dispositivo Source: https://docs.applivery.com/es/device-management/general-settings/device-states/ Description: Qué significa "inactivo" en Applivery, qué refleja realmente el campo Last report y qué valor mirar cuando necesitas actividad real del dispositivo. TL;DR: Inactivo significa que no ha reportado en 5 días. Last report es una marca temporal de reporte, no un indicador de conectividad. Answers: ¿Por qué mi dispositivo aparece como inactivo? · ¿Qué significa Last report en Applivery? · ¿Cómo compruebo si un dispositivo está realmente conectado? Key topics: Dispositivos inactivos, El campo Last report, Leer actividad real del dispositivo, Applivery, Android Device Policy, Google Un dispositivo aparece como **inactivo** y lo primero que se piensa es que está apagado, sin cobertura o roto. Normalmente no es ninguna de las tres, y la confusión viene de leer dos cosas distintas como si significaran lo mismo. ### Qué significa inactivo Un dispositivo se marca como inactivo cuando **no ha reportado en los últimos 5 días**. Esa es toda la regla. Dice algo sobre el reporte, no sobre la conectividad. ### Qué refleja realmente Last report El campo **Last report** muestra la última vez que **Android Device Policy** envió un informe de estado. Quien decide cuándo ocurre eso es Google, no Applivery, y no ocurre a intervalos fijos: el informe sale cuando se detecta un cambio relevante. :::warning **Last report no es un indicador de conectividad.** Un dispositivo puede estar conectado, en uso y perfectamente sano, y aun así mostrar un Last report antiguo simplemente porque no ha cambiado nada que mereciera reportarse. ::: ### Qué mirar para ver actividad real La marca temporal de la **última ubicación reportada** la genera el agente de Applivery y no Google, así que sí refleja actividad real del dispositivo. Por API, el endpoint de detalle de dispositivo expone los valores que conviene mirar:

Campo

Qué te dice

sync

Última sincronización con la política.

agent.location

Última ubicación reportada por el agente de Applivery.

agent.lastReportDate

Cuándo reportó el agente por última vez.

Si un dispositivo Android realmente no está reportando, la causa habitual es que la capa de batería del fabricante esté suspendiendo el agente — consulta [El agente deja de reportar](https://docs.applivery.com/es/device-management/android/troubleshooting/agent-not-reporting/). --- ## Distribución de recursos Source: https://docs.applivery.com/es/device-management/general-settings/distribute-resources/ Description: Despliega apps, scripts, archivos y certificados en dispositivos Android, Windows y Apple con Applivery, en bloque mediante políticas o individualmente. TL;DR: Applivery simplifica la distribución de recursos a dispositivos gestionados (Android, iOS, Windows, macOS) mediante políticas o asignación directa, permitiendo el despliegue eficiente de apps, Scripts y certificados. Answers: ¿Qué tipos de recursos puede implementar Applivery en dispositivos gestionados? · ¿Qué sistemas operativos soporta la Gestión de Dispositivos de Applivery? · ¿Cómo puedo implementar recursos en dispositivos usando Applivery? · ¿Qué tipos de Scripts se soportan para el despliegue con Applivery? · ¿Qué formatos de app se soportan para el despliegue con Applivery? · ¿Qué formatos de certificado soporta Applivery? · ¿Cómo subo recursos al panel de Applivery? · ¿Puedo implementar imágenes en dispositivos Android usando Applivery? Key topics: Tipos de recursos soportados por Applivery, Métodos de distribución de recursos (políticas, asignación directa), Subida de recursos al panel de Applivery, Adición de recursos a políticas, Asignación de recursos a dispositivos, Applivery, Android, Windows, macOS, iOS, iPadOS, Bash, PowerShell, Agente MDM de Applivery La Gestión de Dispositivos de Applivery te permite implementar una amplia gama de recursos —como apps, scripts, archivos, certificados y otros activos— en tus dispositivos gestionados, incluyendo plataformas Android, Windows y Apple (macOS, iOS y iPadOS). La distribución se puede realizar de forma masiva a través de políticas o individualmente por dispositivo, lo que te proporciona total flexibilidad y control. :::warning Estas funciones requieren que el **agente MDM de Applivery** esté habilitado en la política del dispositivo. ::: ### Tipos de recursos

Tipo de Recurso

Descripción

Scripts

Automatiza tareas operativas y configuraciones del sistema implementando Scripts bash para macOS y Scripts powerShell para Windows.

Apps

Implementa aplicaciones personalizadas o de terceros para asegurar que los empleados de los dispositivos tengan acceso a las herramientas que necesitan. Los formatos soportados incluyen .ipa, .pkg, .msi, .msix, .appx y .apk.

Libros

Implementa documentos en una variedad de formatos, incluyendo .pdf, .epub, .rtf, .rtfd y .txt, para asegurar la compatibilidad y accesibilidad en todos los dispositivos.

Imágenes

Implementa imágenes en formato .jpg o .png.

Certificados

Implementa certificados para asegurar las conexiones de los dispositivos, soportando formatos como .p12, .der, .pem, .crt y .cer.

Proveedores de certificados

Configúralos para automatizar la emisión y gestión del ciclo de vida de los certificados. Esto permite a los dispositivos solicitar y renovar certificados dinámicamente a través de autoridades de identidad o de certificados integradas, mejorando la seguridad y reduciendo la sobrecarga administrativa manual.

:::info Los libros solo están disponibles para **dispositivos iOS**. Para entornos de iPad compartido, los libros solo se pueden asignar a **cuentas de usuario**, no directamente a dispositivos. ::: :::info La implementación de imágenes en dispositivos Android no está disponible actualmente. La importación de contactos no está soportada actualmente. ::: :::info La importación de contactos no está soportada actualmente. ::: ### Distribución de recursos Dependiendo del sistema operativo y el tipo de activo, Applivery te permite definir cómo se entregan los recursos: - **Despliegue a nivel de usuario** (cuando esté soportado): dirigido al usuario principal o conectado del dispositivo. - **Despliegue a nivel de dispositivo** (en todo el sistema): aplica activos a nivel de máquina, independientemente de las sesiones de usuario. - **Despliegue basado en políticas**: distribuye activos automáticamente a todos los dispositivos asignados a una política específica. - **Asignación directa a dispositivos**: aplica activos individualmente a los dispositivos seleccionados. Esta flexibilidad permite despliegues personalizados basados en la estructura de tu organización, los requisitos de cumplimiento y las necesidades operativas. #### Subida de recursos al panel de Applivery Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), navega a **Recursos**. Utiliza el menú de la izquierda para elegir el tipo de activo que deseas cargar. Luego, simplemente haz clic en el botón de subida para añadir tu recurso a tu Workspace. ![resources section](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/20661682-7656-43c0-828d-56f93d0ee268.png) #### Añadir recursos a políticas Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), navega a **Políticas** 1. Elige la política a la que te gustaría añadir un recurso. Luego, desde el menú de la izquierda, haz clic en **Recursos** 2 y selecciona el botón **\+ Añadir Recurso** 3 para iniciar el proceso de carga. ![add resource](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/8d9da070-d31a-4fe0-b925-91120d6f9a75.png) Aparecerá una ventana modal donde podrás seleccionar el tipo de recurso que deseas asignar a la política. Puedes elegir subirlo desde la sección de **Recursos** (si lo has subido previamente) o directamente desde tu máquina. Además, podrás seleccionar el ámbito de despliegue y especificar la ubicación donde se almacenará el recurso en los dispositivos donde se aplique la política. #### Asignación de recursos a dispositivos Si no deseas realizar un despliegue masivo a través de una política, también tienes la opción de asignar recursos individualmente a cada dispositivo. Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), navega a **Dispositivos** y selecciona el dispositivo donde deseas añadir el recurso. :::info Ten en cuenta que los tipos de recursos que puedes asignar dependen del dispositivo, como se explicó anteriormente. ::: --- ## Variables dinámicas Source: https://docs.applivery.com/es/device-management/general-settings/dynamic-variables/ Description: Las variables dinámicas de Applivery personalizan configuraciones de dispositivos, scripts y políticas con datos específicos de usuario y dispositivo. TL;DR: Las etiquetas de interpolación de Applivery personalizan configuraciones de dispositivos y automatizan despliegues, reemplazando dinámicamente marcadores con datos específicos de usuario y dispositivo. Answers: ¿Qué son las etiquetas de interpolación de Applivery? · ¿Cómo se utilizan las variables dinámicas en Applivery? · ¿Qué información de dispositivo puedo acceder con etiquetas de interpolación? · ¿Qué información de usuario puedo usar con etiquetas de interpolación? · ¿Cómo puedo crear un contador incremental único con ceros iniciales? · ¿Cuál es el propósito de la etiqueta `{{incremental}}`? · ¿Cómo utiliza Applivery las etiquetas de interpolación durante el despliegue? Key topics: Etiquetas de interpolación, Variables dinámicas, Configuración de dispositivos, Panel de Applivery, Variables admitidas, Applivery, Apple Silicon Applivery admite un conjunto de **etiquetas de interpolación**, también conocidas como **variables dinámicas**, que permiten a los administradores personalizar y adaptar automáticamente los perfiles de configuración de dispositivos, los scripts, las inscripciones inteligentes y las políticas con datos específicos del usuario o del dispositivo. Estas etiquetas se reemplazan dinámicamente en el momento del despliegue, lo que permite a las organizaciones ofrecer configuraciones flexibles y conscientes del contexto en todos los dispositivos gestionados sin necesidad de entrada manual. ### ¿Qué son las etiquetas de interpolación? Las **etiquetas de interpolación** son marcadores que se pueden inyectar dentro de los valores de configuración. Cuando un perfil, una política o un script se despliega en un dispositivo, Applivery reemplaza automáticamente cada etiqueta con el valor real correspondiente recuperado del registro del dispositivo o del usuario. Esto permite a los administradores de TI automatizar despliegues personalizados a escala, optimizando la gestión de la configuración y minimizando el error humano. En el **panel de Applivery**, todos los campos y áreas de entrada que admiten interpolación (excepto los que se encuentran dentro de scripts) están marcados con el símbolo de interpolación: ![interpolation-symbol](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ad70e326-b435-4d27-8483-961be40d6d00.png) :::info Los campos sin este indicador visual no admiten interpolación y tratarán cualquier entrada como texto sin formato, dependiendo del tipo de campo específico. ::: Cuando una configuración o un script se despliega en un dispositivo, Applivery reemplaza automáticamente cada variable de interpolación con su valor real correspondiente del registro del dispositivo o del usuario. Este proceso optimiza la gestión de grandes flotas de dispositivos al aplicar automáticamente configuraciones personalizadas a cada endpoint. ![interpolation-input](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/83188411-c739-4ca7-bfd3-da4dd4554975.png) ### Variables de interpolación admitidas

Variable

Descripción

Formato

{{device.id}}

Identificador único del dispositivo.

String

{{device.displayName}}

Nombre de visualización del dispositivo (según configuración en Applivery).

String

{{device.serialNumber}}

Número de serie de hardware del dispositivo.

String

{{device.osVersion}}

Versión del sistema operativo instalada en el dispositivo.

String

{{device.chip}}

Información del procesador o chipset del dispositivo.

String

{{device.isAppleSilicon}}

Booleano que indica si el dispositivo utiliza Apple Silicon.

true/false

{{device.hostName}}

Nombre de host informado por el dispositivo.

String

{{device.udid}}

UDID único asignado al dispositivo.

String

{{user.id}}

Identificador único de empleado de Applivery.

String

{{user.email}}

Dirección de correo electrónico del empleado de Applivery.

String

{{user.name}}

Nombre completo del empleado de Applivery.

String

{{user.metadata.PROPERTY}}

Valor de metadatos personalizado para el empleado de Applivery.

String

{{incremental}}

Contador incremental global para despliegues, que comienza en 1.

1,2,3, n…

{{incremental:N}}

Contador incremental de longitud fija con N ceros iniciales (N = 1–10), útil para generar etiquetas únicas.

N=1 (01,02,03…), N2 = (001, 002, 003…), etc.

--- ## Composición de políticas Source: https://docs.applivery.com/es/device-management/general-settings/policy-composition/ Description: La composición de políticas en Applivery permite aplicar múltiples políticas a un dispositivo para un control granular, seguridad y escalabilidad mejoradas. TL;DR: La composición de políticas permite a los administradores aplicar múltiples políticas a un único dispositivo para una gestión de configuración flexible y granular. Answers: ¿Qué es la composición de políticas en Applivery? · ¿Cuáles son los beneficios clave de usar la composición de políticas? · ¿Qué es un conjunto de composición? · ¿Cómo resuelve Applivery los conflictos entre políticas? · ¿Cómo se asignan las políticas a los dispositivos usando la composición de políticas? · ¿Cómo funciona la prioridad de las políticas en dispositivos Apple? · ¿Cómo funciona la prioridad de las políticas en dispositivos Android? · ¿Cuál es una buena práctica para asignar prioridades a las políticas? Key topics: Conceptos de composición de políticas, Limitaciones del modelo de política única, Capas y prioridad de políticas, Asignación de políticas y resolución de conflictos, Comportamiento específico de la plataforma, Applivery, Apple MDM, Android Enterprise, Windows MDM, iOS, iPadOS, macOS, Windows, Android A medida que las organizaciones expanden sus flotas de dispositivos, la demanda de configuraciones flexibles y modulares se vuelve cada vez más crítica. La **composición de políticas** aborda esta necesidad al permitir la aplicación de múltiples políticas a un único dispositivo. Esto permite a los administradores superponer configuraciones específicas, despliegues de apps y activos sin interferir con los ajustes generales existentes. Históricamente, el modelo de políticas de Applivery se basaba en una única política monolítica por dispositivo o grupo, que agrupaba todas las configuraciones, despliegues de aplicaciones y distribuciones de activos. Si bien era efectivo para entornos más simples, este enfoque a menudo limitaba la agilidad en escenarios dinámicos, como actualizaciones de cumplimiento dirigidas, asignaciones de aplicaciones basadas en roles o despliegues por fases, lo que frecuentemente requería recreaciones o sobrescrituras completas de políticas. Con la **composición de políticas**, Applivery introduce una arquitectura componible que trata las políticas como bloques de construcción reutilizables. Los administradores ahora pueden construir configuraciones de dispositivos apilando múltiples políticas, estableciendo prioridades según sea necesario y asignándolas o revocándolas dinámicamente. Este control granular no solo optimiza las operaciones administrativas, sino que también reduce la sobrecarga y mejora la seguridad, el cumplimiento y la escalabilidad en entornos empresariales. ### Terminología clave Comprender los términos clave a continuación es esencial para gestionar eficazmente las configuraciones de dispositivos utilizando la **composición de políticas** en Applivery: - **Política**: un conjunto configurable de reglas que definen el comportamiento del dispositivo, incluyendo restricciones, despliegues de apps, aprovisionamiento de activos (por ejemplo, certificados, perfiles de Wi-Fi) y comprobaciones de cumplimiento. - **Composición de políticas**: el método para aplicar múltiples políticas a un único dispositivo, con ajustes de prioridad opcionales para resolver conflictos. - **Conjunto de composición**: la colección completa de políticas asignadas a un dispositivo, que representa su configuración efectiva en un momento dado. ### El modelo de política única En las implementaciones tradicionales de Applivery, a cada dispositivo o grupo de dispositivos se le asignaba una **única política** que abarcaba todas las configuraciones, incluyendo: - **Configuraciones de dispositivos**: ajustes y restricciones, como requisitos de contraseña, acceso a la cámara y restricciones de red. - **Aplicaciones**: apps gestionadas desplegadas en dispositivos, incluyendo apps internas y aplicaciones de la **App Store** pública. - **Activos**: recursos como libros, certificados, fondos de pantalla u otros activos del dispositivo. Si bien era simple de gestionar en entornos pequeños, este modelo presentaba limitaciones en escenarios dinámicos o complejos. Por ejemplo, aplicar una política temporal, como una actualización de cumplimiento sensible al tiempo, a menudo requería crear una nueva política desde cero o modificar la existente, lo que podría sobrescribir involuntariamente ajustes no relacionados. ### Introducción a la composición de políticas La **composición de políticas** proporciona un enfoque modular para la gestión de dispositivos al permitir que se apliquen múltiples políticas a un único dispositivo o grupo. Cada política puede centrarse en un aspecto específico del dispositivo (seguridad, despliegue de apps, marca u otras configuraciones), lo que permite a los administradores gestionar y actualizar los ajustes sin afectar a configuraciones no relacionadas. #### Componentes clave La **composición de políticas** se basa en tres conceptos fundamentales que brindan a los administradores flexibilidad y control sobre las configuraciones de los dispositivos: - **Capas de políticas**: cada política actúa como una capa independiente. Por ejemplo, una política base puede aplicar ajustes de seguridad generales (como cifrado y complejidad de la contraseña), una política departamental podría desplegar aplicaciones específicas de roles y una política temporal podría aplicar restricciones específicas de eventos, como habilitar la configuración de eSIM. - **Prioridad y resolución de conflictos**: cuando se aplican múltiples políticas, la vista previa de la composición de políticas de Applivery permite a los administradores ver la configuración resultante antes del despliegue. Los conflictos entre ajustes se resuelven según la prioridad asignada a cada política. - **Asignación dinámica**: las políticas se pueden asignar o revocar en tiempo real mediante reglas de automatización, lo que permite actualizaciones sin interrumpir las configuraciones existentes del dispositivo. #### Flujo de arquitectura El flujo de trabajo de la **composición de políticas** sigue estos pasos: **Creación de políticas** Los administradores definen políticas individuales en el **panel de Applivery**, especificando configuraciones, apps o recursos. **Asignación de políticas** Las políticas se asignan a dispositivos o grupos, opcionalmente con niveles de prioridad para controlar cómo se resuelven los conflictos. **Procesamiento de la composición** El servidor MDM de Applivery agrega las políticas asignadas en un conjunto de composición, asegurando que se respeten las prioridades. **Sincronización de dispositivos** La configuración compuesta se envía a los dispositivos utilizando protocolos específicos de la plataforma (Apple MDM, Android Enterprise, Windows MDM). **Monitorización y actualizaciones** Cualquier cambio en las políticas se propaga automáticamente, con registros de auditoría que rastrean las asignaciones y los conflictos. #### Guía de implementación ##### Disponibilidad La función de **composición de políticas** está disponible en todas las áreas donde anteriormente se podía asignar una única política. Esto incluye **enlaces de inscripción manual**, que permiten crear enlaces con múltiples políticas para la configuración inicial del dispositivo; **asignación directa de dispositivos**, donde las políticas se pueden aplicar directamente a dispositivos individuales; **inscripciones inteligentes**, que permiten aplicar políticas compuestas durante los flujos de trabajo de inscripción automatizada; y **reglas de automatización**, que permiten aplicar múltiples políticas basadas en la **audiencia del dispositivo**. ##### Asignación de políticas Al asignar políticas en cualquiera de estos escenarios, se abre una ventana modal mejorada, similar a la interfaz anterior de política única. Los administradores ahora pueden añadir múltiples políticas a un dispositivo o grupo y controlar el orden en que se aplican. Las políticas se pueden reordenar utilizando las flechas de la interfaz o asignando valores numéricos de prioridad, donde los números más bajos indican una mayor prioridad en la parte superior del conjunto de composición. Para abrir el modal desde un dispositivo, selecciona el dispositivo y fíjate en el **resumen del dispositivo**, a la izquierda. Al pasar el cursor sobre el campo **Políticas** aparece el icono de un lápiz: haz clic en él y se despliega el modal. La interfaz incluye varios elementos para facilitar la gestión. La **lista de políticas** 1 muestra todas las políticas asignadas, mientras que el campo **Prioridad** 2 permite a los administradores establecer el orden de aplicación. Las **interpolaciones** 3 muestran todas las variables dinámicas utilizadas en las políticas, y la opción **Vista previa** 4 permite revisar la configuración compuesta sin procesar antes del despliegue. Finalmente, el botón **Añadir política** 5 permite a los administradores incluir políticas adicionales en el conjunto. ![policy composition](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/bdc72b48-c51a-40e4-81a9-687b5bd8f7c6.png) #### Resolución de conflictos específica de la plataforma El comportamiento del conjunto de composición varía según la plataforma del dispositivo. :::info **El orden de prioridad y el resultado de un conflicto son dos cosas distintas**, y es fácil leerlas como si se contradijeran. El valor de prioridad define el **orden** en el que se aplican las políticas: los números más bajos van primero, arriba del conjunto de composición. Cuando dos de ellas configuran el mismo ajuste, el dispositivo se queda con el valor aplicado **en último lugar**, que es el que está más abajo en el conjunto. Dicho de otro modo: un número más bajo significa que la política se aplica antes, no que su valor gane el conflicto. ::: **Apple** En los **dispositivos Apple** (iOS, iPadOS, macOS), las políticas se ejecutan secuencialmente según la prioridad, con los números más bajos teniendo precedencia. Por ejemplo, si tres políticas alternan el mismo ajuste, el dispositivo adopta el estado final de la última política en la secuencia. **Android** En los **dispositivos Android**, el orden de prioridad se mantiene de manera similar, pero en caso de ajustes conflictivos, la configuración más restrictiva surte efecto. **Windows** En los **dispositivos Windows**, las políticas también se ejecutan secuencialmente, respetando el orden de prioridad asignado. Esto importa sobre todo cuando una [configuración ADMX personalizada](https://docs.applivery.com/es/device-management/windows/policies/admx-configs/) define una ruta de registro que ya cubre una categoría integrada. Usa **Preview** antes de guardar para ver con qué valor se queda el dispositivo. #### Mejores prácticas Al utilizar la **composición de políticas**, asigna valores de prioridad claros para evitar conflictos y confusiones. :::tip Se recomienda probar las composiciones en un grupo piloto antes de desplegarlas ampliamente. ::: :::tip Revisa regularmente los registros de auditoría para monitorizar la aplicación de políticas y resolver cualquier conflicto. ::: :::tip Para una mejor organización, utiliza números de prioridad inferiores a 100 para las reglas de automatización y superiores a 100 para otras asignaciones de políticas, asegurando que las reglas de automatización siempre tengan mayor precedencia. ::: --- ## Segmentos Source: https://docs.applivery.com/es/device-management/general-settings/segments/ Description: Los segmentos de Applivery organizan dispositivos jerárquicamente, delegan roles y definen el alcance de políticas para un control granular y escalable. TL;DR: Los segmentos de Applivery estructuran y gestionan dispositivos jerárquicamente, delegan roles y definen el alcance de las políticas para una gestión eficiente. Answers: ¿Qué son los segmentos de Applivery y para qué se utilizan? · ¿Cómo se organizan los segmentos en Applivery? · ¿Cómo se relacionan los segmentos con la delegación de roles en Applivery? · ¿Cómo afectan los segmentos a la visibilidad en el panel de Applivery? · ¿Cómo se crea un nuevo segmento en Applivery? · ¿Cómo se crean permisos para un segmento en Applivery? · ¿Cómo funciona la asignación de dispositivos con los segmentos de Applivery? · ¿Cuál es la relación entre los segmentos y la asignación de políticas? Key topics: Jerarquía de segmentos, Control de Acceso Basado en Roles, Gestión de Políticas, Asignación de Dispositivos, Creación de segmentos, Applivery, Active Directory, LDAP, SAML, Dispositivos, Políticas Los segmentos son un componente estructural clave de la Gestión de Dispositivos de Applivery. Permiten a las organizaciones replicar su estructura operativa real —como regiones, departamentos, tiendas o unidades de negocio— dentro de la plataforma. En lugar de ser un simple mecanismo de filtrado, los **segmentos** definen límites administrativos, el alcance de la visibilidad y las reglas de gobernanza para dispositivos, políticas, recursos y automatizaciones. Al usar segmentos, las organizaciones pueden escalar la gestión de dispositivos manteniendo un control estricto sobre quién puede acceder y modificar partes específicas del entorno. A través de los segmentos, puedes: - Organizar dispositivos jerárquicamente. - Delegar roles y permisos con precisión. - Definir el alcance de la visibilidad de políticas, recursos y automatizaciones. - Construir escenarios de despliegue complejos manteniendo una gobernanza estricta. ### Qué es un segmento Un segmento es un contenedor lógico utilizado para agrupar y estructurar dispositivos dentro de un árbol jerárquico. Los segmentos pueden representar: - Regiones geográficas. - Unidades organizativas. - Dominios operativos. Cada segmento puede tener segmentos hijo, formando una estructura de árbol. Esta jerarquía permite la herencia de la visibilidad y el alcance administrativo de los niveles padre a los hijo. ![segments](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/42952a00-c2fc-482d-b80e-22780900e9e8.png) #### Estructura jerárquica Los segmentos se organizan en una estructura de padre-hijo. Los administradores asignados a un segmento de nivel superior pueden gestionar todos sus segmentos descendientes, mientras que los administradores asignados a un segmento de nivel inferior están restringidos a esa rama específica. Por ejemplo, un administrador regional puede tener control total sobre todas las tiendas dentro de su región. En contraste, un administrador a nivel de tienda solo puede gestionar dispositivos, políticas y configuraciones dentro de esa tienda. No puede acceder ni modificar configuraciones definidas a nivel regional o global. Este modelo jerárquico permite una gobernanza centralizada con una descentralización controlada. #### Delegación de roles basada en segmentos Cada segmento puede definir sus propios grupos de permisos y asignar roles como **administrador**, **editor** o **visualizador**, o un [rol de Colaborador personalizado](https://docs.applivery.com/es/platform/roles-permissions/custom-collaborator-roles/) con las acciones exactas que necesita cada puesto. Los usuarios pueden añadirse a estos grupos individualmente o dinámicamente a través de integraciones con proveedores de identidad (como SAML, LDAP o Active Directory). Esto permite a las organizaciones automatizar el control de acceso basado en atributos del directorio corporativo. Los permisos siempre se limitan al segmento asignado y sus descendientes. Los usuarios solo pueden editar, ver o gestionar elementos que caigan dentro de su alcance de segmento autorizado. Esto asegura una clara separación de responsabilidades entre equipos distribuidos. :::info Puedes encontrar más información sobre las integraciones con tu **Directorio Activo** siguiendo [este enlace](https://docs.applivery.com/es/platform/authentication/sso/saml/), o sobre el **estándar abierto LDAP** siguiendo [este enlace](https://docs.applivery.com/es/platform/authentication/sso/ldap/). ::: #### Segmentos en el panel de Applivery Los segmentos se aplican de forma consistente en todo el módulo de Gestión de Dispositivos. Al trabajar dentro de un segmento seleccionado en el panel de Applivery: - Los dispositivos se filtran según ese segmento. - Solo las políticas que pertenecen a ese segmento (y opcionalmente a sus descendientes) son visibles. - Los recursos y las reglas de automatización siguen la misma lógica de alcance. Cada elemento de la plataforma está asociado a un segmento específico. Esta asociación determina quién puede gestionarlo, no necesariamente qué dispositivos lo reciben. :::info Es importante distinguir entre el **alcance administrativo (definido por los segmentos)** y la **lógica de asignación de políticas (definida por la automatización y las audiencias)**. ::: #### Segmentos y asignación de dispositivos Cada dispositivo pertenece a un segmento específico. Esta asignación determina qué administradores pueden gestionar el dispositivo y qué configuraciones son visibles en su contexto. Sin embargo, la pertenencia a un segmento no define automáticamente qué políticas recibe un dispositivo. La entrega de políticas se controla a través de [reglas de automatización](https://docs.applivery.com/es/device-management/general-settings/automation-rules/) y [audiencias de dispositivos](https://docs.applivery.com/es/device-management/general-settings/device-audiences/). Los segmentos definen quién puede configurar esas reglas y políticas, no el resultado final de la configuración en sí. Esta separación garantiza la flexibilidad operativa al tiempo que preserva los límites de gobernanza. #### Políticas y prioridades Los segmentos permiten escenarios de despliegue avanzados cuando se combinan con grupos de identidad, audiencias de dispositivos, lógica de automatización y prioridad de políticas. Por ejemplo, un dispositivo ubicado en una tienda específica puede heredar una política global de referencia, una configuración regional y una personalización específica de la tienda. Si el dispositivo está asociado a un usuario que pertenece a un departamento particular, también pueden aplicarse políticas adicionales. La prioridad de las políticas asegura un comportamiento determinista en caso de superposición de configuraciones. Los segmentos definen la propiedad administrativa, mientras que la prioridad de las políticas define la resolución técnica. #### Reglas de visibilidad y herencia Los siguientes principios rigen el comportamiento de los segmentos: - Los administradores de nivel superior heredan la visibilidad sobre los segmentos de nivel inferior. - Los administradores de nivel inferior no pueden modificar las configuraciones de nivel padre. - Los derechos de edición siempre están restringidos al alcance asignado. - La visibilidad puede limitarse a un segmento específico o expandirse para incluir a sus descendientes. Este modelo soporta una gobernanza de nivel empresarial, lo que hace que los segmentos sean especialmente valiosos en organizaciones grandes o distribuidas. ### Alcance de la herencia: bloqueo de la herencia descendente Por defecto, las configuraciones y la visibilidad definidas en un segmento padre se propagan a través de toda la jerarquía: todos los segmentos hijo y descendientes pueden ver y verse afectados por lo que se define por encima de ellos. En la mayoría de los escenarios, este es el comportamiento deseado, pero hay casos en los que no lo es. El **alcance de la herencia** permite a los administradores marcar explícitamente un segmento como un límite que detiene la herencia descendente. Cuando se habilita en un segmento, las configuraciones, políticas y visibilidad definidas dentro de ese segmento se contienen en él, es decir, no se propagan a los segmentos hijo que se encuentran por debajo. #### Cuándo usar el alcance de la herencia Esto es particularmente útil en escenarios como: - **Unidades de negocio aisladas**: Una subsidiaria o unidad de negocio que comparte la plataforma pero debe operar de forma independiente, sin visibilidad hacia o desde ramas hermanas. - **Entornos de datos sensibles**: Un segmento que contiene dispositivos o configuraciones con requisitos de acceso restringido, donde los subsegmentos no deben poder acceder o heredar la configuración del padre. - **Estructuras de franquicia o multiinquilino**: Cada franquicia o inquilino tiene su propio segmento y no debe verse afectado por políticas definidas en un segmento vecino o padre, más allá de una línea base global establecida en el nivel raíz. - **Delegaciones con alcance**: Un escenario en el que un administrador tiene control total dentro de un segmento, pero ese control no debe extenderse más allá de lo previsto. #### Cómo funciona Cuando el alcance de la herencia está habilitado en un segmento: - Las políticas, recursos y configuraciones definidas dentro de ese segmento **no son visibles ni aplicables** a ningún segmento por debajo en la jerarquía. - Los administradores asignados a segmentos hijo del segmento con alcance **no pueden acceder ni heredar** lo que se ha definido a nivel de alcance. - El propio segmento con alcance sigue funcionando normalmente: sus administradores conservan plena visibilidad y control dentro de su alcance. - Los administradores de nivel superior (padre) **conservan la visibilidad** sobre el segmento con alcance como parte de su alcance más amplio, pero las configuraciones no fluyen hacia abajo a través de él. > **Ejemplo:** Considera una jerarquía estructurada como Global → Región → País → Tienda. Si el segmento País tiene habilitado el alcance de la herencia, cualquier configuración definida a nivel de País no se propagará a los segmentos de Tienda que se encuentren por debajo. Los administradores de Tienda solo verán y recibirán lo que se defina explícitamente a nivel de su propio segmento o se les envíe directamente, no lo que se configure a nivel de País. #### Alcance de la herencia vs. restricciones de rol Es importante no confundir el alcance de la herencia con las restricciones de acceso basadas en roles:

Alcance de la herencia

Restricción de rol

Qué controla

Si las configuraciones fluyen hacia abajo en la jerarquía.

Si un usuario puede acceder o editar un segmento.

Se aplica a

El propio segmento.

Usuarios dentro de un segmento.

Efecto en los segmentos hijo

Detiene la propagación descendente de configuraciones.

No tiene efecto en el flujo de configuraciones.

Caso de uso

Aislar el alcance de la configuración.

Controlar quién puede actuar dentro de un alcance.

Ambos mecanismos pueden y deben usarse juntos para lograr una gobernanza granular en estructuras organizativas complejas. ### Cómo crear segmentos y permisos **Crear un segmento** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), navega a la sección de **Configuración** 1. Desde el menú lateral izquierdo, selecciona **Segmentos & Permisos** 2 y haz clic en el botón **\+ Crear hijo** 3. ![create segment](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/579ae4ed-a54c-4694-91e1-2fb648d31b6e.png) Aparecerá un formulario que te permitirá definir el nombre del segmento, seleccionar un icono, elegir un color y previsualizar cómo aparecerá el segmento dentro de la jerarquía antes de guardarlo. **Crear permisos** Ahora, en la misma sección, haz clic en el botón **\+ Crear permiso** 4. En el modal lateral que aparece, puedes **dar un nombre al permiso** y **asignar un rol**, ya sea predefinido o [personalizado](https://docs.applivery.com/es/platform/roles-permissions/custom-collaborator-roles/). Desde aquí, puedes añadir administradores de segmento **incluyendo grupos** usando la lógica `AND` u `OR`, o introduciendo directamente direcciones de correo electrónico de usuarios individuales. ![create permission](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/c6807b1a-3d0b-4d2c-8377-4685bfc37b40.png) ### Mejores prácticas Al diseñar tu estructura de segmentos: - Alinéala con los límites operativos reales en lugar de proyectos temporales. - Mantén las configuraciones globales o de referencia en niveles superiores, y aplica personalizaciones locales en niveles inferiores. - Usa el mapeo de grupos basado en identidad siempre que sea posible para evitar la gestión manual de accesos. Una planificación cuidadosa del árbol de segmentos mejora significativamente la escalabilidad, la claridad y la mantenibilidad a largo plazo. --- ## Atributos inteligentes Source: https://docs.applivery.com/es/device-management/general-settings/smart-attributes/ Description: Los atributos inteligentes son propiedades dinámicas de dispositivos en Applivery MDM que permiten la automatización, segmentación y gestión multiplataforma. TL;DR: Los atributos inteligentes de Applivery MDM permiten la gestión y automatización dinámica de dispositivos mediante atributos personalizados y la integración con audiencias de dispositivos. Answers: ¿Qué son los atributos inteligentes en Applivery MDM? · ¿Cómo funcionan los atributos inteligentes? · ¿Qué tipos de atributos inteligentes están disponibles? · ¿Cómo se crean y configuran los atributos inteligentes? · ¿Cómo se integran los atributos inteligentes con las audiencias de dispositivos? · ¿Cuáles son los casos de uso comunes para los atributos inteligentes? · ¿Dónde se encuentran los atributos inteligentes en Applivery? · ¿Qué operadores están disponibles para los atributos inteligentes de texto/cadena? Key topics: Tipos de atributos inteligentes, Configuración de atributos inteligentes, Integración con audiencias de dispositivos, Casos de uso de automatización, Applivery MDM, Android, iOS, macOS, Windows ### ¿Qué son los atributos inteligentes y cómo funcionan? Los **atributos inteligentes** son propiedades dinámicas de dispositivos que **permiten la automatización avanzada**, la **segmentación** y la **Gestión de Dispositivos** en Applivery MDM. Permiten a los administradores definir atributos personalizados que pueden asignarse a dispositivos basándose en condiciones específicas, lo que posibilita flujos de trabajo de automatización sofisticados y una segmentación precisa de los dispositivos. Proporcionan una forma unificada y flexible de definir, almacenar y gestionar metadatos específicos de los dispositivos en todas las plataformas compatibles (Windows, Android, iOS y macOS). Actuando como una capa de abstracción entre los datos brutos de los dispositivos y las características de nivel superior —como las políticas, la **automatización** y la **segmentación**—, permiten a los administradores trabajar con atributos coherentes y reutilizables, independientemente del sistema operativo subyacente. Los atributos inteligentes pueden ser **específicos del SO** (valores separados para Android, iOS/macOS y Windows) o **multiplataforma** (un único valor aplicado en todas las plataformas). Se integran directamente con las [audiencias de dispositivos](https://docs.applivery.com/es/device-management/general-settings/device-audiences/), lo que te permite crear grupos de dispositivos dinámicos basados en los valores de los atributos. :::info Los atributos inteligentes tienen un alcance de segmento, lo que significa que se pueden configurar a nivel de **Workspace** (segmento global) o dentro de segmentos organizativos específicos. ::: Al combinar valores estáticos, selecciones predefinidas, entradas manuales, variables del sistema y evaluaciones basadas en scripts, los atributos inteligentes permiten una segmentación precisa y una lógica condicional avanzada en toda tu flota de dispositivos. ### Por qué atributos inteligentes La gestión de dispositivos en múltiples plataformas a menudo requiere lidiar con fuentes de datos inconsistentes y lógica específica del SO. Los atributos inteligentes resuelven esto al: - Estandarizar cómo se definen y consumen los metadatos de los dispositivos. - Permitir una lógica reutilizable y centralizada para la segmentación y la automatización. - Eliminar la necesidad de duplicar configuraciones específicas de la plataforma. - Proporcionar fuentes de datos tanto estáticas como dinámicas para una máxima flexibilidad. Esto permite a las organizaciones escalar la gestión de dispositivos manteniendo la coherencia, el control y la previsibilidad. ### Qué tipos de atributos inteligentes están disponibles Applivery MDM ofrece cinco tipos distintos de atributos inteligentes, cada uno diseñado para diferentes casos de uso. Sin embargo, antes de comprender estos tipos, es importante entender su origen, es decir, quién o qué proporciona el valor del atributo. Los atributos inteligentes se definen en función de este origen, que determina cómo se crean, actualizan y mantienen sus valores. #### Orígenes de atributos - **Administrador TI**: valores gestionados directamente desde el panel de Applivery. - **Usuario**: valores proporcionados por el usuario final a través del agente del dispositivo. - **Dispositivo**: valores obtenidos automáticamente del dispositivo. - **Constante**: valores fijos definidos por los administradores. #### Tipos compatibles por origen

Origen

Tipos compatibles

Cómo funciona

Caso de uso

Administrador TI

Manual, Enum

Los valores se definen en el panel de Applivery. Manual permite la entrada libre, mientras que Enum restringe los valores a opciones predefinidas.

Almacenar identificadores, nombres de departamento o ubicaciones. Estandarizar valores como niveles de dispositivo o de cumplimiento.

Usuario

Manual, Enum

Los valores son proporcionados por el usuario final a través del agente del dispositivo.

Recopilar datos contextuales o proporcionados por el usuario garantizando la coherencia.

Dispositivo

Selector, Script

Los valores se generan automáticamente desde el dispositivo. Los Selectors recuperan propiedades del sistema, mientras que los Scripts ejecutan lógica localmente.

Propiedades dinámicas de dispositivos, valores calculados, comprobaciones de cumplimiento.

Constante

Constant

Valor estático definido una vez por un administrador.

Configuraciones de referencia, ajustes globales.

:::info La versión inicial es compatible con todos los orígenes de atributos inteligentes excepto **Usuario**. La compatibilidad con el origen **Usuario** se introducirá en una versión futura, lo que permitirá a los usuarios finales proporcionar valores de atributos directamente desde el agente del dispositivo. ::: Esta vista ayuda a comprender rápidamente qué combinaciones son posibles al diseñar tus atributos inteligentes.

Origen ↓ / Tipo →

Manual

Enum

Selector

Script

Constant

Admin TI

✅

✅

❌

❌

❌

Usuario

✅

✅

❌

❌

❌

Dispositivo

❌

❌

✅

✅

❌

Constante

❌

❌

❌

❌

✅

#### Comportamiento de actualización La frecuencia de actualización de los atributos inteligentes depende de cómo se generen sus valores.

Tipo

Actualización

Comportamiento

Manual (Admin/Usuario)

Entrada manual

Se actualiza cada vez que el valor se modifica a través del panel de Applivery o del Agente.

Enum (Admin/Usuario)

Selección manual

Se actualiza cada vez que se selecciona una nueva opción.

Selector

Programador del sistema / actualizaciones del dispositivo

Se reevalúa dinámicamente cada 15 minutos o cuando cambian los datos del dispositivo.

Script

Ejecución del Agente

Se actualiza cada vez que el Script se ejecuta en el dispositivo.

Constant

Programador del sistema / actualizaciones del dispositivo

Se actualiza cada 15 minutos o cuando cambia la información del dispositivo.

#### Detalles del tipo Selector El tipo **Selector** utiliza interpoladores para hacer referencia a otras propiedades de dispositivos o atributos inteligentes: - **Versión inicial**: admite interpoladores y operaciones de cadena. - **Versiones futuras**: admitirá funciones avanzadas, que incluyen: - Manipulación de cadenas (dividir, subcadena, concatenación). - Lógica condicional. - Operaciones matemáticas sobre valores numéricos. - Cálculos de fecha/hora. ### Cómo creo y configuro atributos inteligentes **Ver y gestionar los atributos inteligentes existentes** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), navega a **Automatización** 1 y selecciona **Atributos inteligentes** 2. En esta sección, encontrarás una tabla que enumera todos los atributos existentes. Esta tabla proporciona una descripción completa de cada atributo, incluyendo su nombre, tipo, segmento asociado, alcance, número de dispositivos afectados y la marca de tiempo de la última actualización. Desde aquí, también puedes realizar acciones como editar, eliminar o ver los detalles del atributo. Para crear un nuevo atributo, simplemente haz clic en **\+ Crear Atributo inteligente** 3. ![Smart Attributes](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/82d00499-c343-4fe9-9452-3dfc31fdb6a5.png) **Seleccionar el tipo y alcance del atributo** Comienza seleccionando el **origen** del atributo inteligente de las opciones disponibles. Cada origen incluye una breve descripción para ayudarte a comprender cómo funciona y cuándo usarlo. A continuación, define el **tipo de entrada** (cómo se proporciona o genera el valor) y el **tipo de salida**, seguido del alcance del atributo: - **Específicos del SO:** Configura diferentes valores para cada plataforma (Android, iOS/macOS y Windows). - **Multiplataforma**: Define un único valor que se aplica de forma coherente en todas las plataformas. :::info Cuando se utiliza un alcance específico del SO, el sistema gestiona automáticamente las diferencias de plataforma en el backend, manteniendo una experiencia de configuración unificada. ::: ![Smart Attributes form](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/c730468e-8fe5-4a52-b948-6254eaaeb495.png) **Configurar las propiedades del atributo** Define las propiedades principales de tu atributo: - **Nombre**: El nombre que se muestra en la interfaz de **usuario**. - También puedes incluir una **descripción** opcional para aclarar el propósito del atributo. Dependiendo del alcance seleccionado: - Para atributos **específicos del SO**, proporciona valores para cada plataforma (Android, iOS/macOS, Windows). - Para atributos **multiplataforma**, define un único valor que se aplique a todos los dispositivos. **Configurar ajustes específicos del tipo** Algunos tipos de atributos requieren configuración adicional según su comportamiento. - Los atributos **Enum** te permiten definir una lista de opciones predefinidas, lo que garantiza datos coherentes y estructurados. - Los atributos **Script** requieren que proporciones la lógica del **Script** que se ejecutará en el dispositivo. Puedes escribir o pegar tu script directamente en el editor, usar asistencia de IA si está disponible y probarlo antes de la implementación. El script debe devolver el valor en el formato esperado en su última línea. - Los atributos **Selector** utilizan variables dinámicas para recuperar datos de dispositivos o atributos. Estos se definen utilizando interpoladores como: `{{device.serial_number}}-{{device.model}}`. `{{smart_attribute.department}}-{{device.os_version}}`. **Definir la asignación de dispositivos (opcional)** Finalmente, puedes decidir cómo se asigna el atributo inteligente a los dispositivos. Puedes asignar atributos **manualmente** a dispositivos específicos a través de la vista de detalles del dispositivo, o **automatizar** el proceso utilizando **audiencias de dispositivos**, que asignan atributos dinámicamente basándose en condiciones definidas. Esta flexibilidad te permite aplicar atributos caso por caso o a escala mediante una segmentación automatizada. ### Cómo funcionan los atributos inteligentes con las audiencias de dispositivos Los atributos inteligentes se integran perfectamente con las **audiencias de dispositivos**, lo que permite una segmentación dinámica de los dispositivos basada en los valores de los atributos. Al crear o editar una audiencia de dispositivos, puedes usar los atributos inteligentes como parte de tus criterios de filtrado para segmentar los dispositivos con mayor precisión. #### Estructura del filtro de audiencias de dispositivos Los filtros de audiencias de dispositivos siguen esta estructura: **Atributo → Operador → Valor** Esto te permite definir condiciones basadas en propiedades de dispositivos, etiquetas o atributos inteligentes. Por ejemplo, puedes: - Filtrar dispositivos por etiquetas (por ejemplo, ubicación o departamento). - Usar atributos inteligentes para definir condiciones como la versión del SO o el estado de seguridad. - Combinar múltiples filtros para construir una lógica de segmentación más avanzada. #### Ejemplos de configuraciones 1. Filtro de **etiquetas de dispositivos**: dispositivos que incluyen etiquetas específicas como _Madrid_ y _Barcelona._ 2. Filtro de atributo inteligente: dispositivos donde un atributo inteligente como _OS Version_ es mayor que un valor específico (por ejemplo, 26.2). 3. **Filtros combinados**: puedes combinar múltiples condiciones, como FileVault habilitado (Verdadero Y), Versión del SO mayor que 26.2 (O), **Dispositivos** etiquetados con Madrid. #### Operadores lógicos entre filtros Comprender cómo se combinan los filtros es clave para construir audiencias de dispositivos correctas. - **Lógica AND** (dentro del mismo tipo de filtro)**:** cuando se utilizan múltiples condiciones de atributo inteligente, todas ellas deben cumplirse. Por ejemplo, un dispositivo debe tener _OS Version > 26.2,_ **y** _FileVault debe estar habilitado_. - **Lógica OR** (entre diferentes tipos de filtro)**:** los diferentes tipos de filtros (por ejemplo, etiquetas de dispositivos frente a atributos inteligentes) se evalúan de forma independiente, y un dispositivo puede coincidir si satisface cualquiera de esos grupos. - **Comportamiento de las etiquetas de dispositivos:** las etiquetas de dispositivos utilizan el operador **"Incluye (tiene todos)"**, lo que significa que el dispositivo debe contener todas las etiquetas especificadas para coincidir. #### Operadores disponibles por tipo de atributo Los operadores varían según el tipo de datos del atributo inteligente:

Tipo de datos

Operadores disponibles

Texto/Cadena

Igual a, Distinto de, Contiene, No contiene, Empieza por, Termina con.

Número

Igual a, Distinto de, Mayor que, Menor que, Mayor o igual que, Menor o igual que, Entre.

Booleano

Igual a, Distinto de.

Fecha

Igual a, Distinto de, Antes de, Después de, Entre.

Enum

Igual a, Distinto de, En la lista, No en la lista.

#### Comprender la lógica del filtro La interfaz de audiencias de dispositivos proporciona una fórmula visual que representa cómo se evalúan tus filtros: ``` (device_tag includes "Madrid" OR device_tag includes "Barcelona") AND (smart_attribute.os_version > 26.2 AND smart_attribute.filevault = true) ``` Esta representación te ayuda a comprender claramente cómo se aplican las condiciones y garantiza que tu segmentación se comporte como se espera. ### Cuáles son los casos de uso comunes para los atributos inteligentes Los atributos inteligentes admiten una amplia gama de escenarios: - **Etiquetado estático:** asignar metadatos fijos como la ubicación de la oficina o la unidad de negocio. - **Extracción dinámica de datos:** recuperar información a nivel de sistema automáticamente. - **Cálculos personalizados:** generar valores utilizando scripts (por ejemplo, estado de cumplimiento). - **Entradas estandarizadas:** aplicar valores coherentes utilizando Enums. - **Entrada manual de datos:** capturar información no disponible programáticamente. --- ## Primeros pasos Source: https://docs.applivery.com/es/device-management/getting-started/ Description: El panel de control de Applivery centraliza la gestión de dispositivos. Inscribir, configura políticas y automatiza flujos de trabajo en 5 secciones clave. TL;DR: Esta guía introduce el panel de control de Applivery, explicando cómo gestionar dispositivos Apple, Android y Windows a través de sus secciones clave. Answers: ¿Para qué se utiliza Applivery? · ¿Cómo accedo al panel de control de Applivery? · ¿Qué es la sección 'Visión general' del panel de control de Applivery? · ¿Qué tipos de archivos se admiten para el despliegue de aplicaciones en Applivery? · ¿Qué tipos de scripts se pueden desplegar con Applivery? · ¿Qué son las 'Inscripciones inteligentes' en Applivery? · ¿Qué son las 'audiencias de dispositivos' en Applivery? · ¿Qué son los 'Colaboradores' en Applivery? Key topics: Panel de control de Applivery, Creación de cuenta, Gestión de dispositivos, Políticas MDM, Recursos desplegables, Automatización de flujos de trabajo, Applivery, Apple, Android, Windows, Bash, PowerShell, MDM, UEM Applivery ofrece una **plataforma unificada para gestionar dispositivos Apple, Android y Windows** en entornos corporativos. Desde la inscripción hasta las políticas, la automatización y los recursos, los administradores pueden controlar centralmente cada aspecto de la gestión de dispositivos. ### Cómo crear una cuenta en Applivery **Datos de la cuenta** ![Datos de la cuenta](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/c2e556e7-f021-4dac-bcc5-8df3db479c09.png) Ve a https://dashboard.applivery.io/welcome/register y completa el formulario de registro con tus datos. **Valida tu correo electrónico** ![Valida tu correo electrónico](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/0d4fd017-ec2b-48d8-9997-3e0d4f9cdfb6.png) Verifica tu dirección de correo electrónico para activar tu cuenta (requerido por motivos de seguridad). **Configura tu Workspace** ![Configura tu Workspace](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/7ff9efd2-62a9-4cd3-8246-700897580c65.png) Configura tu Workspace. Puedes modificar el nombre y la URL en cualquier momento, pero se recomienda usar el nombre de tu empresa como buena práctica. **Sobre ti** ![Sobre ti](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ecb1a78f-5667-48d3-a66c-2a44471cb3c4.png) Cuéntanos sobre ti **Bienvenido 👋** ![Bienvenido 👋](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/a9a41c1a-3232-4075-b1de-96ea790fc984.png) Bienvenido al panel de control de Applivery ### Acceso al panel de Applivery Para empezar a gestionar tus dispositivos, inicia sesión en el [panel de Applivery](https://dashboard.applivery.io). Los usuarios con acceso se denominan **colaboradores** y tienen diferentes permisos según su rol. Esto asegura que tareas como la inscripción de dispositivos, la asignación de políticas y la automatización puedan delegarse manteniendo la seguridad y el control operativo. Empezar con Applivery es sencillo. Una vez creado tu Workspace, puedes empezar inmediatamente a inscribir y gestionar tus dispositivos. #### El panel El **panel de Applivery para la Gestión de Dispositivos** se organiza en secciones dedicadas que permiten a los administradores supervisar, inscribir, configurar y automatizar la gestión de dispositivos en toda la organización. Desde la visibilidad de la flota a alto nivel hasta la configuración granular de políticas, el panel centraliza todas las operaciones de dispositivos en una interfaz estructurada y basada en roles. ##### Inicio La sección de **Inicio** es la primera pantalla de tu Workspace y proporciona métricas clave para evaluar rápidamente tu flota de dispositivos. Aquí puedes encontrar información sobre: - Número total de dispositivos inscritos. - Estado del dispositivo (activo, inactivo o deshabilitado). - Modelos y versiones de SO más utilizados. - Niveles de batería. - Estado de cumplimiento. Estas métricas permiten a los administradores detectar tendencias, identificar posibles problemas y tomar decisiones basadas en datos sobre la gestión de dispositivos. ![panel de control mdm](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/94ffcba0-db5c-4b65-895e-34875e81b693.png) ##### Dispositivos La sección **Dispositivos** muestra todos los dispositivos actualmente inscritos en tu Workspace. Los dispositivos se listan según los segmentos creados por los administradores del Workspace. El acceso a los dispositivos se controla en función de los permisos de segmento asignados a cada colaborador. Desde esta vista, los usuarios pueden: - Inscribir nuevos dispositivos (Apple, Android o Windows). - Ejecutar acciones masivas, como asignaciones de políticas o comandos remotos. :::info Para obtener una guía detallada sobre la inscripción de dispositivos, consulta la documentación dedicada a la inscripción de Apple, Android y Windows. ::: ![sección de Dispositivos](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/9de1d323-0c4b-4d1c-8cbb-eb6f927a3f4d.png) ##### Políticas Una **política** es una colección de configuraciones que define cómo se comporta un dispositivo una vez que está gestionado. Dependiendo de la plataforma, una Política puede incluir: - Restricciones del sistema y configuraciones de seguridad (contraseñas, cifrado). - Reglas de instalación de aplicaciones. - Scripts o acciones automatizadas. - Integraciones con servicios de seguridad. - Configuraciones de modo quiosco. La sección Políticas lista todas las políticas disponibles para tu cuenta. Al igual que con los dispositivos, la visibilidad y el acceso a las políticas dependen de tus permisos de segmento de Workspace. Desde aquí, los administradores pueden crear nuevas políticas o modificar las existentes. :::info Aprende a crear una nueva política en nuestro [artículo de documentación de políticas](https://docs.applivery.com/es/device-management/general-settings/create-policies/) dedicado. ::: ![sección de Políticas](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/20acb7cf-cac8-4818-9858-fa5c43e3cc21.png) ##### Recursos La sección **Recursos** centraliza todos los activos desplegables utilizados en tus flujos de trabajo de gestión de dispositivos. Estos recursos pueden ser: - **Aplicaciones**: Despliega aplicaciones personalizadas o de terceros para asegurar que los empleados de dispositivos tengan acceso a las herramientas que necesitan. Los formatos admitidos incluyen `.ipa`, `.pkg`, `.msi`, `.msix`, `.appx` y `.apk`. Esto permite la distribución empresarial segura de aplicaciones internas, herramientas de línea de negocio y software externo aprobado en dispositivos gestionados. - **Scripts**: Automatiza tareas operativas y configuraciones del sistema desplegando scripts **bash** para macOS y scripts **PowerShell** para Windows. Los scripts pueden utilizarse para la instalación de software, cambios en la configuración del sistema, acciones de remediación, aplicación de cumplimiento o tareas de mantenimiento. - **Libros**: Distribuye documentación y contenido digital en múltiples formatos admitidos, incluyendo `.pdf`, `.epub`, `.rtf`, `.rtfd`, `.txt`. :::info Los libros solo están disponibles para **dispositivos iOS**. Para entornos de iPad compartido, los libros solo pueden asignarse a **cuentas de usuario**, no directamente a los dispositivos. ::: - **Imágenes**: Despliega archivos de imagen en `.jpg` y `.png` en tus dispositivos Apple y Windows. Las imágenes pueden utilizarse para branding, configuraciones de quiosco, personalización de la pantalla de bloqueo o distribución de contenido interno. - **Certificados**: Protege las comunicaciones y la autenticación de dispositivos desplegando certificados digitales. Los formatos admitidos incluyen `.p12`, `.der`, `.pem`, `.crt` y `.cer`. Los certificados son esenciales para la autenticación Wi-Fi, el acceso VPN, la seguridad del correo electrónico y la comunicación segura de aplicaciones. - **Proveedores de certificados**: Configúralos para automatizar la emisión y la gestión del ciclo de vida de los certificados. Esto permite a los dispositivos solicitar y renovar certificados dinámicamente a través de autoridades de identidad o certificados integradas, mejorando la seguridad y reduciendo la carga administrativa manual. :::info Puedes leer más sobre los recursos en el siguiente [enlace a nuestra documentación](https://docs.applivery.com/es/device-management/general-settings/distribute-resources/). ::: ![sección de Recursos](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/2fd67f25-4a08-45e3-9fa3-db6bad7a7347.png) ##### Automatización La sección **Automatización** se organiza por sistema operativo y permite a los administradores agilizar la gestión del ciclo de vida de los dispositivos a través de flujos de trabajo automatizados: - **Inscripciones inteligentes**: te permiten automatizar el proceso de inscripción de dispositivos basándose en reglas y condiciones predefinidas. Puedes definir criterios que los dispositivos deben cumplir durante la inscripción y asignar automáticamente las políticas adecuadas en función de esas condiciones. Esto asegura que los dispositivos se configuren correctamente desde el principio, sin intervención manual. :::info Para obtener una guía detallada sobre las inscripciones inteligentes, consulta la documentación dedicada a Apple, Android y Windows. ::: - **Audiencias de dispositivos**: permiten a los administradores crear grupos dinámicos de dispositivos basados en atributos específicos como el sistema operativo, el estado de cumplimiento, el modelo o criterios personalizados. Estas audiencias facilitan la segmentación de subconjuntos específicos de dispositivos para configuraciones, políticas o despliegues. Para saber más sobre las audiencias de dispositivos, consulta [nuestra documentación](https://docs.applivery.com/es/device-management/general-settings/device-audiences/). - **Reglas de automatización**: permiten a los administradores ejecutar acciones automáticamente cuando se cumplen ciertas condiciones. Cada regla está vinculada a una audiencia de dispositivos. Cuando un dispositivo coincide con los criterios definidos, se activan automáticamente una o más acciones predefinidas, como asignaciones de políticas, despliegues de aplicaciones o actualizaciones de configuración. Esto permite una gestión de dispositivos dinámica y a gran escala sin necesidad de operaciones manuales. Para saber más sobre las reglas de automatización, consulta [nuestra documentación](https://docs.applivery.com/es/device-management/general-settings/automation-rules/). ![sección de Automatización](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/55c896cc-d231-42ac-b2b4-2ec8137e9d45.png) Estas características permiten a los equipos de TI reducir tareas manuales, mantener el cumplimiento y asegurar que los dispositivos se configuren de manera consistente en toda la flota. ##### Directorio y Configuración La sección **Directorio y Configuración** centraliza la gestión de identidades, el control de acceso, la segmentación del Workspace y las configuraciones específicas del sistema operativo dentro del entorno de gestión de dispositivos de Applivery. Esta sección asegura que los administradores puedan controlar de forma segura quién gestiona los dispositivos, a qué dispositivos pueden acceder y cómo se aplican las configuraciones específicas de la plataforma en toda la organización. - **Colaboradores**: Usuarios con acceso al panel de Applivery. Se les pueden asignar roles granulares y niveles de permiso según sus responsabilidades operativas, como control administrativo completo, permisos de gestión de dispositivos, creación y modificación de políticas, y acceso de solo lectura. El control de acceso basado en roles (RBAC) garantiza la seguridad operativa al limitar el acceso a acciones sensibles de dispositivos y prevenir cambios de configuración no autorizados. - **Empleados de dispositivos**: Usuarios finales que tienen uno o más dispositivos asignados a ellos. Estos usuarios representan la capa humana de tu flota de dispositivos y son esenciales para el seguimiento de la propiedad de los dispositivos, la asociación de cumplimiento, la segmentación de políticas y la asignación de recursos (aplicaciones, configuraciones, libros, etc.). - **Segmentos y Permisos**: Los segmentos permiten a los administradores dividir lógicamente el Workspace en grupos estructurados para un control granular. Pueden utilizarse para restringir el acceso de los colaboradores a subconjuntos específicos de dispositivos, aislar entornos (por ejemplo, departamentos, regiones, subsidiarias), controlar la visibilidad de políticas y recursos, y delegar responsabilidades de gestión de forma segura. Los permisos se aplican en función de la pertenencia al segmento, asegurando que los administradores solo gestionen los dispositivos y configuraciones relevantes para su alcance. Esta estructura es crítica para despliegues a gran escala o multientidad. - **Configuraciones del sistema operativo**: Esta sección también incluye configuraciones específicas de la plataforma para cada sistema operativo compatible (Apple, Android y Windows). Dependiendo de la plataforma, los administradores pueden configurar métodos de inscripción e integraciones de plataforma. :::tip Puedes encontrar más información sobre los tipos de usuario en el siguiente artículo de [nuestra documentación](https://docs.applivery.com/es/device-management/getting-started/manage-users/). ::: ![sección de configuración](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/e9222326-767b-4d7d-b7e0-616e6892d98c.png) --- ## Conceptos clave Source: https://docs.applivery.com/es/device-management/getting-started/main-concepts/ Description: Conceptos clave de gestión de dispositivos en Applivery: Workspaces, inscripción, políticas, Reglas de automatización, Segmentos y estado de cumplimiento. TL;DR: Applivery gestiona dispositivos iOS, Android y Windows a través de Workspaces, inscripción, políticas y automatización para asegurar el cumplimiento. Answers: ¿Qué es la gestión de dispositivos? · ¿Cómo gestiona Applivery los dispositivos? · ¿Qué son las políticas de dispositivos? · ¿Qué es la inscripción de dispositivos? · ¿Qué son las reglas de automatización en la gestión de dispositivos? · ¿Cómo funciona el cumplimiento en Applivery? · ¿Qué es un Workspace en Applivery? Key topics: Workspaces, Inscripción de Dispositivos, Políticas MDM, Automatización de Dispositivos, Cumplimiento de Seguridad, Applivery, iOS, Android, Windows, MDM, UEM Como introducción a la Gestión de Dispositivos de Applivery, te recomendamos encarecidamente que explores y comprendas los siguientes conceptos básicos, que se explicarán en detalle en los próximos capítulos de la documentación, ya que representan los fundamentos de nuestra plataforma. ### Workspaces Un **Workspace** es el entorno organizativo donde se gestionan dispositivos, políticas, recursos, reglas de automatización y administradores. Cada Workspace opera de forma independiente y contiene su propia configuración, modelo de segmentación y estructura de control de acceso. ### Dispositivo Un **dispositivo** es cualquier endpoint de Apple, Android o Windows inscrito y gestionado a través de Applivery. Una vez inscrito, un dispositivo puede recibir políticas, aplicaciones, scripts, configuraciones y ajustes de seguridad definidos por los administradores. ### Inscripción La **inscripción** es el proceso de registrar un **d**ispositivo en el sistema de gestión de Applivery. Durante la inscripción, el dispositivo establece confianza con la plataforma y se vuelve elegible para recibir configuraciones, políticas y acciones automatizadas. Los métodos de inscripción varían según el sistema operativo y la configuración organizativa. ### inscripción inteligente La **inscripción inteligente** automatiza el proceso de inscripción aplicando reglas y condiciones predefinidas. Los dispositivos que cumplen criterios específicos pueden recibir automáticamente políticas y configuraciones durante la inscripción, asegurando una configuración estandarizada sin intervención manual. ### Política Una **política** es una colección estructurada de configuraciones que definen cómo se comporta un dispositivo gestionado. Dependiendo del sistema operativo, las Políticas pueden incluir: - Restricciones de seguridad. - Requisitos de código de acceso y cifrado. - Reglas de gestión de aplicaciones. - Configuraciones de red (Wi-Fi, VPN, correo electrónico). - Ajustes de modo quiosco. - Restricciones del sistema. Las políticas aplican el cumplimiento y los estándares operativos en todos los dispositivos. ### Audiencias de dispositivos Una [**Audiencia de Dispositivos**](https://docs.applivery.com/es/device-management/general-settings/device-audiences/) es un grupo dinámico de dispositivos generado automáticamente en función de condiciones predefinidas (como la versión del sistema operativo, el estado de cumplimiento, el modelo o atributos personalizados). Las audiencias de dispositivos se actualizan automáticamente a medida que los dispositivos cumplen o dejan de cumplir los criterios definidos, lo que permite una segmentación escalable para la automatización y la asignación de políticas. ### Reglas de automatización Una [**Regla de automatización**](https://docs.applivery.com/es/device-management/general-settings/automation-rules/) es un mecanismo basado en reglas que activa automáticamente acciones cuando un dispositivo coincide con las condiciones de una audiencia de dispositivos. Las acciones pueden incluir: - Asignación de políticas. - Despliegue de aplicaciones o scripts. - Actualización de configuraciones. Las reglas de automatización permiten una gestión dinámica del ciclo de vida sin ejecución manual. ### Segmento Un [**Segmento**](https://docs.applivery.com/es/device-management/general-settings/segments/) es una división estructural dentro de un Workspace que permite un control administrativo granular. Los segmentos restringen la visibilidad y los permisos de gestión, asegurando que los administradores solo puedan acceder a los dispositivos, políticas y recursos asignados a su ámbito. Esto es especialmente importante en entornos multidepartamentales o multi-entidad. ### Recurso Un [**recurso**](https://docs.applivery.com/es/device-management/general-settings/distribute-resources/) es cualquier activo desplegable que se puede asignar a [**d**](https://docs.applivery.com/es/device-management/general-settings/distribute-resources/)ispositivos, ya sea manualmente o a través de políticas y automatización. Los recursos pueden incluir: - Aplicaciones. - Scripts. - Libros. - Imágenes. - Certificados. - Proveedores de certificados. Los recursos amplían la funcionalidad del dispositivo y permiten una gestión segura de la configuración. ### Estado de cumplimiento El **estado de cumplimiento** indica si un **d**ispositivo cumple con los estándares de seguridad y configuración definidos por las políticas asignadas. Los dispositivos pueden marcarse como conformes o no conformes dependiendo de factores como el estado de cifrado, los requisitos de código de acceso, la versión del sistema operativo o la [postura de seguridad](https://docs.applivery.com/es/device-management/android/security-posture/). La monitorización del cumplimiento ayuda a aplicar los estándares de seguridad corporativos. Consulta [Comprobaciones de conformidad](https://docs.applivery.com/es/device-management/general-settings/compliance-checks/) para saber cómo interpretar el resultado en un dispositivo concreto. ### Directorio El **directorio** centraliza la gestión de: - Colaboradores (administradores de Workspace). - Empleados de dispositivos (usuarios finales). - Control de acceso y segmentación. Define quién puede gestionar dispositivos y cómo se asocian los dispositivos con los usuarios dentro de la organización. :::tip Puedes encontrar más información sobre los tipos de usuario en el siguiente artículo de [nuestra documentación](https://docs.applivery.com/es/device-management/getting-started/manage-users/). ::: --- ## Gestión de usuarios Source: https://docs.applivery.com/es/device-management/getting-started/manage-users/ Description: Applivery organiza usuarios en colaboradores (administradores) y empleados de dispositivos (usuarios finales) para un control de acceso y políticas precisos. TL;DR: Applivery gestiona dos tipos de usuarios (colaboradores y empleados de dispositivo) para un control de acceso preciso y despliegues dirigidos de políticas en dispositivos móviles y de escritorio. Answers: ¿Cómo añado usuarios a la Gestión de Dispositivos de Applivery? · ¿Cuál es la diferencia entre colaboradores y empleados de dispositivos en Applivery? · ¿Cómo creo audiencias de dispositivos en Applivery? · ¿Cómo hago seguimiento de la actividad de los usuarios en Applivery? · ¿Cómo invito a colaboradores a Applivery? · ¿Qué son los segmentos en Applivery y cómo se utilizan? · ¿Cómo asigno políticas a los empleados de dispositivos en Applivery? · ¿Cómo gestiona Applivery el control de acceso para diferentes tipos de usuario? Key topics: Gestión de colaboradores, Gestión de empleados de dispositivos, audiencias de dispositivos y segmentos, Seguimiento de la actividad del usuario, Roles de usuario de Applivery, Applivery, colaboradores, empleados de dispositivos, audiencias de dispositivos, Segmentos, iOS, Android, Windows, macOS Una gestión eficaz de usuarios es esencial para proteger y organizar los dispositivos corporativos. Applivery proporciona una interfaz centralizada para gestionar tanto a los administradores (colaboradores) como a los usuarios finales (empleados de dispositivos) con un control de acceso preciso. En la Gestión de Dispositivos de Applivery, existen dos categorías principales de usuarios: **colaboradores** y **empleados de dispositivos**. ### Colaboradores Los colaboradores son miembros del equipo que gestionan dispositivos y configuraciones de Workspace a través del panel de Applivery. Lo que puede hacer cada Colaborador depende del rol que tenga asignado en sus [permisos de segmento](https://docs.applivery.com/es/device-management/general-settings/segments/#cómo-crear-segmentos-y-permisos). Además de los roles predefinidos Admin, Editor y Viewer, puedes crear [roles de Colaborador personalizados](https://docs.applivery.com/es/platform/roles-permissions/custom-collaborator-roles/) con solo las acciones que necesita cada puesto. ![mdm Collaborators](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/5cf3e09a-ded8-422d-9917-559cc07046b3.png) ### Empleados de dispositivos Los empleados de dispositivos representan a los usuarios finales asignados a dispositivos gestionados. Pueden agruparse y asignárseles políticas, apps o configuraciones. ![mdm Device Employees](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ea6d02de-aac9-471e-8bc6-d1b01569dec6.png) ### Audiencias de dispositivos y segmentos La Gestión de Dispositivos de Applivery permite a los administradores definir audiencias y segmentos para organizar dispositivos y usuarios para políticas y despliegues dirigidos. - [**Segmentos**](https://docs.applivery.com/es/device-management/general-settings/segments/): colecciones estáticas de dispositivos o usuarios para el control de acceso. - [**Audiencias de dispositivos**](https://docs.applivery.com/es/device-management/general-settings/device-audiences/): grupos dinámicos que se ajustan automáticamente según los atributos o criterios del dispositivo. Esto ayuda a asegurar que las políticas, apps y scripts se desplieguen a los usuarios correctos sin intervención manual. ### Resumen de actividad del usuario Applivery registra la actividad de los colaboradores para monitorizar el uso y la interacción con el Workspace. El sistema registra: - Los inicios de sesión actualizan tanto la marca de tiempo del último inicio de sesión como la de la última acción. - Otras acciones (cambios de política, tareas de gestión de dispositivos, etc.) actualizan la marca de tiempo de la última acción. :::info El seguimiento de la actividad **no se aplica a los empleados de dispositivos,** ya que no tienen acceso al panel de Applivery. ::: #### Mejores prácticas - Utiliza audiencias de dispositivos para la gestión dinámica de grandes flotas. - Monitoriza la actividad de los colaboradores regularmente para identificar cuentas inactivas o posibles configuraciones erróneas. - Asegúrate de que a los nuevos empleados de dispositivos o colaboradores se les asignen los segmentos y permisos adecuados para sus responsabilidades. ### Cómo invitar a tu equipo Una vez en el [**panel de Applivery**](https://dashboard.applivery.io), navega a la sección de **Configuración** 1 y, en el menú de la izquierda, bajo la sección **Directorio** 2, selecciona el tipo de usuario que deseas añadir. ![add users](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/22eddd09-883e-4e43-be7c-52947d724d5b.png) #### Flujo de invitación Cuando invitas a un colaborador a unirse a tu equipo, recibirá una invitación por correo electrónico para registrarse. Por el contrario, la creación de un empleado de dispositivos no activa una invitación, ya que estos usuarios son usuarios finales nominales vinculados directamente a los dispositivos inscritos. ##### Colaboradores Al invitar a un nuevo colaborador a tu Workspace: **Correo electrónico de invitación** El usuario recibe un correo electrónico de invitación para unirse a Applivery. Su dirección de correo electrónico se rellena previamente en el formulario de registro. **Registro** Después de registrarse, recibe un segundo correo electrónico para verificar su dirección de correo electrónico. **Verificación** Una vez verificado, se le redirige a la página de inicio de sesión para introducir las credenciales que acaba de crear. **Acceso al panel de Applivery** Finalmente, puede acceder al panel de Applivery y solo verá los segmentos de Workspace a los que se le ha asignado. ![Collaborators invitation flow](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/9952e706-cf25-4abe-b29e-925129f9c67d.png) ##### Empleados de dispositivos Los empleados de dispositivos son una entidad lógica utilizada para agrupar dispositivos. Cada empleado de dispositivos se identifica mediante una dirección de correo electrónico, que no requiere confirmación. Puedes usar correos electrónicos reales o genéricos para representar a individuos, equipos, departamentos o ubicaciones. --- ## Integraciones Source: https://docs.applivery.com/es/device-management/integrations/ Description: Integraciones en Gestión de Dispositivos de Applivery — SSO, SCIM, notificaciones e integraciones de seguridad para autenticación centralizada y cumplimiento normativo. TL;DR: Applivery se integra con Okta y Google Workspace para un SSO simplificado y el aprovisionamiento de usuarios, mejorando la seguridad en la gestión de dispositivos. Answers: ¿Qué es el SSO en Applivery? · ¿Con qué proveedores de identidad se integra Applivery? · ¿Qué pueden hacer los administradores con el SSO de Applivery? · ¿Dónde se configura el SSO de Applivery? · ¿Cuál es la ventaja de usar SSO en Applivery? · ¿Admite Applivery el aprovisionamiento de usuarios? Key topics: SSO, aprovisionamiento de usuarios, integraciones Applivery, Okta, Google Workspace, Applivery La Gestión de Dispositivos de Applivery se integra con herramientas y plataformas externas para ampliar sus capacidades. Esto incluye SSO y proveedores de identidad para una autenticación centralizada, soluciones de seguridad para la defensa contra amenazas móviles y servicios de notificaciones para mantener informado a tu equipo. Las integraciones de la Gestión de Dispositivos están organizadas por tipo: SSO, Seguridad y Notificaciones. --- ## Notificaciones Source: https://docs.applivery.com/es/device-management/integrations/notifications/ Description: Notificaciones de Gestión de Dispositivos en Applivery — mantente informado con Slack, webhooks y alertas en tiempo real para eventos de dispositivos y certificados. TL;DR: Las notificaciones de Applivery se integran con Slack y webhooks para proporcionar alertas en tiempo real y visibilidad de la actividad de gestión de dispositivos. Answers: ¿Para qué sirven las notificaciones de Applivery? · ¿Con qué servicios externos puede integrarse Applivery para notificaciones? · ¿Quién puede configurar las notificaciones en Applivery? · ¿Dónde se configuran las notificaciones de Applivery? · ¿Qué tipo de alertas se pueden configurar en Applivery? · ¿Cómo mejoran las notificaciones de Applivery la visibilidad? Key topics: notificaciones Applivery, integración Slack, integración webhook, alertas de gestión de dispositivos, Applivery, Slack, webhooks, Gestión de Dispositivos Las integraciones de notificaciones te permiten mantenerte informado sobre la actividad de Gestión de Dispositivos en tiempo real. Puedes conectar Applivery con Slack para recibir alertas en tus canales, o configurar webhooks personalizados para enviar eventos a cualquier servicio externo. Configura cada integración de notificaciones disponible para la Gestión de Dispositivos. --- ## Slack Source: https://docs.applivery.com/es/device-management/integrations/notifications/slack/ Description: Integra Applivery con Slack para recibir notificaciones instantáneas sobre inscripciones de dispositivos, caducidad de certificados y actualizaciones de inventario. TL;DR: Integra Applivery con Slack para recibir notificaciones en tiempo real sobre inscripciones de dispositivos, caducidad de certificados y otros eventos clave. Answers: ¿Qué eventos de Applivery pueden activar notificaciones en Slack? · ¿Cómo integro Applivery con Slack? · ¿Dónde se configuran las integraciones de Slack de Applivery? · ¿Puedo personalizar qué eventos generan notificaciones en Slack? · ¿Cómo cambio el canal o usuario de Slack que recibe las notificaciones? · ¿Cómo actualizo los eventos que activan las notificaciones de Slack? · ¿Cómo elimino la integración de Slack de Applivery? · ¿Qué información muestra la lista de integraciones de Slack? Key topics: Integración Slack, Notificaciones de Applivery, Alertas de gestión de dispositivos, Ajustes del workspace, Configuración de la integración, Applivery, Slack, Apple Push Certificate ![applivery-slack-macIphone | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/8e0ca2d7-921c-47eb-b6f9-0d4b32d04df1.png) Ahora puedes integrar Applivery con Slack y empezar a recibir notificaciones cuando se produzcan los siguientes eventos: - Se ha creado un nuevo **Token de inscripción**. - Un nuevo **Dispositivo** se ha inscrito correctamente. - Se ha asignado o cambiado un **Empleado** en un dispositivo. - El **Apple Push Certificate** está a punto de caducar. - Se ha registrado un nuevo **ítem de inventario**. Integrar Applivery en tu equipo de Slack es muy sencillo gracias a nuestra App Oficial, y la configuración te llevará menos de 1 minuto. Solo tienes que seguir los pasos siguientes. ### Primeros pasos La integración de Slack se puede configurar a nivel de **Workspace**, de modo que las notificaciones de todos los dispositivos y la actividad de inscripción de tu organización se envíen a un `#canal` o `@usuario` específico. **Ve a Integraciones** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a los Ajustes del Workspace 1 desde el menú desplegable superior, luego abre Integraciones 2 en el menú de la izquierda y haz clic en el botón + Crear integración 3. ![integrations](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/a4fd9792-8503-4f69-96d2-920a820650b9.png) **Eventos de Slack** Elige la opción **Slack**, selecciona los eventos que quieres recibir de la lista y haz clic en el botón **Añadir a Slack**. ![slack integration](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/64bf647b-46bd-4f8b-8203-e88d90f37717.png) **Autoriza la integración** Ahora es el momento de iniciar sesión en tu equipo, por lo que necesitarás introducir tu **dirección de email de Slack** y tu **contraseña de Slack**. Después, selecciona dónde deben publicarse los mensajes de Applivery usando el menú desplegable inferior que mostrará la lista de usuarios y canales disponibles en tu equipo de Slack. Una vez hecho, haz clic en el botón **Permitir**. ![slack-step4-1 | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/92f790ba-de74-448d-9a6a-aee13fa8274c.png) **Gestiona las integraciones de Slack** Serás redirigido automáticamente a la sección **Integraciones**, donde debería aparecer la nueva integración de Slack con todos los detalles que has seleccionado: - **Tipo:** Slack. - **Configuración:** `#canal` o `@usuario` que recibirá los mensajes. - **Eventos:** lista de eventos que se notificarán. ![slack-step4-1 | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/92f790ba-de74-448d-9a6a-aee13fa8274c.png) ¡Eso es todo! Serás redirigido automáticamente de vuelta a Applivery y empezaremos a enviar notificaciones a tu equipo de Slack de inmediato. **Actualiza los ajustes de la integración de Slack** Puedes editar tus integraciones de Slack en cualquier momento yendo a la **sección Integraciones** de tu **Workspace** y haciendo clic en una de tus integraciones de Slack existentes. Se abrirá un panel lateral que te permitirá elegir qué eventos se publicarán en tus `@usuarios` o `@canales`. También podrás eliminar la integración haciendo clic en el botón **Eliminar**. ![slack integration notifications](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/16a8bb97-6804-4148-8909-88126ba060ef.png) #### Ejemplos de notificaciones ![new-Builds-messages | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/99ca45b9-c2b3-439b-86a2-999d16107ab0.png) ![new-feedback-messages | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/265daebc-72c2-4c22-9355-b8cca6b0bbb7.png) **Webhooks personalizados** Aprende a configurar webhooks personalizados para escenarios de integración avanzados. --- ## Webhooks personalizados Source: https://docs.applivery.com/es/device-management/integrations/notifications/webhooks/ Description: Conecta la Gestión de Dispositivos de Applivery con servicios externos usando webhooks — notificaciones en tiempo real para inscripciones de dispositivos, caducidad de certificados y mucho más. TL;DR: Integra Applivery con webhooks para recibir notificaciones en tiempo real sobre eventos de gestión de dispositivos como inscripciones, caducidad de certificados y cambios de inventario. Answers: ¿Qué eventos activan los webhooks de Applivery para Gestión de Dispositivos? · ¿Cómo configuro un webhook en Applivery? · ¿Dónde se configuran los webhooks de Applivery? · ¿Cuál es el formato de los payloads de los webhooks de Applivery? · ¿Cómo identifico el tipo de evento en un payload de webhook de Applivery? · ¿Qué significa el campo numDays en el webhook apple_push_certification_renovation? · ¿Qué indica el campo enrollmentToken.type en el webhook emm_enrollment_token_created? · ¿Qué indica el campo subAction en el webhook de InventoryItem? Key topics: Configuración de webhook, Payloads de eventos, Eventos de gestión de dispositivos, Gestión de integraciones, Applivery, HTTP POST, JSON, Apple Push Notification service (APNs), Plataformas ITSM ![webhooks](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/a78842cc-a70c-4563-8b35-9740ae11e2d1.png) Integra Applivery con servicios externos usando webhooks personalizados para recibir notificaciones en tiempo real sobre eventos clave de Gestión de Dispositivos. Los webhooks te permiten conectar Applivery con cualquier servicio externo que acepte peticiones HTTP POST — plataformas ITSM, dashboards personalizados, herramientas de automatización y mucho más. Cuando ocurre un evento relevante en Applivery, se envía automáticamente un payload JSON a la URL que configures. Para la Gestión de Dispositivos, los siguientes eventos pueden activar una notificación de webhook: - Se ha creado un nuevo **Token de inscripción**. - Un nuevo **Dispositivo** se ha inscrito correctamente. - Se ha asignado o cambiado un **Empleado** en un dispositivo. - El **Apple Push Certificate** está a punto de caducar. - Se ha registrado un nuevo **ítem de inventario**. ## Primeros pasos Las integraciones de webhook se pueden configurar a nivel de **Workspace**, de modo que las notificaciones de todos los dispositivos y la actividad de inscripción de tu organización se envíen a la URL configurada. **Ve a Integraciones** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a los **Ajustes del Workspace** 1 desde el menú desplegable superior, luego abre **Integraciones** 2 en el menú de la izquierda y haz clic en el botón **\+ Crear integración** 3. ![integrations](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/f35947b0-3416-4397-b188-4469361632d7.png) **Configura el Webhook** 1. Selecciona **Webhook** como tipo de integración. 2. Introduce la **URL** que debe recibir los payloads del webhook. 3. Selecciona los **eventos** a los que quieres suscribirte de la lista. 4. Haz clic en **Guardar**. ![device management webhook](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/abce7f4c-69a6-43ba-867b-035d5ca77964.png) ### Gestión de integraciones de webhook Después de guardar, serás redirigido a la sección Integraciones, donde tu nuevo webhook aparece con un resumen de su configuración: - **Tipo:** Webhook. - **Configuración:** La URL de destino. - **Eventos:** La lista de eventos suscritos. #### Editar un webhook Haz clic en una integración de webhook existente. Se abrirá un panel lateral donde podrás actualizar la URL de destino y los eventos suscritos. #### Eliminar un webhook Abre la integración de webhook y haz clic en el botón **Eliminar** en el panel lateral. ### Payloads de eventos Todas las notificaciones de webhook se entregan como peticiones HTTP POST con un cuerpo JSON. Usa el campo `action` para identificar el tipo de evento y dirigir tu lógica de procesamiento en consecuencia. El prefijo `{os}` en algunos nombres de acción se reemplaza en tiempo de ejecución por el identificador de plataforma — por ejemplo `emm` para Android o `win` para Windows. _[Accordion]_ Se activa cuando se ha creado un nuevo token de inscripción MDM."> ```json { "action": "emm_enrollment_token_created", "sendEmail": true, "enrollmentToken": { "type": "Fully Managed" }, "mdmUser": { "id": { "id": "5e9099ee4da32b180204770e", "email": "[email protected]" }, "email": "[email protected]", "url": "https://dashboard.applivery.io/test/mdm/users/5e9099ee4da32r180204770e" }, "organization": { "id": "5d4d1391cd523c15f50df235", "name": "Applivery Test", "url": "https://dashboard.applivery.io/test" } } ``` :::info El campo `enrollmentToken.type` indica el modo de gestión — por ejemplo, `Fully Managed` o `Work Profile`. ::: _[Accordion]_ Se activa cuando un nuevo dispositivo se ha inscrito correctamente en Applivery."> ```json { "action": "emm_device_enrolled", "organization": { "id": "5d4d1391cd523c15f50df235", "name": "Applivery Test", "url": "https://dashboard.applivery.io/test" }, "emmDevice": { "type": "Fully Managed", "url": "https://dashboard.applivery.io/test/mdm/users/5e9099ee4da32b180204770e?id=5f634c11034824062256e38c" }, "mdmUser": { "id": "5e9099ee4da32b180204770e", "email": "[email protected]", "url": "https://dashboard.applivery.io/test/mdm/users/5e9099ee4da32b180204770e" } } ``` _[Accordion]_ Se activa cuando se ha asignado o cambiado un empleado en un dispositivo gestionado."> ```json { "action": "win_device_added_mdm_user", "organization": { "id": "5c34ec7810399b6cc062a04a", "name": "Applivery Test", "url": "https://dashboard.applivery.io/test" }, "winDevice": { "productName": "", "url": "https://dashboard.applivery.io/test/mdm/users/65f83a5e4ecbfd693b7486d6?id=66d05845114a9509d18e7266" }, "mdmUser": { "id": "65f83a5e4ecbfd693b7486d6", "email": "[email protected]", "url": "https://dashboard.applivery.io/test/mdm/users/65f83a5e4ecbfd693b7486d6" }, "trigger": "deviceUpdate" } ``` :::info El campo `trigger` indica qué causó la asignación de usuario — por ejemplo, `deviceUpdate`. ::: _[Accordion]_ Se activa cuando el certificado Apple Push Notification (APNs) se acerca a su fecha de caducidad. Este certificado es necesario para que el MDM de Apple funcione. Renovarlo antes de que caduque es fundamental para mantener la Gestión de Dispositivos en dispositivos iOS, iPadOS y macOS."> ```json { "action": "apple_push_certification_renovation", "organization": { "id": "5d4d1391cd523c15f50df235", "name": "Applivery Test", "url": "https://dashboard.applivery.io/test" }, "numDays": "5", "appleId": "[email protected]" } ``` :::info El campo `numDays` indica cuántos días quedan antes de que caduque el certificado. El campo `appleId` identifica el Apple ID usado para crear el certificado. ::: _[Accordion]_ Se activa cuando se registra o actualiza un nuevo ítem en el Inventario. "> ```json { "action": "A new InventoryItem is being registered", "subAction": "created", "organization": { "id": "5d4d1391cd523c15f50df235", "name": "Applivery Test", "url": "https://dashboard.applivery.io/test" }, "inventoryItem": { "id": "62bd71d980df8b001b085ceb", "type": "monitor", "members": { "type": "mdmUser", "memberId": "6241d3d804e388001b3c605c", "email": "[email protected]" }, "metadata": {} } } ``` :::info Usa el campo `subAction` para determinar la operación específica realizada sobre el ítem de inventario — por ejemplo, `created`, `updated` o `deleted`. ::: ### Referencia de eventos | Acción | Disparador | | --- | --- | | `{os}_enrollment-token_created` | Se ha creado un nuevo token de inscripción MDM. | | `{os}_device_enrolled` | Un dispositivo se ha inscrito correctamente. | | `{os}_device_added_mdm_user` | Se ha asignado o cambiado un usuario MDM en un dispositivo. | | `apple_push_certification_renovation` | El Apple Push Certificate se acerca a su caducidad. | | `A new InventoryItem {action}` | Se ha registrado o actualizado un ítem en el Inventario. | --- ## Seguridad Source: https://docs.applivery.com/es/device-management/integrations/security/ Description: Explora las funciones de seguridad de Applivery para la protección de dispositivos, seguridad de comunicaciones y cumplimiento normativo. Integra Check Point y Threema. Dashboard centralizado. TL;DR: Applivery mejora la seguridad y el cumplimiento de los dispositivos a través de soluciones integradas y un dashboard centralizado. Answers: ¿Con qué soluciones de seguridad puede integrarse Applivery? · ¿Qué pueden gestionar los administradores desde el dashboard de seguridad de Applivery? · ¿Cómo mejora Applivery la seguridad de los dispositivos? · ¿Ayuda Applivery con el cumplimiento normativo? · ¿Puede Applivery proteger las comunicaciones? Key topics: seguridad de dispositivos, cumplimiento normativo, soluciones de seguridad integradas, Applivery, Check Point Harmony Mobile, Threema Work Las integraciones de seguridad te permiten ampliar la Gestión de Dispositivos de Applivery con herramientas de protección de terceros. Las integraciones admitidas actualmente incluyen Check Point Harmony Mobile para la defensa contra amenazas móviles y Threema Work para mensajería empresarial segura. Conecta cada integración de seguridad con Applivery y configúrala en tus políticas. --- ## Integración con Check Point Harmony Mobile Source: https://docs.applivery.com/es/device-management/integrations/security/checkpoint-harmony-mobile-integration/ Description: Integra Check Point Harmony Mobile con Applivery para una defensa avanzada contra amenazas móviles en dispositivos Android y Apple. TL;DR: Integra Check Point Harmony Mobile con Applivery para mejorar la seguridad móvil mediante la detección de amenazas en tiempo real y la gestión centralizada de políticas. Answers: ¿Cuál es la ventaja de integrar Check Point Harmony Mobile con Applivery? · ¿Cómo habilito la integración de Check Point Harmony Mobile en Applivery? · ¿Dónde encuentro el Portal Account ID de Harmony Mobile? · ¿Cómo se relacionan los grupos en Harmony Mobile con Applivery? · ¿Cómo configuro Harmony Mobile para dispositivos Android en Applivery? · ¿Por qué debo configurar la VPN permanente para Check Point Harmony Mobile en Android? · ¿Qué parámetros se necesitan para configurar la app Harmony Mobile Protection en Android? · ¿Qué parámetros se necesitan para configurar la app Harmony Mobile Protection en dispositivos Apple? · ¿Cómo configuro el perfil VPN de Check Point Harmony Mobile en dispositivos Apple? · ¿Dónde encuentro el token para completar la integración de Harmony Mobile y Applivery? Key topics: Integración con Applivery, Configuración de Check Point Harmony Mobile, Configuración para Android, Configuración para Apple, Defensa contra amenazas móviles, Check Point Harmony Mobile, Applivery, Android Enterprise, Harmony Mobile Protection App [CheckPoint Harmony Mobile](https://www.checkpoint.com/harmony/mobile-security/) se integra de forma nativa con Applivery para ofrecer defensa avanzada contra amenazas móviles y una seguridad integral de los dispositivos. Esta solución ofrece detección de malware en tiempo real, protección contra phishing y monitorización de seguridad de red, garantizando que los dispositivos corporativos estén continuamente protegidos frente a las amenazas emergentes. Con la integración de Harmony Mobile y Applivery, los administradores cuentan con una consola unificada para monitorizar los niveles de riesgo de los dispositivos, clasificarlos dinámicamente en grupos según la gravedad de la amenaza y aplicar políticas de seguridad personalizadas en consecuencia. La integración admite el despliegue Zero-touch, lo que permite la instalación y activación automática de la app Harmony Mobile Protect en flotas grandes sin intervención del usuario. ### En el panel de Applivery Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a los **Ajustes del Workspace** 1 desde el menú desplegable superior, luego abre **Integraciones** en el menú de la izquierda y habilita **Check Point Harmony Mobile** 2. ![checkpoint](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/93a2c2f8-e259-4b95-a684-810158c67c6d.png) Para iniciar la integración, escribe o pega el **Portal Account ID** del [Portal de Harmony Mobile](https://portal.checkpoint.com/signin). Puedes encontrarlo en **Ajustes > General > Account ID**. Una vez introducido, haz clic en Siguiente paso. Applivery mostrará toda la información que necesitas para habilitar la integración en el Portal de Harmony Mobile. ### En el Portal de Harmony Mobile Dirígete a **Ajustes**, selecciona **Integraciones** en el menú de la izquierda y añade una nueva integración (puedes seleccionar temporalmente Hexnode hasta que Applivery aparezca como opción). Alternativamente, puedes acceder directamente desde [este enlace](https://portal.checkpoint.com/dashboard/mobile/harmonymobile#/settings/integrations). En el formulario de integración, introduce un **Display Name** de tu elección y rellena la **Server Address**, el **Username** y la **Password** proporcionados en tu panel de Applivery. Una vez hecho, haz clic en **Verify** y, tras la verificación correcta, haz clic en **Next** para continuar. ![server-details | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/23fab5b4-1d97-4485-a9ce-c0d4e04cf471.png "server-details | Applivery") Una vez que los grupos terminen de cargarse, los asociados a tus dispositivos se añadirán automáticamente. Ten en cuenta que en Harmony Mobile, **los grupos corresponden a etiquetas** en Applivery, por lo que **las etiquetas deben estar asignadas a los dispositivos en Applivery** para que aparezcan en la lista de grupos de Harmony Mobile. :::info El campo de grupos de Android Enterprise en la integración UEM se usa para gestionar y proteger dispositivos Android con perfiles de trabajo y personales, permitiéndote aplicar diferentes políticas a cada perfil. Esta configuración es especialmente útil cuando trabajas con soluciones UEM que admiten Android Enterprise. Para más detalles, consulta la guía [Using Android Enterprise with Harmony Mobile](https://sc1.checkpoint.com/documents/Infinity_Portal/WebAdminGuides/EN/Harmony-Mobile-Integration-Guide/Topics-Integration-Guide/Citrix-Endpoint-Management/Using-Android-Enterprise-with-Harmony-Mobile.htm#_Ref40278689). ::: ![sync | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/f485b5aa-df8e-4e96-80dd-93bfbebb0a0f.png "sync | Applivery") A continuación, copia el **token** proporcionado en el último paso de la integración y pégalo en el campo correspondiente del panel de Applivery. ![token | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/2214524c-b3df-4399-9034-e07ae2d3fe9c.png "token | Applivery") Una vez completado, tus dispositivos empezarán a aparecer en la sección **Devices** del Portal de Harmony Mobile. Ten en cuenta que, hasta que un dispositivo esté completamente aprovisionado, su información puede aparecer vacía. ### Configuración para dispositivos Android **Habilitar Check Point Harmony Mobile** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a cualquiera de tus **Políticas**. En el menú lateral izquierdo, abre la sección **Seguridad** y habilita **Check Point Harmony Mobile**. ![checkpoint integration](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/08e4a155-f6f9-4bc6-9842-089cd3334ea4.png) **Configurar VPN permanente** Para que Check Point Harmony Mobile funcione correctamente, debes configurar la opción **Paquete Vpn siempre activa** con el nombre de paquete de la app Harmony Protect. Esto garantiza que el túnel VPN permanezca activo continuamente y que todo el tráfico del dispositivo esté protegido en todo momento. Dentro de la política, selecciona **Red** desde el menú lateral izquierdo y busca la configuración **Paquete Vpn siempre activa**. En el campo **Nombre del paquete**, introduce: `com.lacoon.security.fox` **Añadir la app Harmony Mobile Protection** Dirígete a la sección **Apps** y haz clic en el botón **\+ Añadir App**. Añade la app **Harmony Mobile Protection**. Una vez seleccionada, sus propiedades gestionadas aparecerán automáticamente: - El **MDM UUID** (usando interpolaciones, obtenido del resumen de red del dispositivo bajo UDID). - La **GW Address** y el **Infinity Portal Account ID** (ambos encontrados en los ajustes del Portal de Harmony Mobile). - El **Token**, que obtendrás del último paso de la integración, generalmente se añade automáticamente. ![harmony app](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/eb66541c-dcd8-4d8b-9778-8f49f44b8e91.png) **Completar la configuración en el dispositivo** Abre la app en el dispositivo y completa el proceso de configuración. Una vez activa la integración, cualquier nueva alerta aparecerá en el portal a medida que se produzca. ### Configuración para dispositivos Apple **Configurar el perfil VPN** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a cualquiera de tus **Políticas**. Haz clic en **+ Añadir configuración**, selecciona el tipo de perfil **VPN** y configura los siguientes campos: | Campo | Valor | |---|---| | **Nombre definido por el usuario** | `Check Point Local Tunnel` | | **Nombre de usuario de la cuenta** (bajo VPN) | `{{device.serialNumber}}` | | **Método de autenticación** (bajo VPN) | `Certificado` | | **Dirección remota** (bajo VPN) | `www.checkpoint.com` | | **Subtipo VPN** | `com.checkpoint.capsuleprotect` | | **Tipo** | `VPN` | | **Configuración del vendedor** | `{ "zero_touch": "true" }` | A continuación, selecciona **Activar VPN bajo demanda** (`1`) y añade las siguientes Reglas bajo demanda: | Acción a petición | Coincidencia de tipo de interfaz | |---|---| | Conecta | Wi-Fi | | Conecta | Cellular | Opcionalmente, añade una tercera regla con **Conecta** + **Ethernet** para conexiones por cable. **Añadir la app Harmony Mobile Protection** Añade la app **Harmony Mobile Protection** a tu política, asegurándote de tener suficientes [licencias VPP](https://docs.applivery.com/es/device-management/apple/app-management/vpp/) disponibles. Configura los parámetros requeridos en el campo de configuración: - `Lacoon Server Address`: `eu-gw.locsec.net` - `Device Serial Number`: `{{device.serialNumber}}` - `token`: Usa tu token aquí. - `ios_dep_notification_permission`: `true` - `portalAccountId`: ID de cuenta de Harmony Mobile. ![harmony mobile protect configuration](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/47b4a1a0-b6b9-4e8b-b4e0-e5c3e910553f.png) --- ## Integración con Threema Work Source: https://docs.applivery.com/es/device-management/integrations/security/threema-work-integration/ Description: Integra Threema Work con el MDM de Applivery para la gestión centralizada de usuarios y políticas de comunicaciones empresariales seguras. TL;DR: Integra Threema Work con el MDM de Applivery para gestionar centralizadamente licencias y configurar políticas de mensajería empresarial segura en dispositivos Android y Apple. Answers: ¿Qué es Threema Work? · ¿Threema Work requiere número de teléfono o dirección de email? · ¿Cómo creo licencias MDM en Threema Work? · ¿Qué credenciales se necesitan para las licencias MDM en Threema Work? · ¿Cómo guardo la contraseña de las licencias MDM de Threema Work? · ¿Cómo creo una política para Threema Work en Applivery? · ¿Qué claves de configuración incluye la plantilla de política de Threema Work en Applivery? · ¿Cómo configuro Threema Work en Applivery para dispositivos Apple? Key topics: Creación de licencias MDM en Threema Work, Configuración de políticas en Applivery, Configuración de Threema Work en Android, Configuración de Threema Work en Apple, Threema Work, Applivery, Android, iOS, RGPD [Threema Work](https://work.threema.ch/en/login) es una solución de mensajería empresarial segura diseñada para uso profesional en organizaciones que priorizan la protección de datos y la privacidad. A diferencia de las apps de mensajería convencionales, Threema Work garantiza el cifrado de extremo a extremo en todas las comunicaciones, incluidos mensajes, llamadas de voz y archivos. Cumple con estrictas normativas de privacidad como el RGPD y no requiere número de teléfono ni dirección de email, preservando el anonimato del usuario. Diseñado para entornos corporativos, Threema Work ofrece gestión centralizada de usuarios y políticas. Los administradores de TI pueden preconfigurar la app, aplicar políticas de uso y distribuirla a escala en todos los dispositivos gestionados. ### Crea las licencias MDM en Threema Work Para empezar, inicia sesión en [Threema Work](https://work.threema.ch/en/login) y selecciona tu suscripción activa. Ve a la sección **Gestión de usuarios** 1 y haz clic en + **Añadir** 2 para comenzar a asignar licencias MDM a tu suscripción. ![threema-user-management](https://www.applivery.com/wp-content/uploads/2025/05/threema-user-management-2-1024x415.png "threema-user-management | Applivery") Elige la opción **Licencia para sistema MDM** 3 y especifica un nombre de usuario y una contraseña — estas credenciales se usarán posteriormente para integrar las licencias con Applivery. Puedes guardar la contraseña en texto plano o como hash. Si eliges una contraseña hasheada, asegúrate de guardar el enlace que se muestra tras hacer clic en **Guardar**, ya que las contraseñas hasheadas no se pueden recuperar después. :::info Si se guarda en texto plano, las credenciales permanecerán visibles y se pueden copiar en cualquier momento haciendo clic en los tres puntos junto a la entrada de la licencia. ::: ![threema-license-mdm](https://www.applivery.com/wp-content/uploads/2025/05/threema-license-mdm-1024x415.png "threema-license-mdm | Applivery") Selecciona el número deseado de licencias para la Gestión de Dispositivos de Applivery y haz clic en **Guardar** 4. ### Crea una política para Threema Work en Applivery Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a la sección **Políticas** y crea una nueva. Haz clic en el botón **\+ Crear Política**. Selecciona el sistema operativo deseado y elige la plantilla **Threema Work**, que viene con una política de configuración predefinida que incluye los siguientes parámetros: | Claves de configuración | Tipo de valor | Descripción | | --- | --- | --- | | th_license_username | String | MDMLicenseCompany | | th_license_password | String | Password123! | | th_firstname | String | {{user.firstname}} | | th_csi | String | {{use.email}} | | th_safe_enable | Boolean | True | ![threma apple](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/48713e7d-c00f-41cc-a266-f039db5267d7.png) Si seleccionaste **Apple**, dirígete a la sección **Apps** del menú de la izquierda, busca la app **Threema Work** y haz clic en el icono de **ajustes** al final de su fila. Ahora puedes configurar la app usando los parámetros proporcionados a continuación: ![threma appe configuration](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/2a41e2d3-253f-4023-9e9f-a302c75ca978.png) Si seleccionaste **Android**, dirígete a la sección **Apps** y haz clic en la app **Threema Work**. Aparecerá un menú en el lado derecho con las propiedades gestionadas disponibles. ![threma android configuration](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/2b8b97f5-75c9-4dfc-a35e-b17d6f370ced.png) --- ## SSO Source: https://docs.applivery.com/es/device-management/integrations/sso/ Description: Configura el SSO en la Gestión de Dispositivos de Applivery con Okta y Google Workspace — simplifica la autenticación y el aprovisionamiento de usuarios. TL;DR: Configura el SSO en Applivery con Okta o Google Workspace para una autenticación centralizada y el aprovisionamiento de usuarios. Answers: ¿Qué es el SSO en Applivery? · ¿Qué proveedores de identidad puedo usar con el SSO de Applivery? · ¿Qué pueden hacer los administradores con el SSO de Applivery? · ¿Cuál es la ventaja de usar SSO en Applivery? · ¿Ofrece el SSO de Applivery gestión centralizada de usuarios? Key topics: Configuración del SSO, Integración con proveedor de identidad, Autenticación de usuarios, Control de acceso, Applivery, SSO, Okta, Google Workspace Las integraciones SSO permiten a tu equipo autenticarse en el panel de Applivery usando el proveedor de identidad existente de tu organización. Applivery admite SSO basado en SAML con proveedores como Okta, Azure AD y Ping Identity, así como el aprovisionamiento automatizado de usuarios y grupos mediante SCIM. Configura el SSO para la Gestión de Dispositivos, desde la configuración del proveedor de identidad hasta la asignación de grupos y roles en Applivery. --- ## Google Workspace Source: https://docs.applivery.com/es/device-management/integrations/sso/google-workspace/ Description: Configura Google Workspace con el MDM de Applivery — establece credenciales OAuth 2.0 para una integración fluida de Gestión de Dispositivos y SSO. TL;DR: Configura Google Workspace con el MDM de Applivery creando un proyecto en Google Cloud Platform, configurando credenciales OAuth 2.0 y habilitando el acceso a la API. Answers: ¿Cuáles son los requisitos previos para configurar la integración de Google Workspace en Applivery? · ¿Cómo creo un nuevo proyecto en Google Cloud Platform para Applivery? · ¿Qué tipo de usuario debo seleccionar para la pantalla de consentimiento OAuth? · ¿Cuál es el URI de redirección autorizado para las credenciales OAuth de Applivery? · ¿Dónde introduzco el Google Client ID y el Client Secret en Applivery? · ¿Qué significa el error "5137: Could not retrieve user groups (invalid_grant)"? · ¿Cómo soluciono el error "invalid_grant" al integrar Google Workspace? Key topics: Configuración de Google Cloud Platform, Configuración de OAuth 2.0, Integración MDM con Applivery, Acceso a la API, Google Workspace, Applivery, Google Cloud Platform, OAuth 2.0, Admin SDK API :::warning Esta es una función premium que puede no estar disponible en tu plan actual. Consulta la disponibilidad en nuestra [página de precios](https://www.applivery.com/pricing/). ::: Para configurarla, asegúrate de tener acceso de administrador al Google Workspace de tu organización. De esta forma, podrás crear un nuevo proyecto u obtener los permisos necesarios para configurar las credenciales OAuth 2.0 para un proyecto existente. Sigue los pasos siguientes con atención. ### Configura tu Google Workspace **Crea un nuevo proyecto en Google Cloud Platform (GCP)** Inicia sesión en la [consola](https://console.cloud.google.com/) de Google Cloud Platform. Esta es diferente de tu consola de Google Workspace. Se necesita un proyecto de Google Cloud para habilitar las APIs de Google Workspace. Ve a **IAM y administración** > **Crear proyecto**. Ponle un nombre al proyecto y selecciona **Crear**. A continuación, dirígete a **APIs y servicios** y haz clic en **\+ Habilitar APIs y servicios**. Esto cargará la Biblioteca de API. Una vez en la biblioteca, busca `admin`, elige la **Admin SDK API** y procede a **habilitarla**. Vuelve a la página de **APIs y servicios** y ve a **Credenciales**. Verás un aviso indicando que debes configurar una pantalla de consentimiento. Selecciona **Configurar pantalla de consentimiento.** Verifica el nombre del proyecto que aparece en la esquina superior izquierda junto al logo para asegurarte de estar usando el proyecto correcto. ![Credentials | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/eb68983c-831e-4bc4-9d2a-92f7f68703b0.png "Credentials | Applivery") **Configura la pantalla de consentimiento** Selecciona **Interno** como tipo de usuario. Esta opción restringe las solicitudes de autorización a los usuarios de tu Google Workspace, evitando el acceso de personas con cuentas de Gmail estándar. Proporciona un nombre para la aplicación, incluye un email de soporte y rellena los campos de contacto. Ten en cuenta que Google Cloud Platform requiere un email de tu cuenta. Puedes dejar la página de **Permisos** vacía. Una vez que se cargue la página de resumen, guarda tu configuración y sal. **Configura las credenciales** Vuelve a la página de **Credenciales** y selecciona **\+ Crear credenciales** > **ID de cliente de OAuth**. ![68747470733a2f2f6465762d646f63732e636c6f7564666c6172656163636573732e6f72672f6163636573732f7374617469632f636c6f7564666c6172652d6f6e652f6964656e746974792f6773756974652f6372656174652d6f617574682e706e67 | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/04de0208-0982-4051-8229-0bdcfbac0ca8.png "68747470733a2f2f6465762d646f63732e636c6f7564666c6172656163636573732e6f72672f6163636573732f7374617469632f636c6f7564666c6172652d6f6e652f6964656e746974792f6773756974652f6372656174652d6f617574682e706e67 | Applivery") Elige **Aplicación web** como tipo de aplicación. Para el campo **URI de redireccionamiento autorizados**, introduce: `https://mdm-portal.applivery.io/login/`. Google proporcionará los valores de **OAuth Client ID y Secret**. Recuerda que el campo secret funciona como contraseña y debe mantenerse confidencial. Copia ambos valores. En tu [consola de administración de Google](https://admin.google.com/), dirígete a **Seguridad** > **Acceso y control de datos** > **Controles de API**, abre el menú Ajustes y habilita la opción **Confiar en apps internas de dominio propio**. ![Untitled | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/be6e9f9b-6821-4e5f-a797-7aa21b20ebc0.jpg "Untitled | Applivery") ### Obtén la información del proveedor de servicios en Applivery Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a los **Ajustes del Workspace** 1 desde el menú desplegable superior, luego abre ** Proveedores de acceso** 2 en el menú de la izquierda y haz clic en la opción **Google Workspace** bajo la sección **Portal MDM** 3. ![google Workspace login provider](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/2d3b3e80-afde-4dab-9bb6-e1f8808c6892.png) Verás tu configuración de Google Workspace, donde necesitarás introducir los campos **Client ID** y **Client Secret**. ![google Workspace](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/10cdb784-b181-4b68-af61-dc4125b31719.png) ### Resolución de problemas #### Error 5137: Could not retrieve user groups (`invalid_grant`) Cuando un usuario intenta inscribir un dispositivo a través del MDM Portal, puede ver el siguiente error: ``` 5137: {"reason":"Could not retrieve user groups","err":"invalid_grant"} ``` Este error significa que la autorización de Applivery para leer los grupos de Google Workspace ha caducado o ha sido revocada. Para solucionarlo, debes volver a autorizar a Applivery. **Abre los Ajustes del Workspace** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), haz clic en el menú desplegable de la esquina superior derecha y ve a **Ajustes del Workspace**. **Volver a autorizar a Applivery** En el menú de la izquierda, dirígete a **Proveedores de acceso** y haz clic en **Configurar** junto a la opción **Google Workspace** bajo la sección **MDM Portal**. En el **Paso 2**, haz clic en la palabra **aquí** para conceder a Applivery permiso para obtener grupos de nuevo. ![reauthorize](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/8ece9115-1122-40a4-9aa2-d8f837f1958b.png) Una vez completada la autorización, el flujo de inscripción debería funcionar sin errores. --- ## Aprovisionamiento de usuarios SCIM y gestión de atributos Source: https://docs.applivery.com/es/device-management/integrations/sso/scim-attribute-creation-and-assignment-in-okta/ Description: Gestiona el aprovisionamiento de usuarios y atributos en Okta usando SCIM — esquemas core, enterprise y personalizados para una gestión de identidad fluida. TL;DR: Aprende a gestionar el aprovisionamiento de usuarios y atributos en Okta usando SCIM, incluyendo la creación de atributos personalizados y su mapeo en tus aplicaciones. Answers: ¿Qué es SCIM? · ¿Qué esquemas SCIM admite Okta? · ¿Cuál es el URN del esquema de usuario principal en Okta SCIM? · ¿Cómo creo un atributo SCIM personalizado en Okta? · ¿Qué propiedades son obligatorias al crear un atributo SCIM personalizado en Okta? · ¿Cómo asigno atributos en Okta para SCIM? · ¿Cuál es la ruta del atributo SCIM para el departamento de un usuario en Okta? · ¿Cuál es la ruta del atributo SCIM para el nombre de pila de un usuario en Okta? Key topics: Esquemas SCIM, Atributos personalizados, Mapeo de atributos, Aprovisionamiento en Okta, Okta, SCIM, JSON, URN :::warning Esta es una función premium que puede no estar disponible en tu plan actual. Consulta la disponibilidad en nuestra [página de precios](https://www.applivery.com/pricing/). ::: SCIM (System for Cross-domain Identity Management) es un estándar abierto que automatiza el intercambio de datos de identidad de usuario entre sistemas. Okta incluye soporte nativo de SCIM 2.0 para el aprovisionamiento, la sincronización de usuarios y la gestión del ciclo de vida de atributos con aplicaciones de terceros. ### Esquemas SCIM admitidos Okta implementa varios esquemas SCIM 2.0, cada uno definiendo un conjunto de atributos que describen a un usuario. Estos esquemas se usan durante el aprovisionamiento de usuarios y las operaciones de sincronización. #### Esquema de usuario principal (Core User Schema) - **URN**: `urn:ietf:params:scim:schemas:core:2.0:User`. El esquema principal contiene los atributos de usuario SCIM 2.0 estándar y siempre se incluye en los payloads SCIM salientes. ##### Ejemplo JSON ``` { "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"], "id": "00u12345abcdXYZ", "userName": "john.doe@example.com", "name": { "formatted": "John Doe", "familyName": "Doe", "givenName": "John", "middleName": "A", "honorificPrefix": "Mr.", "honorificSuffix": "Jr." }, "displayName": "John Doe", "nickName": "Johnny", "profileUrl": "https://example.com/john.doe", "emails": [ { "value": "john.doe@example.com", "type": "work", "primary": true } ], "addresses": [ { "type": "work", "streetAddress": "123 Main St", "locality": "San Francisco", "region": "CA", "postalCode": "94105", "country": "US", "primary": true } ], "phoneNumbers": [ { "value": "+1-415-555-1234", "type": "work" } ], "preferredLanguage": "en-US", "locale": "en-US", "timezone": "America/Los_Angeles", "active": true, "password": "hashed-password" } ``` #### Esquema de usuario enterprise - **URN**: `urn:ietf:params:scim:schemas:extension:enterprise:2.0:User`. Este esquema amplía el recurso de usuario principal con atributos centrados en la empresa, como departamento, responsable y centro de coste. ``` { "schemas": [ "urn:ietf:params:scim:schemas:core:2.0:User", "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User" ], "userName": "john.doe@example.com", "name": { "givenName": "John", "familyName": "Doe" }, "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User": { "employeeNumber": "E12345", "costCenter": "CC1001", "organization": "Engineering", "division": "Software Development", "department": "R&D", "manager": { "managerId": "00u67890abcdXYZ", "displayName": "Jane Smith" } } } ``` #### Esquema de extensión personalizado - **URN**: `urn:okta:custom:schema`. Okta permite a los administradores definir esquemas personalizados para atributos que no encajan en el estándar SCIM. Este esquema puede usar cualquier cadena URN de tu elección. ``` { "schemas": [ "urn:ietf:params:scim:schemas:core:2.0:User", "urn:okta:custom:schema" ], "userName": "john.doe@example.com", "name": { "givenName": "John", "familyName": "Doe" }, "urn:okta:custom:schema": { "customEmployeeType": "Contractor", "customStartDate": "2024-01-10", "customSecurityClearance": "Level 3" } } ``` ### Creación de nuevos atributos personalizados Para definir y exponer un nuevo atributo SCIM personalizado en Okta, empieza abriendo tu aplicación SCIM y navegando a **Aplicaciones** > **Tu app SCIM** > **Aprovisionamiento** > **Para la app**. A continuación, dirígete al Editor de perfiles haciendo clic en **Ir al editor de perfiles**. Desde allí, crea un nuevo atributo haciendo clic en **Añadir atributo** y configura las siguientes propiedades: - **Nombre de pantalla** (por ejemplo, Nivel de acceso de seguridad). - **Nombre de variable** (p. ej., `customSecurityClearance`). - **Nombre externo** (la clave del atributo SCIM, como `urn:okta:custom:schema:customSecurityClearance`). - **Espacio de nombres externo** (el URN de tu esquema personalizado). - **Tipo de datos** (`String`, `Boolean`, `Number` o `Date`). Después de guardar el nuevo atributo, asígnalo al perfil de un usuario abriendo cualquier usuario en Okta y confirmando que el atributo aparece en la sección de perfil. ### Mapeo de atributos en Okta Después de crear atributos estándar y personalizados, es necesario asignarlos para garantizar que los datos fluyan correctamente entre Okta y tu aplicación habilitada para SCIM. Para ello, dirígete a **App SCIM** > **Aprovisionamiento** > **Para la app** y haz clic en **Editar** para habilitar el mapeo de atributos. Para cada atributo que quieras asignar, selecciona **el Atributo del perfil de usuario de Okta correspondiente** (por ejemplo, `user.profile.department`) y especifica la **ruta del atributo de la app** (p. ej., `urn:ietf:params:scim:schemas:extension:enterprise:2.0:User.department`). Una vez configurados todos los mapeos, guarda los cambios. Por último, prueba el aprovisionamiento actualizando un usuario en Okta y verificando que los cambios se propagan correctamente a la aplicación de destino a través de la API SCIM. ### Tabla de mapeo de ejemplo | Atributo OKTA | Ruta del atributo SCIM | | --- | --- | | `user.profile.firstName` | `name.givenName` | | `user.profile.lastName` | `name.familyName` | | `user.profile.email` | `emails[primary eq true].value` | | `user.profile.department` | `urn:ietf:params:scim:schemas:extension:enterprise:2.0:User.department` | | `user.profile.customSecurityClearance` | `urn:okta:custom:schema:customSecurityClearance` | --- ## Mapeo de atributos SCIM Source: https://docs.applivery.com/es/device-management/integrations/sso/scim-attributes-mapping/ Description: Asigna atributos SCIM a los metadatos de usuario en Applivery para mantener la información de usuario consistente — personaliza el mapeo de atributos para una mejor Gestión de Usuarios. TL;DR: Applivery permite asignar atributos SCIM a los metadatos de usuario para una gestión mejorada, configurando mapeos personalizados y siguiendo reglas de resolución específicas. Answers: ¿Cuál es la finalidad de attributesHistory en el SCIM de Applivery? · ¿Cómo asigno atributos SCIM a los metadatos de usuario en Applivery? · ¿Qué es el campo name en la configuración mappedAttributes? · ¿Cómo resuelve Applivery qué valor SCIM asignar a los metadatos? · ¿Dónde puedo encontrar los Ajustes de proveedores de inicio de sesión en Applivery? · ¿Cómo determino el namespace correcto para el mapeo de atributos SCIM en Applivery? · ¿Qué ocurre después de guardar los cambios del mapeo de atributos SCIM en Applivery? · ¿Es el mapeo de atributos SCIM una función premium de Applivery? Key topics: Mapeo de atributos SCIM, Configuración de metadatos de usuario, Integración SCIM con Applivery, Resolución de atributos SCIM, Integración con proveedor de identidad, SCIM, Applivery, IdP, Okta :::warning Esta es una función premium que puede no estar disponible en tu plan actual. Consulta la disponibilidad en nuestra [página de precios](https://www.applivery.com/pricing/). ::: Al recibir información de usuario a través de SCIM, los datos a menudo se organizan en varios esquemas. Para mantener esta información consistente, utilizable y accesible, Applivery puede asignar atributos SCIM específicos al campo `metadata` del usuario. ### Entender el almacenamiento de atributos SCIM Todos los campos SCIM mapeables se almacenan automáticamente en un objeto interno llamado `attributesHistory`. Este objeto rastrea cada atributo recibido de SCIM, esté o no actualmente asignado a metadatos. #### Historial de atributos SCIM El objeto `attributesHistory` contiene todos los atributos SCIM con la siguiente estructura: ```typescript type IProviderSCIMAttributesHistory = { namespace: string key: string } ``` Este objeto se puebla automáticamente con todos los atributos proporcionados en las solicitudes SCIM. Su propósito es servir como registro completo de cualquier campo que pueda potencialmente ser asignado. #### Mapeo de atributos personalizado Para asignar campos SCIM a los metadatos del usuario, puedes definir un mapeo personalizado a través de la propiedad `mappedAttributes` en el modelo de configuración SCIM. ```typescript type IProviderSCIMCustomAttributes = { name: string attributes?: { namespace?: string key: string }[] } ``` Cada entrada de mapeo admite los siguientes campos: - **Name**: La clave bajo la que se almacenará el valor asignado dentro de los metadatos del usuario. - **Attributes**: Una lista de atributos SCIM (especificando opcionalmente su namespace/esquema) que se usarán para generar este valor de metadatos. :::tip Para obtener orientación sobre cómo definir atributos personalizados dentro de tu proveedor de identidad (IdP), consulta el [siguiente artículo de nuestra documentación](https://docs.applivery.com/es/device-management/integrations/sso/scim-attribute-creation-and-assignment-in-okta/). ::: #### Reglas de resolución Al resolver qué valor SCIM asignar a `metadata`, Applivery sigue estas reglas: 1. Si se especifica un namespace, el sistema busca el atributo SCIM dentro de ese namespace/esquema exacto. 2. Si no se define ningún namespace, el sistema asigna la primera clave de atributo coincidente encontrada en cualquier esquema. 3. Cuando un payload SCIM incluye un valor para un atributo personalizado asignado, Applivery lo escribe automáticamente en los `metadata` del usuario: - **Key**: El nombre definido en la entrada de `mappedAttributes`. - **Value**: El valor del atributo SCIM resuelto basado en las reglas de mapeo. #### Ejemplo de mapeo basado en namespace ##### Payload SCIM ```json { "schemas": [ "urn:ietf:params:scim:schemas:core:2.0:User", "urn:company:params:scim:schemas:extension:custom:2.0:User" ], "urn:ietf:params:scim:schemas:core:2.0:User": { "userName": "jane.smith" }, "urn:company:params:scim:schemas:extension:custom:2.0:User": { "employeeId": "EMP-4567", "department": "Engineering" } } ``` ##### Configuración de mapeo personalizado ```javascript const mappedAttributes = [ { name: "department", attributes: [ { namespace: "urn:company:params:scim:schemas:extension:custom:2.0:User", key: "department" } ] }, { name: "employeeCode", attributes: [ { namespace: "urn:company:params:scim:schemas:extension:custom:2.0:User", key: "employeeId" } ] } ] ``` ##### Resultado en los metadatos del usuario ```json { "metadata": { "department": "Engineering", "employeeCode": "EMP-4567" } } ``` ### Configura el mapeo de atributos en Applivery **Ve a los Ajustes de proveedores de inicio de sesión** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a los **Ajustes del Workspace** 1 desde el menú desplegable superior, luego abre ** Proveedores de acceso** 2 en el menú de la izquierda y haz clic en la opción **SAML** bajo la sección **Portal MDM** 3. ![login providers](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/0c5fb7b6-4277-4b92-830c-ebb4a3cdc744.png) **Introduce el namespace** Desplázate hasta el **Paso 3** e introduce el namespace apropiado. Puedes determinar el namespace correcto basándote en el tipo de atributo (Core, Enterprise o Custom) y su valor. ![attribute mapping](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/1295fb1c-b743-4791-8354-339c41df6e2c.png) **Guarda los cambios** Para guardar los cambios, simplemente haz clic en Guardar. Una vez que tu IdP realice su próxima sincronización programada, los atributos asignados en ambos lados empezarán a poblar los `metadata` de cada usuario en Applivery. En resumen: - Los atributos SCIM se pueden asignar a los metadatos de usuario usando `mappedAttributes`. - El `namespace` ayuda a distinguir atributos cuando hay múltiples esquemas implicados. - Los atributos SCIM no asignados se almacenan en `attributesHistory` para referencia futura. - Este sistema de mapeo te da control total sobre cómo se almacenan y aprovechan los datos de usuario. --- ## Windows Source: https://docs.applivery.com/es/device-management/windows/ Description: Gestiona dispositivos Windows a escala con Applivery. Inscribe, configura políticas, despliega apps y garantiza el cumplimiento. Answers: ¿Qué puedo hacer con la gestión de dispositivos Windows en Applivery? · ¿Qué políticas puedo configurar para dispositivos Windows en Applivery? · ¿Cómo puedo desplegar apps en dispositivos Windows con Applivery? · ¿Puede Applivery mantener mis dispositivos Windows actualizados? · ¿Qué tipos de dispositivos Windows puede gestionar Applivery? · ¿Admite Applivery la configuración de BitLocker para dispositivos Windows? · ¿Puedo gestionar la configuración del Firewall de Windows desde Applivery? Applivery te permite inscribir, proteger y gestionar dispositivos Windows a escala. Puedes desplegar apps desde la Microsoft Store o como paquetes Win32, configurar Políticas para BitLocker, Firewall y más, y mantener los dispositivos actualizados y en cumplimiento — todo desde un único panel. La Gestión de Dispositivos Windows en Applivery incluye métodos de inscripción, gestión de apps, políticas y resolución de problemas. --- ## Gestión de apps Source: https://docs.applivery.com/es/device-management/windows/app-management/ Description: Gestión de Apps de Windows en Applivery — despliega, actualiza y controla apps en Dispositivos Windows a escala desde un panel centralizado. Answers: ¿Qué es la Gestión de Apps de Windows en Applivery? · ¿Qué pueden hacer los administradores con la Gestión de Apps de Windows de Applivery? · ¿Cómo gestiona Applivery los dispositivos Windows? · ¿Puede Applivery configurar el modo quiosco en dispositivos Windows? · ¿Puede Applivery gestionar ajustes OEM en dispositivos Windows? La Gestión de Apps de Windows en Applivery te permite desplegar y mantener aplicaciones en Dispositivos Windows gestionados a escala. Puedes instalar apps desde la Microsoft Store, desplegar paquetes Win32 (`.msi`, `.exe`) y gestionar las asignaciones de apps a través de políticas. Elige un método de distribución de apps para Windows, sube y configura apps, y asígnalas a dispositivos o usuarios. --- ## Bloquear la Microsoft Store Source: https://docs.applivery.com/es/device-management/windows/app-management/block-microsoft-store/ Description: Deshabilita el acceso a la Microsoft Store en Dispositivos Windows propiedad de la empresa usando las políticas de Applivery para mejorar la seguridad y el cumplimiento. TL;DR: Aprende a bloquear la Microsoft Store en dispositivos Windows con Applivery para mejorar la seguridad y controlar las instalaciones de apps. Answers: ¿Por qué debería deshabilitar la Microsoft Store en dispositivos de empresa? · ¿Cómo accedo a los ajustes de política en Applivery para bloquear la Microsoft Store? · ¿Dónde encuentro la configuración de Windows Store en Applivery? · ¿Qué ajuste habilito para deshabilitar la Microsoft Store en Applivery? · ¿Cuál es el primer paso para bloquear la Microsoft Store con Applivery? · ¿Cuáles son los riesgos de permitir el acceso a la Microsoft Store en dispositivos de empresa? · ¿Puedo bloquear la Microsoft Store en dispositivos específicos con Applivery? Dado que cualquier usuario puede descargar e instalar apps desde la Microsoft Store, puede convertirse en un riesgo de seguridad para los dispositivos propiedad de la empresa. Las apps no autorizadas pueden introducir vulnerabilidades, violar las políticas de cumplimiento o interferir con las configuraciones empresariales. Para mantener un entorno seguro y controlado, se recomienda deshabilitar el acceso a la Microsoft Store en los dispositivos Windows gestionados. Esto puede lograrse fácilmente a través de Applivery configurando la política adecuada. ### Configurar tu política En el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a **Políticas** 1. Elige la política en la que quieres bloquear la Microsoft Store. Luego, en el menú de la izquierda, haz clic en **\+ Añadir configuración** 2 y usa la barra de búsqueda para encontrar la Directiva de Grupo **Windows Store** 3. ![microsoft store](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/e8f2ce9b-1b04-4896-b34a-83690aa4661b.png) A continuación, habilita el ajuste **Desactivar la aplicación de la Tienda** para deshabilitar la Microsoft Store en tus dispositivos. ![turn off store](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/8025fead-abeb-4d2e-9264-bdc84eabf4d8.png) --- ## Gestión de apps Source: https://docs.applivery.com/es/device-management/windows/app-management/manage-apps/ Description: Gestiona Apps de Windows con Applivery MDM — despliega, actualiza y controla software en Dispositivos Windows para la seguridad y el cumplimiento. TL;DR: Applivery MDM simplifica la gestión de apps en Windows ofreciendo herramientas para desplegar, actualizar y controlar aplicaciones en toda tu flota de dispositivos Windows. Answers: ¿Cuáles son las opciones de tipo de instalación para apps de Windows en Applivery? · ¿Cómo agrego una app de Windows a una política en Applivery? · ¿Qué fuentes de apps se admiten para el despliegue de apps de Windows en Applivery? · ¿Cuándo debería usar la Microsoft Store como fuente de apps en Applivery? · ¿Cuándo debería usar la opción Recursos para el despliegue de apps en Applivery? · ¿Cuál es la diferencia entre 'Tu Workspace' y 'App Catalog' en Applivery? · ¿Para qué se usa elcCatálogo de Apps en Applivery? · ¿Cómo gestiona Applivery las aplicaciones de Windows? La gestión de aplicaciones es un pilar fundamental de cualquier estrategia de Gestión de Dispositivos Móviles (MDM) de Windows. En entornos corporativos, garantizar que los dispositivos ejecuten solo software aprobado, correctamente configurado y actualizado es esencial para mantener la seguridad, la productividad y el cumplimiento de las políticas internas. Applivery proporciona un conjunto completo de herramientas para gestionar de forma centralizada las aplicaciones en Dispositivos Windows a escala, permitiendo a los equipos de TI desplegar, actualizar y controlar el software sin requerir interacción del usuario. A través de las políticas MDM nativas y, cuando sea necesario, el agente Windows de Applivery, los administradores pueden abordar tanto los escenarios de despliegue estándar como los casos de uso avanzados que requieren un control más profundo. ### Opciones de tipo de instalación - **Instalación forzosa**: La app se instalará de forma forzada. - **Disponible**: La app estará disponible para instalarse bajo demanda, ya sea desde el panel o usando el Self-Service en los dispositivos Windows. ### Gestión de apps En el [**panel de Applivery**](https://dashboard.applivery.io), dirígete a cualquiera de tus **Políticas** 1. En el menú lateral izquierdo, dirígete a **Apps** 2 y haz clic en el botón **\+ Añadir App** 3. Aparecerá una ventana modal que te permitirá seleccionar la fuente de la aplicación. ![add app](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/60217f47-ed98-4fdd-af94-18cad5f02c99.png) - **Microsoft Store**: Esta fuente te permite desplegar aplicaciones directamente desde la Microsoft Store. Es la opción recomendada para las aplicaciones modernas que admiten la gestión MDM, ya que garantiza la integración nativa con Windows, mayor seguridad y actualizaciones automáticas. - **Applivery**: Esta fuente hace referencia a las aplicaciones distribuidas directamente a través de Applivery (Distribución de Apps o catálogo de apps). - **Recurso**: Esta fuente permite el despliegue de aplicaciones empaquetadas en formatos `.msi`, `.msix` y `.appx` que se han cargado previamente a la sección de Recursos en Applivery, o que se pueden cargar directamente usando el botón **Cargar nuevo recurso**. Esta opción es ideal para aplicaciones corporativas internas, software de terceros o instaladores personalizados que no están disponibles en la Microsoft Store. #### Gestión de Apps de Applivery Hay dos opciones para gestionar aplicaciones a través de Applivery. ![app management](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/6f7d0616-6993-48f7-8181-2d8885a89807.png) Por un lado, puedes seleccionar **Tu Workspace**: aplicaciones que se han subido previamente a tu Workspace a través de Distribución de Apps. Estas aplicaciones se gestionan y despliegan directamente usando Applivery, permitiendo a los administradores controlar la instalación, las actualizaciones y la disponibilidad en toda la flota de dispositivos. Por otro lado, puedes elegir **App Catalog**. Esta opción está directamente vinculada a las aplicaciones gestionadas por el agente de Applivery. El catálogo de apps permite a los usuarios finales instalar aplicaciones aprobadas bajo demanda a través de la experiencia de Self-Service, mientras TI mantiene el control total sobre qué aplicaciones están disponibles. Este enfoque reduce la carga administrativa, mejora la flexibilidad y empodera a los usuarios sin comprometer la seguridad o el cumplimiento. --- ## Comprimir archivos en MSI Source: https://docs.applivery.com/es/device-management/windows/app-management/wrapping-msi-files/ Description: Comprime archivos en un único paquete MSI para el despliegue a través de Applivery MDM — despliega apps personalizadas, scripts e instaladores en dispositivos Windows. TL;DR: Aprende a empaquetar archivos en un MSI para un despliegue sencillo vía MDM, permitiendo distribuir aplicaciones y configuraciones personalizadas. Answers: ¿Por qué comprimir archivos en un único MSI para Applivery MDM? · ¿En qué contexto de usuario se ejecutan los archivos MSI cuando se despliegan a través de Applivery? · ¿Puedo ejecutar directamente scripts PowerShell dentro de un archivo MSI? · ¿Cuál es la herramienta recomendada para crear paquetes MSI? · ¿Dónde se crea el archivo MSI de salida al usar MSI Wrapper? · ¿Qué tipo de archivo debe seleccionarse como ejecutable en MSI Wrapper? · ¿Cuál es el propósito del Código de Actualización en MSI Wrapper? · ¿Qué archivos deben incluirse en la carpeta antes de comprimirlos en un MSI? Comprimir archivos en un único archivo MSI es útil cuando se despliegan aplicaciones o scripts personalizados a través de Applivery MDM. Una vez empaquetado, el MSI puede cargarse a Applivery y desplegarse como cualquier aplicación estándar, activando tus scripts o instaladores personalizados en los dispositivos objetivo. ### Casos de uso comunes Comprimir en un único MSI es útil para: - Instalar aplicaciones `.exe`. - Instalar paquetes `.msix` o `.msixbundle`. - Desplegar scripts personalizados. :::info Los archivos MSI desplegados a través de Applivery se ejecutan con **privilegios de administrador** bajo la **cuenta SYSTEM** en Windows. Ten esto en cuenta al desplegar scripts o aplicaciones destinados a la ejecución a nivel de usuario, ya que también se ejecutarán en el contexto de SYSTEM. ::: ### Cómo funciona El enfoque más directo es incluir todos los archivos necesarios en una carpeta, junto con un archivo **batch** (`.bat`). Este script batch sirve como punto de entrada, permitiéndole llamar scripts PowerShell o lanzar instaladores. **Ejemplo: Desplegar** `xbox.msixbundle` **Crear un archivo batch (installXbox.bat) para activar un script PowerShell** ```batch @echo off powershell.exe -ExecutionPolicy Bypass -File "%~dp0installXboxApp.ps1" ``` **Crear el script PowerShell (installXboxApp.ps1) para instalar la App** ```powershell Dism /Online /Add-ProvisionedAppxPackage /PackagePath:".\xbox.msixbundle" /SkipLicense exit 0 ``` **Coloca los siguientes archivos en una única carpeta** - `installXbox.bat` - `installXboxApp.ps1` - `xbox.msixbundle` ### Crear un MSI con MSI Wrapper de EXEMSI Hay múltiples herramientas disponibles para crear paquetes MSI. Los pasos siguientes usan **MSI Wrapper de EXEMSI** — una utilidad sencilla que ofrece versiones gratuitas y de pago. :::info La versión gratuita agrega una marca de agua al nombre del archivo MSI pero no limita la funcionalidad. ::: #### Prepara tus archivos Antes de comprimir, crea una carpeta con **solo** los archivos necesarios (por ejemplo, archivo batch, scripts, paquetes de apps). :::warning Los archivos MSI no pueden ejecutar scripts PowerShell directamente. Debes usar un archivo `.bat` para activar cualquier lógica PowerShell. ::: En este ejemplo, el archivo batch se establece como el **ejecutable principal**. Cuando se ejecuta el MSI, el script batch inicia el script PowerShell, que realiza la instalación real. **Abre MSI Wrapper y haz clic en Siguiente para comenzar el proceso de configuración** ![step-1](https://www.applivery.com/wp-content/uploads/2025/08/step-1.png "step-1 | Applivery") **Selecciona el archivo batch como ejecutable (este es tu archivo de activación)** - Asegúrate de **marcar la casilla** para incluir todos los archivos en la carpeta de instalación. - Elige la **arquitectura de plataforma** adecuada (normalmente x64). ![step-2](https://www.applivery.com/wp-content/uploads/2025/08/step-2.png "step-2 | Applivery") **Establece el contexto de instalación según tus necesidades de despliegue** - En la mayoría de los casos, querrás instalar para **todos los usuarios** o a **nivel de sistema**. ![step-3](https://www.applivery.com/wp-content/uploads/2025/08/step-3.png "step-3 | Applivery") **Define la identidad de la aplicación** - Introduce un **ID de Aplicación** (cualquier cadena de tu elección). - Haz clic para **generar un nuevo Código de Actualización**. ![](https://www.applivery.com/wp-content/uploads/2025/08/step-4.png "step-4 | Applivery") **Rellena los detalles del producto manualmente** - Proporciona el **Nombre del producto**, **Fabricante** y **Versión**. - Haz clic en **Siguiente** en los pasos restantes. ![](https://www.applivery.com/wp-content/uploads/2025/08/step-5.png "step-5 | Applivery") **Haz clic en Compilar para generar el archivo MSI** - El MSI de salida se creará en el **mismo directorio** que tus archivos de origen. ![step-6](https://www.applivery.com/wp-content/uploads/2025/08/step-6.png "step-6 | Applivery") --- ## Comandos Source: https://docs.applivery.com/es/device-management/windows/commands/ Description: Comandos remotos para dispositivos Windows gestionados en Applivery: reiniciar, sincronizar, borrar y desinscribir sin acceso físico. TL;DR: Comandos remotos para dispositivos Windows: sincronizar, actualizar estado, reiniciar, forzar sincronización, borrar, desinscribir y mover de segmento. Los comandos MDM de Windows te permiten realizar acciones remotas en tiempo real en dispositivos Windows gestionados — enviar de nuevo la política asignada, reiniciar un dispositivo, borrarlo o retirarlo de la gestión sin necesidad de acceso físico. Cada comando remoto disponible para Windows incluye cuándo usarlo y qué sucede en el dispositivo cuando se ejecuta. --- ## Comandos remotos Source: https://docs.applivery.com/es/device-management/windows/commands/remote-commands/ Description: Reinicia, sincroniza, borra o desinscribe un dispositivo Windows de forma remota desde el panel de Applivery, sin necesidad de acceso físico. TL;DR: Usa el botón Action de un dispositivo Windows para sincronizarlo, reiniciarlo, borrarlo, desinscribirlo o moverlo de segmento. Consulta la pestaña Commands para ver si cada uno ha llegado al dispositivo. Key topics: Acciones remotas, Borrado de dispositivos Windows, Desinscripción, Estado de los comandos, Applivery, Windows Una vez inscrito un dispositivo Windows, Applivery puede gestionarlo de forma remota sin acceso físico: reenviar la política asignada, reiniciarlo, borrarlo o retirarlo de la gestión. Todas estas acciones están a un clic desde la ficha del dispositivo, y cada una queda registrada para que puedas confirmar que ha llegado realmente. ### Sincronizar política Reenvía la política asignada al dispositivo, sin esperar a la siguiente sincronización programada. Es lo primero que conviene probar tras cambiar una política, cuando prefieres no esperar a que el dispositivo la recoja por su cuenta. **Navegar al dispositivo** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a cualquiera de tus **dispositivos** y haz clic en el botón **Acción** 1. **Seleccionar Sincronizar política** En el menú desplegable, selecciona **Sincronizar política** 2. ![sync policy](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/e10d5bfd-a9dc-41e4-a583-6a7770ffaef0.png) ### Actualizar estado Solicita un informe actualizado del dispositivo: batería, almacenamiento, apps instaladas y el resto de la información que aparece en la pestaña **Resumen**. Útil cuando los datos del dispositivo parecen desactualizados, o antes de tomar una decisión basándote en lo que muestra el panel. **Navegar al dispositivo** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a cualquiera de tus **dispositivos** y haz clic en el botón **Acción** 1. **Seleccionar Actualizar estado** En el menú desplegable, selecciona **Actualizar estado** 2. ![](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/63e7d4a9-e413-4c26-88e6-b95de3d9347d.png) ### Reiniciar Reinicia el dispositivo de forma remota. Enviar un reinicio es útil en varias situaciones: libera memoria cuando el rendimiento se degrada, aplica actualizaciones del sistema que solo surten efecto tras reiniciar y resuelve fallos menores como apps que no responden. También merece la pena en dispositivos que llevan semanas sin reiniciarse, y después de aplicar ajustes que lo requieren para activarse. **Navegar al dispositivo** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a cualquiera de tus **dispositivos** y haz clic en el botón **Acción** 1. **Seleccionar Reiniciar** En el menú desplegable, selecciona **Reiniciar** 2. ![](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ecc8309d-fceb-4748-bd97-cd632b408a13.png) ### Borrar Restablece el dispositivo. Al seleccionar **Borrar** se abre un diálogo donde eliges entre dos tipos: - **Borrar dispositivo**: restablece el dispositivo a su estado de fábrica. Se eliminan todos los datos. - **Borrado protegido**: restablece el dispositivo y limpia por completo la unidad interna. A diferencia del borrado estándar, el dispositivo **sigue intentando completar el restablecimiento aunque el proceso se interrumpa**, por ejemplo, por un corte de energía. Usa el borrado estándar para un restablecimiento normal, como un dispositivo que se reasigna internamente. Usa **Borrado protegido** cuando necesites garantizar que los datos han desaparecido de verdad: un dispositivo perdido o robado, o uno que sale de la organización. **Navegar al dispositivo** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a cualquiera de tus **dispositivos** y haz clic en el botón **Acción** 1. **Seleccionar Borrar y elegir el tipo** En el menú desplegable, selecciona **Borrar** 2 y después elige **Borrar dispositivo** o **Borrado protegido** en el diálogo. ![wipe](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/762241f2-494b-4a76-9889-dd309cd5785e.png) :::warning **Borrar un dispositivo es irreversible.** Asegúrate de que apuntas al dispositivo correcto antes de confirmar, sobre todo con **Borrado protegido**: como sobrevive a las interrupciones, no hay margen para detenerlo una vez en marcha. ::: El borrado está también disponible en **Ajustes → Zona de peligro** de la ficha del dispositivo, donde se explican los dos tipos uno junto al otro. ### Dar de baja Retira el dispositivo de la gestión de Applivery. El dispositivo deja de recibir políticas, apps y comandos, pero **conserva sus datos y su software instalado**. Esa es la diferencia con el borrado: desinscribir es lo que quieres cuando el dispositivo se queda con el usuario y simplemente ya no debe estar gestionado. **Navegar al dispositivo** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a cualquiera de tus **dispositivos** y haz clic en el botón **Acción** 1. **Seleccionar Dar de baja** En el menú desplegable, selecciona **Dar de baja** 2. ![disenroll](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/b11504f9-a7af-48ad-8716-58732435e826.png) Desinscribir está también disponible en **Ajustes → Zona de peligro**. ### Mover Segmento Mueve el dispositivo a un segmento distinto. **Navegar al dispositivo** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a cualquiera de tus **dispositivos** y haz clic en el botón **Acción** 1. **Seleccionar Mover Segmento** En el menú desplegable, selecciona **Mover Segmento** 2 y elige el destino. ![move segment](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/e8930856-1dd6-41c1-ac93-df7702a26149.png) :::info Todos los comandos mencionados anteriormente también pueden ejecutarse desde la pestaña **Comandos** o desde la sección **Zona de peligro**, dentro de la pestaña de **Ajustes**. ::: --- ## Detalles del dispositivo Source: https://docs.applivery.com/es/device-management/windows/device-details/ Description: Consulta los datos MDM en crudo que Windows reporta de un dispositivo — inscripción, certificados, hardware y configuraciones aplicadas — y gestiona sus Smart Attributes. TL;DR: Abre un dispositivo Windows y ve a Details para ver los datos MDM en crudo que reporta, repartidos en ocho categorías. Todo es de solo lectura salvo Smart attributes. Answers: ¿Para qué sirve la pestaña Details? · ¿Qué es un CSP? · ¿Qué diferencia hay entre las categorías Device y User? · ¿Puedo exportar lo que estoy viendo? · ¿Dónde compruebo si un dispositivo es conforme? · ¿Cómo confirmo qué se envió exactamente a un dispositivo? · ¿Puedo editar algo en la pestaña Details? · ¿Por qué faltaría un área de política en un dispositivo? Key topics: Datos MDM en crudo, Configuration Service Providers, Smart Attributes, Diagnóstico de dispositivos, Applivery, Windows, Microsoft La pestaña **Resumen** de un dispositivo te da un resumen elaborado: lo que se consulta más a menudo, presentado para leerse. La pestaña **Detalles** es justo lo contrario: una ventana directa a los datos en crudo que el propio Windows reporta por MDM, sin ninguna interpretación por encima. Es la pestaña que abres cuando el resumen no basta: cuando necesitas confirmar qué se entregó realmente a un dispositivo, o por qué algo no se está aplicando. ![device details](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/c9a5a569-0e53-41ec-afd3-81e5d894b92a.png) :::info La mayor parte de lo que verás aquí se corresponde directamente con un **Configuration Service Provider (CSP)** de Windows: los bloques estándar que usa Windows para reportar y configurar ajustes por MDM. Cuando una categoría se corresponde con uno, incluye un enlace a la referencia oficial de Microsoft. ::: ### Cómo moverse Abre un dispositivo Windows y ve a su pestaña **Detalles**. Una lista de categorías a la izquierda filtra lo que se muestra a la derecha, y un buscador en la parte superior filtra dentro de la categoría seleccionada. El botón **Exportar CSV**, arriba a la derecha, descarga los datos de la categoría que estés viendo. :::warning **Todo es de solo lectura salvo los Atributos inteligentes.** El resto es telemetría reportada por el dispositivo: estás leyendo lo que Windows envió, no configurando nada. ::: ### Atributos inteligentes La única categoría que no es telemetría. Aquí es donde consultas y gestionas los [Atributos inteligentes](https://docs.applivery.com/es/device-management/general-settings/smart-attributes/) del dispositivo, acotados por segmento, con un interruptor **Incluir de padres** y **\+ Añadir atributo inteligente** para crear nuevos. ### Info del dispositivo Datos básicos de identidad del dispositivo y de su sesión MDM: `Dev Id` (su identificador MDM único), `DmV` (la versión del protocolo DM que habla), `Lang` y la información de fabricante y modelo. Es el [DevInfo CSP](https://learn.microsoft.com/en-us/windows/client-management/mdm/devinfo-csp), lo primero que reporta un dispositivo cuando habla con un servidor MDM. ### Dispositivo Ajustes y estado de **ámbito de máquina**. En términos de MDM de Windows, es el lado `./Device/Vendor/MSFT/...` del árbol de CSP. Entre otras cosas incluye: - **Salud de la inscripción y su renovación**: `Error Code`, `Last Renewal Attempt Time`, `Renew Period`, `Retry Interval`, la `Server URL` y el `Status` de la inscripción, y el hash del certificado `ROOT` que confirma la cadena de confianza con Applivery. Procede del [DMClient CSP](https://learn.microsoft.com/en-us/windows/client-management/mdm/dmclient-csp), que todo dispositivo inscrito usa para gestionar su conexión con el servidor. - **Cifrado de disco**: estado de BitLocker, Device Encryption Status y Removable Drives Encryption Status, del [BitLocker CSP](https://learn.microsoft.com/en-us/windows/client-management/mdm/bitlocker-csp). - **Almacenes de certificados**: Root CA Trusted Certificates, Trusted People, Trusted Publisher y Untrusted Certificates, del [CertificateStore CSP](https://learn.microsoft.com/en-us/windows/client-management/mdm/certificatestore-csp). - **Gestión de aplicaciones**: Enterprise Desktop App Management para instalaciones clásicas Win32 y MSI, y Enterprise Modern App Management para apps de la Store y MSIX y sus licencias, del [EnterpriseModernAppManagement CSP](https://learn.microsoft.com/en-us/windows/client-management/mdm/enterprisemodernappmanagement-csp). - **Ajustes de idioma** y el resultado de cualquier [configuración ADMX personalizada](https://docs.applivery.com/es/device-management/windows/policies/admx-configs/) aplicada. :::info Esta categoría lista además **todas las áreas de política que admite el dispositivo**. Merece la pena comprobarlo antes de dedicar tiempo a investigar por qué un ajuste no se aplica: si el área no está en la lista, el dispositivo sencillamente no la admite, y no habrá ajuste de política que lo cambie. ::: ### Usuario El mismo tipo de datos que **Device**, pero referidos al **usuario con la sesión iniciada**: el lado `./User/Vendor/MSFT/...` del árbol. Muchos CSP de Windows existen en una instancia de dispositivo y otra de usuario, porque algunos ajustes solo tienen sentido por persona y no a nivel de máquina. - **Personal Data Encryption**: si está activado y qué carpetas conocidas (Escritorio, Documentos, etc.) están protegidas, del [Personal Data Encryption CSP](https://learn.microsoft.com/en-us/windows/client-management/mdm/personaldataencryption-csp). - **Apps instaladas por usuario**: los nombres de familia de paquete AppX instalados para ese usuario, como Teams, Edge u Outlook. - **Inscripción y certificados de ámbito de usuario**: ActiveSync, Accounts y la instancia de usuario de Client Certificate Install para PFX y SCEP, del [ClientCertificateInstall CSP](https://learn.microsoft.com/en-us/windows/client-management/mdm/clientcertificateinstall-csp), además de la información del proveedor DM Client de ámbito de usuario. ### Fabricante Telemetría más amplia de salud, seguridad y licencias que no se reparte entre Device y User: varios CSP reportados bajo una misma categoría. - **Seguridad y salud**: estado de las firmas de antivirus del [Defender CSP](https://learn.microsoft.com/en-us/windows/client-management/mdm/defender-csp), estimaciones de batería, identidades de red móvil, conformidad del cifrado y Device Guard. - **Seguridad de red**: reglas del cortafuegos, perfiles y direcciones de palabras clave dinámicas, del [Firewall CSP](https://learn.microsoft.com/en-us/windows/client-management/mdm/firewall-csp). - **Licencias de Windows**: estado del Device Licensing Service, License Type, Edition, License Key Type y Subscriptions. - **Otros ajustes de ámbito de dispositivo**: ajustes de red como credenciales y cifrado de contraseñas, Secure Assessment y el estado de Autopilot o del aprovisionamiento del dispositivo. ### Detalle del dispositivo Datos de hardware y de sistema operativo: versión de software (`Sw V`), OEM, `DNS Computer Name` y `Device Name`, `Free Storage`, `Local Time` y otros atributos de bajo nivel. Proceden en su mayoría del [DevDetail CSP](https://learn.microsoft.com/en-us/windows/client-management/mdm/devdetail-csp). ### Configuración personalizada Las cargas de configuración que se enviaron realmente al dispositivo, incluido — en el caso de una [configuración ADMX personalizada](https://docs.applivery.com/es/device-management/windows/policies/admx-configs/) — el XML de ADMX en crudo que se le entregó, bajo `Config Operations`, `ADMX Install` y `Policy`. Es la forma más directa de confirmar qué se envió exactamente a un dispositivo, tal cual. Cuando un ajuste no se comporta como esperabas, comparar lo que configuraste con lo que llegó aquí suele zanjar la cuestión. ### Resumen Un resumen orientado a la conformidad: `Serial Number`, `Compliance` e `Is Compliance`, `Last Sync Error` y `Last Sync Error Message`, y los recuentos de `Applications`, `Books` y `Profiles`. Es lo más rápido para comprobar si un dispositivo está en un estado saludable — y `Last Sync Error Message` suele ser el campo más útil de toda la pestaña cuando algo ha dejado de funcionar. --- ## Inscripción de dispositivos Source: https://docs.applivery.com/es/device-management/windows/enrollment/ Description: Inscripción de Windows en Applivery — inscribe, configura y controla dispositivos Windows a escala con Inscripciones inteligentes y políticas. Answers: ¿Cómo se inscribe un dispositivo Windows en Applivery? · ¿Qué métodos de inscripción admite Applivery para Windows? · ¿Cuáles son las ventajas de usar Applivery para gestionar dispositivos Windows? Inscribir un dispositivo Windows en Applivery lo registra en la plataforma MDM y aplica automáticamente las políticas, apps y la configuración de tu organización. Applivery admite múltiples métodos de inscripción Windows para cubrir tanto dispositivos corporativos como escenarios de unión a Azure AD. Elige el método de inscripción para Windows más adecuado para tu despliegue: inscripción manual, unión a Azure AD o Autopilot. --- ## Autodescubrimiento: Configuración CNAME Source: https://docs.applivery.com/es/device-management/windows/enrollment/auto-discovery-domain/ Description: Configura un registro DNS CNAME para que los dispositivos Windows descubran automáticamente el servidor MDM de Applivery durante la inscripción — sin URLs manuales ni tokens. TL;DR: Configura un registro CNAME DNS (`enterpriseenrollment` apuntando a `domains.applivery.io`) y establece tu dominio en Applivery para habilitar el descubrimiento automático de inscripción MDM en Windows. Answers: ¿Qué es la función de Dominio de Autodescubrimiento Windows en Applivery? · ¿Cómo simplifica el Autodescubrimiento Windows la inscripción de dispositivos? · ¿Dónde configuro el Dominio de Autodescubrimiento Windows en el panel de Applivery? · ¿Qué dominio debo introducir en Applivery para el Autodescubrimiento Windows? · ¿Qué tipo de registro DNS se necesita para el Autodescubrimiento Windows de Applivery? · ¿Cuáles son los valores específicos del registro CNAME para el Autodescubrimiento de Applivery? · ¿Cuánto tiempo tardan en aplicarse los cambios del Autodescubrimiento Windows? El **Dominio de Autodescubrimiento Windows** permite que los dispositivos Windows corporativos localicen automáticamente el servidor MDM de Applivery durante el proceso de inscripción — sin necesidad de URLs de servidor manuales ni tokens de inscripción. Los usuarios simplemente introducen su dirección de correo corporativo, y Windows consulta los registros DNS públicos de tu empresa para descubrir el camino a Applivery. **Definir el dominio en Applivery** En el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a la sección **Configuración** 1 y selecciona **Configuración Windows** 2 en el menú de la izquierda. Localiza la sección **Dominio de Autodescubrimiento Windows** 3 y encuentra el campo de texto junto a `enterpriseenrollment.`. Introduce el dominio corporativo raíz de tu organización — por ejemplo, si tu dominio es `applivery.com`, la cadena resultante será `enterpriseenrollment.applivery.com`. ![cname](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/05a04a0a-869d-4492-ae77-2f81f54935c9.png) **Crear el registro CNAME en tu proveedor DNS** Un administrador de red debe crear un registro **CNAME** en el panel de gestión de tu proveedor de DNS público. Usa exactamente estos valores:

Parámetro

Valor requerido

Tipo

CNAME

Nombre / Host

enterpriseenrollment (o enterpriseenrollment.tudominio.com según la interfaz de tu proveedor)

Valor / Destino

domains.applivery.io

TTL

3600 (o el valor predeterminado de tu proveedor)

**Guardar y esperar la propagación** Una vez guardado el registro en tu proveedor DNS, vuelve al [**panel de Applivery**](https://dashboard.applivery.io/) y haz clic en **Guardar**. :::info Los cambios de DNS suelen ser casi instantáneos, pero la validación completa por parte de los dispositivos Windows puede tardar **hasta 24 horas** en aplicarse globalmente. ::: --- ## Métodos de inscripción Source: https://docs.applivery.com/es/device-management/windows/enrollment/enrollment-methods/ Description: Métodos de inscripción de Windows en Applivery: inscripción manual, Microsoft Entra ID, Autopilot, unión a dominio y aprovisionamiento directo para dispositivos Windows. TL;DR: Inscribe dispositivos Windows mediante inscripción manual, inscripción automática con Microsoft Entra ID, aprovisionamiento zero-touch con Windows Autopilot, paquetes de aprovisionamiento directo o unión a dominio en entornos con Active Directory local. Answers: ¿Qué método de inscripción de Windows debo elegir? · ¿Todos los métodos de inscripción requieren interacción del usuario? · ¿Para qué sirve el dominio de autodescubrimiento? · ¿Puedo inscribir dispositivos que ya están unidos a Entra ID? · ¿Puedo inscribir dispositivos Windows sin proveedor de identidad? · ¿Hay que activar algo antes de inscribir dispositivos Windows? · ¿Puedo asignar políticas distintas según el usuario? · ¿Qué es Windows Autopilot y qué necesita? Key topics: Métodos de inscripción de Windows, Windows Autopilot, Orígenes de identidad, Niveles de automatización, Paquetes de aprovisionamiento, Applivery, Microsoft Entra ID, Active Directory, Windows Una vez activado tu [Windows Enterprise](https://docs.applivery.com/es/device-management/windows/get-started/), puedes empezar a inscribir tus dispositivos Windows en Applivery. Veamos los métodos de inscripción disponibles. :::info Si necesitas dar de alta a varias personas a la vez, puedes invitarlas todas de una vez con una [inscripción masiva](https://docs.applivery.com/es/device-management/general-settings/bulk-enrollment/). ::: ### Opciones de inscripción Windows ofrece varias formas de inscribir dispositivos según tu infraestructura de identidad (solo nube, híbrida o local), el nivel de automatización que necesites y si los dispositivos se inscriben de uno en uno o de forma masiva. Todos los métodos terminan con el dispositivo gestionado por Applivery, pero se diferencian en dos aspectos clave: - **Nivel de automatización**: unos métodos requieren que el usuario final añada manualmente una cuenta de trabajo desde la app Configuración, mientras que otros inscriben el dispositivo automáticamente en el momento en que se une a tu proveedor de identidad, sin ninguna interacción. - **Origen de la identidad**: los dispositivos Windows pueden estar vinculados a **Microsoft Entra ID** (identidad en la nube), a un **dominio de Active Directory local**, o inscribirse como **dispositivos independientes** sin ninguna unión de identidad, mediante un paquete de aprovisionamiento. Sea cual sea el método, todo dispositivo Windows debe llegar al paso de [activación de Windows Enterprise](https://docs.applivery.com/es/device-management/windows/get-started/) antes de poder inscribirse, y cualquier inscripción se puede combinar con una [Smart Enrollment](https://docs.applivery.com/es/device-management/windows/enrollment/smart-enrollment/) para asignar políticas de forma condicional según datos del usuario o del dispositivo. #### Inscripción manual El **método de inscripción manual clásico**, que se realiza desde el propio dispositivo en **Configuración > Cuentas > Acceder al trabajo o al centro educativo**. El usuario introduce su correo corporativo y Windows descubre automáticamente el servidor MDM de Applivery mediante el dominio de autodescubrimiento de tu organización — un registro DNS de tipo CNAME que evita tener que escribir URLs de servidor o tokens de inscripción. Funciona con independencia de Entra ID y encaja bien en inscripciones puntuales o en dispositivos que no se gestionan mediante un servicio de directorio. Puedes obtener más información [aquí](https://docs.applivery.com/es/device-management/windows/enrollment/manual-enrollment/). #### Inscripción con Microsoft Entra ID Vincula la inscripción directamente a tu sistema de identidad corporativo. Una vez configurada la integración, cualquier dispositivo que se una a Microsoft Entra ID **se inscribe automáticamente en Applivery**, sin ningún paso de inscripción aparte. Es el método recomendado para parques corporativos gestionados en la nube, ya que además habilita el inicio de sesión único y la asignación automática de políticas según la identidad de usuario y de grupo. Puedes obtener más información [aquí](https://docs.applivery.com/es/device-management/windows/enrollment/entra-id-enrollment/). :::info Los dispositivos que **ya estaban unidos a Entra ID antes** de configurar la integración necesitan un paso adicional de recuperación, ya que conservan un token de seguridad emitido antes de que Applivery existiera. Consulta [Inscribir dispositivos ya unidos a Entra ID](https://docs.applivery.com/es/device-management/windows/enrollment/entra-id-joined-devices-enrollment/) para incorporarlos sin desvincularlos ni restablecerlos. ::: #### Windows Autopilot La tecnología de **aprovisionamiento zero-touch** de Microsoft. Un dispositivo nuevo se configura solo la primera vez que se enciende, sin imágenes ni preparación manual: durante la experiencia de primer uso se redirige a Applivery, de modo que el Agente, tus políticas y tus apps se instalan automáticamente en cuanto el usuario inicia sesión. Requiere una **integración activa con Entra ID**, ya que la redirección se configura mediante el traspaso de MDM en Entra. Es el método para enviar dispositivos directamente del proveedor al empleado. Puedes obtener más información [aquí](https://docs.applivery.com/es/device-management/windows/enrollment/windows-autopilot/). #### Unión a dominio Para entornos con un **Active Directory local**. El dispositivo se inscribe automáticamente al unirse al dominio, sin interacción del usuario, lo que lo convierte en el equivalente local de la inscripción con Entra ID. Es la opción natural para dispositivos corporativos en entornos locales o híbridos, donde la identidad ya vive en tu propio directorio en lugar de en la nube. #### Aprovisionamiento directo Permite generar un **paquete de aprovisionamiento** asociado a una plantilla de inscripción, que empaqueta las credenciales de inscripción (incluido un secreto generado automáticamente) para que los dispositivos puedan inscribirse **sin interacción del usuario ni unión a ningún directorio**, normalmente durante el primer arranque o mediante USB. Es el método más adecuado para despliegues masivos, offline o de tipo quiosco, y el único que funciona cuando el dispositivo no está vinculado a ningún proveedor de identidad. Puedes obtener más información [aquí](https://docs.applivery.com/es/device-management/windows/enrollment/provisioning-package-enrollment/). ### Métodos de inscripción | Método de inscripción | Origen de identidad | Nivel de automatización | Interacción del usuario | Caso de uso habitual | | --- | --- | --- | --- | --- | | **Inscripción manual** | Ninguno (descubrimiento por correo) | Manual | Necesaria (introducir el correo de trabajo) | Inscripciones puntuales, sin servicio de directorio | | **Inscripción con Microsoft Entra ID** | Microsoft Entra ID (nube) | Automática al unirse | Ninguna (tras la unión a Entra ID) | Parques corporativos gestionados en la nube | | **Windows Autopilot** | Microsoft Entra ID (nube) | Zero-touch, automática en el primer arranque | Ninguna (el usuario solo inicia sesión) | Dispositivos nuevos enviados directamente al empleado | | **Unión a dominio** | Active Directory local | Automática al unirse | Ninguna (tras la unión al dominio) | Parques corporativos locales o híbridos | | **Aprovisionamiento directo** | Ninguno (independiente) | Automática (por paquete) | Ninguna | Despliegues masivos, offline o de tipo quiosco | --- ## Inscripción con Entra ID Source: https://docs.applivery.com/es/device-management/windows/enrollment/entra-id-enrollment/ Description: Inscribe dispositivos Windows en Applivery MDM a través de Microsoft Entra ID — simplifica el aprovisionamiento y centraliza la Gestión de Dispositivos. TL;DR: Integra Microsoft Entra ID con Applivery para agilizar la inscripción de dispositivos, mejorar la seguridad y centralizar la gestión de dispositivos Windows. Answers: ¿Cuál es el beneficio de integrar Microsoft Entra ID con Applivery? · ¿Cómo mejora la integración de Entra ID la seguridad en Applivery? · ¿Dónde encuentro la configuración de Entra ID en Applivery? · ¿Qué URLs debo configurar en el portal de Azure? · ¿Qué credenciales se necesitan para completar la integración de Entra ID en Applivery? · ¿Dónde encuentro instrucciones para generar el Client ID, Tenant ID y Client Secret? · ¿Cuál es la ventaja principal de usar Entra ID para la inscripción de dispositivos? · ¿Cómo automatiza Entra ID el aprovisionamiento de dispositivos en Applivery? La integración de **Microsoft Entra ID** (anteriormente Azure Active Directory) con Applivery permite a las organizaciones vincular la inscripción de dispositivos directamente a su sistema de identidad corporativa. Al aprovechar Entra ID, los usuarios pueden inscribir Dispositivos con sus credenciales existentes mientras los equipos de TI mantienen el control centralizado sobre el acceso, la seguridad y la asignación de políticas. Esta integración conecta la identidad y la gestión de dispositivos, reduciendo el trabajo manual, mejorando la postura de seguridad y garantizando que los dispositivos estén siempre asociados con los usuarios y grupos correctos. ### ¿Por qué usar Entra ID para la inscripción? Usar Microsoft Entra ID como parte de tu estrategia de inscripción proporciona varios beneficios clave: - **Inicio de Sesión Único (SSO)**: Los usuarios inscriben dispositivos con sus credenciales corporativas estándar, eliminando la necesidad de nombres de usuario o contraseñas adicionales. - **Aprovisionamiento automatizado**: Los usuarios y grupos se sincronizan automáticamente, garantizando que se apliquen las políticas y configuraciones adecuadas según la identidad. - **Seguridad mejorada**: El soporte para la Autenticación Multifactor (MFA) y la revocación inmediata del acceso cuando un usuario deja la organización refuerza la seguridad general. **Acceder a la configuración de Entra ID** En el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a Automatización 1, selecciona **Inscripciones Inteligentes** 2, elige Windows 3 en el menú de la izquierda y localiza el perfil de inscripción que quieres configurar. Haz clic en el **menú de tres puntos (⋮)** 4 en el lado derecho del perfil y selecciona **Configuración de Microsoft Entra ID** 5. Se abrirá una ventana modal con los detalles de configuración necesarios, incluyendo tus URLs de configuración únicas de Azure y los campos necesarios para completar la integración. ![entra id](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/e1745a8b-34b1-4112-b538-178f240d0da3.png) **Completar la configuración de la integración** Con el modal de configuración de Applivery abierto, ya puedes vincular Applivery con tu tenant de Microsoft Entra ID. Copia la **URL de Términos de Uso MDM** y la **URL de Detección MDM** 6 proporcionadas en Applivery y úsalas para configurar la aplicación Mobility (MDM y MAM) en el portal de Microsoft Entra ID / Azure. Luego, introduce las credenciales necesarias — **Client ID**, **Tenant ID** y **Client Secret** 7 — en los campos correspondientes de Applivery. Una vez añadidos todos los valores, haz clic en Guardar configuración para finalizar la conexión entre Applivery y Entra ID. ![entra id configuration](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/d09a0ef6-21ef-4828-ac8b-c76cfdda0d53.png) :::info Las instrucciones detalladas paso a paso para generar el Client ID, Tenant ID y Client Secret en el portal de Microsoft Entra ID (Azure) están disponibles en la sección final del modal de configuración de Applivery (**Guía de configuración paso a paso** 8). ::: Al integrar Microsoft Entra ID con Applivery, las organizaciones pueden habilitar un flujo de inscripción seguro basado en identidad que simplifica el onboarding, aplica controles de acceso y garantiza que los dispositivos siempre se gestionen según las políticas de identidad y seguridad corporativas. :::info ¿Algunos de tus PCs **ya estaban unidos a Entra ID antes** de configurar Applivery? Esos dispositivos no se inscribirán por sí solos, porque usan un token de seguridad emitido antes de que existiera la integración. Consulta [Inscribir dispositivos ya unidos a Entra ID](https://docs.applivery.com/es/device-management/windows/enrollment/entra-id-joined-devices-enrollment/) para incorporarlos sin desvincularlos ni restablecerlos. ::: :::info ¿Quieres que los dispositivos completamente nuevos se inscriban en Applivery por sí solos, nada más sacarlos de la caja? Con tu integración de Entra ID ya en marcha, ahora puedes configurar [Windows Autopilot](https://docs.applivery.com/es/device-management/windows/enrollment/windows-autopilot/) para una experiencia de aprovisionamiento sin intervención. ::: --- ## Inscribir dispositivos ya unidos a Entra ID Source: https://docs.applivery.com/es/device-management/windows/enrollment/entra-id-joined-devices-enrollment/ Description: Inscribe PCs Windows que se unieron a Microsoft Entra ID antes de configurar Applivery — sin desvincular ni restablecer, usando dsregcmd /forcerecovery. TL;DR: Los dispositivos unidos a Entra ID antes de configurar Applivery no se inscriben solos. Ejecuta `dsregcmd /forcerecovery`, pide al usuario que inicie sesión, y Windows refresca su token e inscribe el dispositivo automáticamente. Cuando configuras la [integración con Microsoft Entra ID](https://docs.applivery.com/es/device-management/windows/enrollment/entra-id-enrollment/), todos los dispositivos que se unan a Entra ID a partir de ese momento se inscriben en Applivery automáticamente. Pero los dispositivos que **ya estaban unidos a Entra ID antes** de que configuraras Applivery se comportan de otra manera: nunca aparecen para inscribirse. El motivo es cuestión de tiempos. Estos PCs usan un token de seguridad que se emitió _antes_ de que existiera la integración con Applivery, así que, hasta donde el dispositivo sabe, Applivery no está ahí. El dispositivo no está averiado ni hay nada mal configurado — simplemente necesita refrescar su token para poder descubrir el nuevo MDM. Microsoft ofrece un comando para exactamente esta situación. Ejecutar `dsregcmd /forcerecovery` refresca el registro del dispositivo con Entra ID **sin desvincular el equipo ni borrar ningún dato**. Una vez refrescado el token, el dispositivo detecta Applivery y se inscribe por sí solo. :::info Este procedimiento da por hecho que la [integración con Entra ID](https://docs.applivery.com/es/device-management/windows/enrollment/entra-id-enrollment/) ya está configurada en tu tenant. Si no lo está, configúrala primero — de lo contrario, el token refrescado seguirá sin encontrar Applivery. ::: **Ejecutar el comando de recuperación** Puedes lanzar el refresco del token de dos maneras. Elige la que mejor se adapte a cómo llegas a los dispositivos afectados. **Opción A — De forma remota, con un script de Applivery** Si los dispositivos ya son accesibles en tu panel de Applivery, envía el comando como un script. Ve a **Recursos > Scripts**, crea un nuevo script de PowerShell con la línea de abajo y asígnalo a los dispositivos afectados. Consulta [Scripts](https://docs.applivery.com/es/device-management/windows/policies/scripts/) para ver el flujo completo. ```powershell dsregcmd /forcerecovery ``` **Opción B — Manualmente, en el dispositivo** En el PC, abre el Símbolo del sistema o PowerShell **como administrador** y ejecuta: ```powershell dsregcmd /forcerecovery ``` **Iniciar sesión cuando se solicite** Al ejecutarse el comando, el usuario ve un **mensaje nativo de inicio de sesión de Microsoft**. Pídele que inicie sesión con su cuenta corporativa de Entra ID. Este es el paso que refresca el token de seguridad del dispositivo — en cuanto el usuario inicia sesión, Windows actualiza el token en segundo plano. **Dejar que se complete la inscripción** Tras el inicio de sesión, Windows descubre Applivery como MDM e **inscribe el dispositivo automáticamente en segundo plano**. El usuario no tiene que hacer nada más. Una vez finalizada la inscripción, el dispositivo aparece en la sección **Dispositivos** del [panel de Applivery](https://dashboard.applivery.io/) con las políticas y apps de tu organización aplicadas. --- ## Inscripción manual Source: https://docs.applivery.com/es/device-management/windows/enrollment/manual-enrollment/ Description: Inscribe manualmente dispositivos Windows 10 y 11 en Applivery MDM — conéctate al servidor de gestión y aplica políticas automáticamente. TL;DR: Inscribe tus dispositivos Windows 10/11 en Applivery MDM creando un empleado, generando un token de inscripción y siguiendo los pasos de configuración manual. Answers: ¿Qué versiones de Windows son necesarias para la inscripción en Applivery? · ¿Qué permisos se necesitan en el dispositivo Windows para la inscripción? · ¿Cómo creo un empleado en Applivery? · ¿Puedo crear empleados directamente desde el formulario de inscripción? · ¿Qué información se necesita para inscribir un dispositivo Windows? · ¿Cuáles son las opciones de inscripción para dispositivos Windows? · ¿Cómo accedo a las instrucciones de inscripción Windows? · ¿Qué ocurre después de completar los pasos de inscripción Windows? Una vez que tengas [Windows Enterprise](https://docs.applivery.com/es/device-management/windows/get-started/) configurado, puedes comenzar a inscribir tus dispositivos Windows. Veamos cómo hacerlo. :::info Antes de comenzar a inscribir dispositivos Windows, es importante asegurarse de que se cumplen los siguientes requisitos para habilitar la gestión completa del dispositivo: - Un dispositivo con **Windows 10 o 11 Pro/Enterprise**. - **Permisos de administrador local** en el dispositivo. ::: **Crear una nueva inscripción** En el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a **Dispositivos** y haz clic en el botón **\+ Inscribir dispositivo**. Rellena el formulario de la siguiente manera: - **Plataforma:** Elige Windows. - **Empleado:** Usuario propietario del dispositivo. Puedes crear un nuevo empleado introduciendo la dirección de correo electrónico. - **Política:** Elige la política que se aplicará al dispositivo. Puedes hacerlo en Gestión de Dispositivos > Políticas si aún no la has creado. También puedes crear una nueva política aquí y configurarla más tarde. - **Nombre de visualización (opcional):** Un nombre descriptivo para identificar fácilmente el dispositivo entre los demás. - **Válido hasta:** El tiempo de vencimiento del token de inscripción que se generará. - **Enviar correo con instrucciones al empleado (opcional):** Elige si deseas enviar una notificación al usuario con las instrucciones de inscripción. ![windows enrollment](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/1b7d0132-11e8-4561-b66d-4c84abbcb79e.png) **Inscribir el dispositivo** Una vez creada la inscripción, aparecerá en la lista de dispositivos. Haz clic en ella para ver los detalles e instrucciones de inscripción. ![enrollment instructions](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/e361a858-765d-4442-abdb-4f4e522d2726.png) Puedes elegir entre usar el **Sitio de inscripción** o un **Enlace Directo** para el proceso de inscripción. - El **Sitio de inscripción** es un portal seguro de Applivery que guía a los usuarios paso a paso por el proceso de inscripción. - Alternativamente, el **Enlace Directo** proporciona una URL que lleva a los usuarios directamente al perfil de inscripción, sin necesidad de autenticación. **Completar la inscripción** Una vez que hayas completado los pasos descritos en cada opción, deberás confirmar que la información es correcta y hacer clic en **Siguiente**. Sigue las instrucciones en pantalla para completar el proceso de inscripción hasta que veas el mensaje **Configurando tu Dispositivo.** Luego, haz clic en **Entendido**. ![setting-up-your-device | Applivery](https://www.applivery.com/wp-content/uploads/2025/07/image-1.png "setting-up-your-device | Applivery") En ese momento, el dispositivo quedará inscrito en Applivery y podrás ver y gestionar sus detalles desde el panel de Applivery. ![windows device](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/d034f201-bb32-479a-89a8-d8ddd02ca3fe.png) --- ## Inscripción con paquete de aprovisionamiento Source: https://docs.applivery.com/es/device-management/windows/enrollment/provisioning-package-enrollment/ Description: Inscribe dispositivos Windows a escala usando un paquete de aprovisionamiento generado desde una Inscripción inteligente en Applivery — sin interacción del usuario. TL;DR: Desde una inscripción inteligente en Applivery, haz clic en los tres puntos verticales, selecciona Ver instrucciones, elige Paquete de aprovisionamiento y sigue los pasos en pantalla. Answers: ¿Qué es unpPaquete de aprovisionamiento (PPKG) para dispositivos Windows? · ¿Cuáles son los principales beneficios de usar un paquete de aprovisionamiento para la inscripción? · ¿Qué se necesita antes de generar un paquete de aprovisionamiento? · ¿Cómo genero un paquete de aprovisionamiento en Applivery? · ¿Puedo crear varios paquetes de aprovisionamiento desde la misma Inscripción inteligente? · ¿Cómo quedan vinculados los dispositivos al inscribirse con un paquete de aprovisionamiento? · ¿Cómo aplico un paquete de aprovisionamiento en mis dispositivos Windows? Un **paquete de aprovisionamiento (PPKG)** es un método de despliegue que te permite inscribir dispositivos Windows automáticamente usando un archivo generado directamente desde una [Inscripción inteligente de Windows](https://docs.applivery.com/es/device-management/windows/enrollment/smart-enrollment/). Es ideal para despliegues masivos o zero-touch, ya que no se necesita introducir URLs manualmente ni credenciales de usuario en el dispositivo. ### Cómo generar y desplegar un paquete de aprovisionamiento :::info Antes de empezar, asegúrate de tener una [Inscripción inteligente de Windows](https://docs.applivery.com/es/device-management/windows/enrollment/smart-enrollment/) ya configurada. ::: **Abrir las instrucciones de la Inscripción inteligente** En el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a la sección **Automatización** 1 y selecciona **Inscripciones inteligentes** 2. En el menú de la izquierda, elige **Windows** 3 como plataforma. Haz clic en los tres puntos verticales 4 junto a la inscripción inteligente que quieras usar y selecciona **Ver instrucciones** 5. ![provisioning package](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/04fddb99-cb0c-4220-b08b-b6b4b483b184.png) **Generar el paquete de aprovisionamiento** En el panel lateral, selecciona **Paquete de aprovisionamiento** 6 y haz clic en el botón **\+ Crear aprovisionamiento** 7. :::warning Los dispositivos inscritos mediante este paquete quedarán vinculados inicialmente a un único usuario o departamento. Puedes reasignarlos posteriormente usando un script. Puedes crear tantos paquetes de aprovisionamiento como necesites desde la misma inscripción. ::: **Aplicar el paquete en tus dispositivos** Una vez generado el paquete, haz clic en **Seleccionar** 8. ![create and select ppkg](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/f245477a-0821-4af4-8181-84b872368662.png) Las instrucciones en pantalla te guiarán por el proceso de aplicación del archivo PPKG en tus dispositivos Windows. * * * ### Inscripción durante el OOBE (Out-of-Box Experience) Cuando aplicas un paquete de aprovisionamiento durante el **OOBE** de Windows — el asistente de configuración inicial que se ejecuta en un equipo nuevo o recién restablecido — la inscripción necesita un paso extra para que perdure. Durante el OOBE, Windows se ejecuta bajo una sesión temporal (`defaultuser0`) que **no es persistente**. Si inscribes directamente desde esa fase, la inscripción en Applivery queda vinculada a esa sesión temporal y se elimina de forma silenciosa cuando la sesión se limpia — dejando el dispositivo sin inscribir. Para evitarlo, divides el proceso en dos fases: - **Fase OOBE**: se configura en el dispositivo la cuenta de usuario y todo lo que no está relacionado con la inscripción en Applivery. - **Tras el primer inicio de sesión en Windows**: se ejecuta la inscripción real en Applivery, vinculada a un usuario **persistente**, de modo que sobrevive a los reinicios. :::info Este procedimiento solo es necesario cuando el PPKG se aplica desde el **asistente OOBE**. Para dispositivos ya activados (que ya han pasado la configuración inicial), solo necesitas el único `Enroll.ppkg` descrito en la sección anterior. ::: **Crear la Inscripción inteligente y exportar Enroll.ppkg** En el [**panel de Applivery**](https://dashboard.applivery.io/), crea una **Inscripción inteligente de Windows**, selecciona **Inicio de sesión anónimo** (Anonymous login) y añade una política. ![](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/e3ed0e2a-a89e-4415-b5ee-93c1e9801e1a.png) Genera un paquete de aprovisionamiento siguiendo las instrucciones del panel (como en la sección anterior), incluyendo **solo la configuración de Workplace para inscribir**. Expórtalo como `Enroll.ppkg` en tu escritorio. Ten en cuenta que se crea también un archivo de catálogo `.cat` con el mismo nombre. ![configure windows configuration designer](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/316fa9e3-81c7-4633-a7de-13bb2cb3f51b.png) **Construir el paquete envoltorio en Windows Configuration Designer** Crea un **nuevo proyecto de paquete de aprovisionamiento** en **Windows Configuration Designer** y configura lo siguiente. **a) Crear la cuenta de usuario** Crea una cuenta de usuario y asegúrate de que forma parte del grupo local de **Administradores**. Si es un usuario estándar, la inscripción tras el RunOnce fallará por falta de permisos. ![admin user](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/af549dab-c8f3-45d3-ad10-7c1cdfda3fac.png) **b) Añadir Enroll.ppkg a los archivos entregados** Baja hasta el nodo **Folders** dentro de **Runtime settings** y expándelo. Los archivos añadidos aquí se entregan en `C:\Users\Public\Documents` en el dispositivo de destino. Añade el `Enroll.ppkg` y su archivo de catálogo `.cat`, y luego haz clic en **Add**. Aparecerán dentro del árbol **Runtime**. ![folders](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/7f5464e1-4106-4c31-9485-c5c4a7fb1b0b.png) **c) Configurar el OOBE** Baja hasta el nodo **OOBE** y configúralo como se muestra. ![node configuration](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/1fa609fa-753e-48e6-a746-c92a0c8d4601.png) **d) Añadir el comando de aprovisionamiento RunOnce** Este es el paso clave. Baja hasta **Provisioning Commands** y expándelo. Haz clic en **Device Context** y selecciona el campo **CommandLine** en el árbol de la izquierda. Añade el siguiente comando de una sola línea: ``` reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce" /v "AppliveryOOBEEnroll" /t REG_SZ /d "powershell.exe -ExecutionPolicy Bypass -Command \"Install-ProvisioningPackage -PackagePath C:\Users\Public\Documents\Enroll.ppkg -QuietInstall -ForceInstall\"" /f ``` **Exportar y desplegar** Exporta el PPKG y ya está listo. El comando inyecta una entrada **RunOnce** en el Registro de Windows que se ejecuta de forma silenciosa justo después del primer inicio de sesión del usuario tras el aprovisionamiento con el PPKG desde OOBE. Esto vincula la inscripción en Applivery al usuario persistente que acaba de iniciar sesión. Para confirmarlo, ve a **Configuración > Cuentas > Acceder a trabajo o escuela** — la cuenta de **Applivery** ya aparecerá en la lista. A partir de ese momento, la inscripción persiste entre reinicios. --- ## Inscripciones inteligentes Source: https://docs.applivery.com/es/device-management/windows/enrollment/smart-enrollment/ Description: Automatiza la inscripción de dispositivos Windows con Inscripciones Inteligentes en Applivery — define reglas, asigna Políticas y simplifica la Gestión de Dispositivos. TL;DR: Las inscripciones inteligentes automatizan la inscripción de dispositivos Windows usando reglas y condiciones para asignar políticas y configuraciones de forma automática. Answers: ¿Qué son las Inscripciones inteligentes? · ¿Para qué se pueden usar las Inscripciones inteligentes? · ¿Cómo creo una Inscripción inteligente? · ¿Qué son los Campos auxiliares en las Inscripciones inteligentes? · ¿Cómo agrego condiciones a una Inscripción inteligente? · ¿Cómo aplico diferentes políticas según las condiciones? · ¿Cómo despliego una Inscripción inteligente en un dispositivo Windows? · ¿Para qué sirve la opción 'Continuar automáticamente'? Si alguna vez has soñado con automatizar el 100% del proceso de inscripción de dispositivos y la asignación condicional de políticas basándose en datos del usuario (nombre, correo, Grupos de Usuarios) o en datos del dispositivo (IMEI, Número de Serie, etc.), las **Inscripciones inteligentes** son la herramienta que estabas buscando. #### Introducción Las Inscripciones inteligentes son la forma más eficiente de gestionar las inscripciones de dispositivos de forma desatendida, ya que te permiten **definir un conjunto de reglas y condiciones que deben cumplirse para que un dispositivo sea inscrito** y, además, te permiten **asignar Políticas de forma condicional** basándose en estos conjuntos de reglas. Las Inscripciones inteligentes son útiles para: - Limitar la inscripción de dispositivos: - Basándose en la autenticación del usuario a través de [integraciones SSO](https://docs.applivery.com/es/platform/authentication/sso/) (grupos de usuarios o patrones de correo). - Basándose en información del dispositivo (IMEI, número de serie). - Asignar condicionalmente diferentes políticas según reglas. - Automatizar inscripciones para habilitar experiencias zero-touch desatendidas. ### Configuración de la Inscripción inteligente Empecemos a configurar tu primera Inscripción inteligente. Primero, dirígete a **Automatización** 1, selecciona **Inscripciones inteligentes** 2 y elige **Windows** 3 como plataforma en el menú de la izquierda. Luego haz clic en el botón **\+ Crear Inscripción inteligente** 4. ![Smart Enrollment](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/514a8ed0-1052-4c32-a9b2-cfcb187137f8.png) **Configurar la Inscripción inteligente** 1. **Nombre:** Elige un nombre descriptivo para tu nueva Inscripción inteligente. 2. **Descripción:** Elige una descripción para tu nueva Inscripción inteligente. 3. **Modo de gestión**: Especifica el método de gestión del dispositivo que se aplicará durante este proceso de Inscripción inteligente. 4. **Proveedores de acceso**: Se mostrarán los proveedores SSO configurados a nivel de Workspace. También puedes configurar la integración específica a nivel de Inscripción inteligente haciendo clic en **Sobrescribir**. 5. **Política:** Elige la política que se aplicará al dispositivo desde la biblioteca de políticas. Si aún no tienes Políticas predefinidas, escribe un nombre y se creará una nueva política vacía. 6. **Segmento destino**: Elige el [Segmento](https://docs.applivery.com/es/device-management/general-settings/segments/) al que se asignarán los dispositivos inscritos. 7. **Etiquetas**: Usadas para filtrar y agrupar. :::info Cuando el proveedor de acceso está configurado como **Anónimo**, puedes habilitar la opción **Continuar automáticamente**, que permite que los dispositivos continúen la inscripción automáticamente cuando no se requiere interacción del usuario. ::: ![Smart Enrollment form](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/3a28a704-4299-4d70-8a7d-c8664d871748.png) **Configurar Campos auxiliares** 8. **Campos auxiliares**: Al rellenar este formulario, podrás configurar etiquetas de dispositivo durante la inscripción. ![auxiliary fields](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/1fceaef5-1bc0-4ade-b700-94ebbd416ca9.png) **Configurar el patrón de nombre de visualización** 9. **Patrón de nombre de visualización**: Asigna un nombre para mostrar combinando propiedades del dispositivo. ![interpolation tags](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ea33f0ed-ea8e-40bc-acce-9ea60a927278.png) Si haces clic en **Guardar** en este punto, habrás terminado de configurar tu Inscripción inteligente básica y podrás comenzar a inscribir dispositivos. **Campos auxiliares** Usando los Campos auxiliares, puedes definir una **estructura de inscripción flexible** que se adapte a las características organizativas de tu empresa. Esto permite a los usuarios inscribir sus dispositivos **según requisitos específicos**, mientras permite a los administradores aplicar diferentes configuraciones según estas selecciones. Estos Campos auxiliares se pueden usar para generar etiquetas de dispositivo durante la inscripción, que funcionan como parámetros condicionales. Puedes crear tantos campos como necesites y asociarlos posteriormente con las políticas correspondientes para cada escenario. Tras continuar, el usuario verá los menús desplegables definidos en los Campos auxiliares, según los requisitos de la organización. Una vez seleccionados los campos necesarios, el usuario se autenticará usando el método habilitado por la organización, y se aplicarán las políticas adecuadas según las etiquetas asignadas. El dispositivo completará entonces la inscripción y aplicará las configuraciones en segundo plano. **Aplicar condiciones y reglas** Ahora que tienes tu Inscripción inteligente básica configurada, puedes agregar **Condiciones** 5 y **Reglas** 6 que la harán más inteligente. ![conditions and rules](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/63afb755-bc2b-4adc-85f2-7e7ad39c6283.png) Usa la opción **Añadir condición** para habilitar límites de inscripción basados en información del usuario (como patrones de correo o grupos) e información del dispositivo (IMEI, número de serie y campos auxiliares). Puedes usar operadores condicionales para hacerlo tan complejo como necesites. ![conditions](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/2b5656eb-509a-4afd-a93c-6877b1851707.png) También puedes usar la opción **Añadir regla adicional** para crear grupos de condiciones, cada uno con una política objetivo. Como verás, cada grupo de condiciones también tendrá tantas **Condiciones** como necesites. ![rules](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/d11df520-b632-4b67-8ab4-218ed719cd3a.png) Una vez hecho, haz clic en **Guardar**. **Desplegar Inscripciones inteligentes** Para completar el proceso, deberás asignar las Inscripciones inteligentes a tus dispositivos Windows. Simplemente haz clic en los tres puntos verticales junto a cualquiera de tus Inscripciones inteligentes y selecciona **Ver instrucciones** 7. Esta acción te dará acceso al panel lateral de instrucciones, donde podrás seguir fácilmente los pasos proporcionados. ![view instructions](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/b2fb8152-8213-4f55-84d5-8379d1aab051.png) --- ## Windows Autopilot Source: https://docs.applivery.com/es/device-management/windows/enrollment/windows-autopilot/ Description: Inscribe dispositivos Windows en Applivery mediante Windows Autopilot — configura el traspaso de MDM, el perfil de despliegue y el registro de hardware para un aprovisionamiento sin intervención. TL;DR: Configura Windows Autopilot con Applivery estableciendo el traspaso de MDM en Entra, creando un perfil de despliegue, registrando los hardware hashes de los dispositivos y dejando que se aprovisionen automáticamente en el primer arranque. Answers: ¿Cómo configurar Windows Autopilot con Applivery? · ¿Qué es la URL de detección de MDM en Autopilot? · ¿Cómo obtener el hardware hash de un dispositivo Windows? · ¿Qué licencias se necesitan para un perfil de despliegue? · ¿Cómo redirigir los dispositivos de Autopilot a Applivery en lugar de Intune? · ¿Cuáles son los ajustes recomendados de la OOBE para Autopilot? · ¿Cómo aprovisiona Autopilot los dispositivos automáticamente? Key topics: Windows Autopilot, Traspaso de MDM, Perfil de despliegue, Registro de hardware, Aprovisionamiento sin intervención, Microsoft Entra ID, Microsoft Intune, Applivery, MDM **Windows Autopilot** es la tecnología de aprovisionamiento sin intervención de Microsoft: permite que un dispositivo Windows completamente nuevo se configure a sí mismo la primera vez que se enciende, sin necesidad de crear imágenes ni de una configuración manual. Cuando combinas Autopilot con Applivery, el dispositivo se redirige a Applivery durante la experiencia lista para usar (OOBE) — de modo que el Agente de Applivery, tus Políticas y tus Apps se instalan automáticamente en el momento en que el usuario inicia sesión. :::warning Antes de empezar esta configuración, asegúrate de haber completado la [configuración de Microsoft Entra ID](https://docs.applivery.com/es/device-management/windows/enrollment/entra-id-enrollment/). Autopilot requiere una **integración de Entra ID activa** para redirigir los dispositivos a Applivery durante la inscripción. ::: ### 1\. Configura el traspaso de MDM Este es el paso más crítico. Le indica a Microsoft Entra: _"No gestiones tú este dispositivo; envíalo a Applivery."_ **Inicia sesión en el portal de Azure** Inicia sesión en el [**portal de Azure**](https://portal.azure.com/) con una cuenta que tenga permiso para gestionar los ajustes de Movilidad. **Abre los ajustes de Movilidad (MDM y WIP)** Ve a **Manage** > **Mobility (MDM and WIP)**. **Selecciona tu aplicación de Applivery** Haz clic en tu aplicación de **Applivery**. Debería aparecer ya listada en el panel de aplicaciones de movilidad — si no está, añádela primero. ![mobility mdm and wip](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/1c9d87ab-6911-45bf-a919-13c31d882a8e.png) **Configura el ámbito de usuario de MDM y verifica la URL de detección** Establece el **MDM User Scope** en **All**, o dirígete a un grupo de seguridad específico eligiendo **Some**. A continuación, verifica que la **MDM Discovery URL** apunta al **endpoint de inscripción de Applivery**. Esta URL es la que redirige el dispositivo fuera de Intune y hacia Applivery — debería haberse configurado durante la [configuración de Entra ID](https://docs.applivery.com/es/device-management/windows/enrollment/entra-id-enrollment/). ![mdm user scope](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/789a3f1d-26d4-4642-a390-18a4db78ee70.png) ### 2\. Crea el perfil de despliegue El perfil de despliegue controla la **experiencia lista para usar (OOBE)** — lo que el usuario ve cuando enciende el equipo. **Abre los perfiles de despliegue en Intune** En el [**Centro de administración de Microsoft Intune**](https://intune.microsoft.com/#home), ve a **Devices** > **Windows**, y después a **Enrollment** > **Deployment Profiles**. :::info Crear un perfil de despliegue requiere una de estas licencias: **Microsoft 365 E3**, **Microsoft 365 E5**, **Microsoft 365 F1**, **Microsoft 365 F3** o **Microsoft 365 Business Premium**. ::: **Crea un perfil nuevo** Haz clic en **\+ Create profile** > **Windows PC**. **Nombra tu perfil** Usa un nombre descriptivo que identifique su propósito, por ejemplo: `Applivery-Standard-Setup`. **Configura los ajustes de la OOBE** Configura la experiencia lista para usar con los siguientes ajustes: - **Deployment mode**: selecciona `User-driven`. - **Join to Microsoft Entra ID as**: selecciona `Microsoft Entra ID joined`. - **Hide privacy settings**: establece en `Hide` para una experiencia más fluida. - **User account type**: selecciona `Standard user` (recomendado por seguridad). **Guarda y asigna el perfil** **Guarda** el perfil y asígnalo a un grupo de Entra ID que contenga tus dispositivos de destino. El perfil se aplicará automáticamente a todos los dispositivos registrados en ese grupo. ### 3\. Registro de hardware El dispositivo debe ser _"conocido"_ por Microsoft antes de que Autopilot pueda gestionarlo. **Obtén el hardware hash de cada dispositivo** El hardware hash es un identificador único que se usa para registrar el dispositivo en Autopilot. Puedes obtenerlo de dos formas: - Solicitando el archivo `.csv` directamente a tu proveedor de hardware. - Ejecutando el script de PowerShell `Get-WindowsAutopilotInfo.ps1` en los dispositivos. **Abre la pantalla de importación de dispositivos en Intune** En el [**Centro de administración de Microsoft Intune**](https://intune.microsoft.com/#home), ve a **Devices** > **Windows**, y después a **Enrollment** > **Devices**. **Importa el archivo CSV** Haz clic en **Import** y sube tu archivo `.csv`. **Espera a que se complete la importación** El estado cambiará de **Pending** a **Assigned** una vez que se aplique el perfil de despliegue de la Fase 2. Esto puede tardar unos minutos. ### 4\. Verificación y traspaso Una vez que se enciende un dispositivo registrado, comienza el flujo de aprovisionamiento automático. **Conecta el dispositivo al Wi-Fi** En cuanto el dispositivo se conecta a internet, reconoce su perfil de Autopilot automáticamente. **Inicia sesión con las credenciales de Microsoft Entra** Se pide al usuario que introduzca las credenciales de su cuenta corporativa de Microsoft durante la configuración de la OOBE. **Entra ID redirige el dispositivo a Applivery** Tras la autenticación, Entra ID verifica al usuario y usa la **MDM Discovery URL** configurada en la Fase 1 para redirigir la inscripción a Applivery en lugar de a Intune. **Comienza el aprovisionamiento automático** El Agente de Applivery se instala automáticamente, y el dispositivo empieza a descargar las Políticas y Apps que hayas configurado. ![provisioning](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/afea5756-39df-4eb5-86f3-3375fe99329f.png) Con Autopilot configurado, cada dispositivo nuevo que tu organización encienda se inscribe en Applivery por sí solo — sin crear imágenes, sin que un técnico lo toque y con tus Políticas y Apps aplicadas desde el primer arranque. --- ## Primeros pasos Source: https://docs.applivery.com/es/device-management/windows/get-started/ Description: Activa Windows Enterprise en Applivery para habilitar la Gestión de Dispositivos Windows y crear Inscripciones inteligentes para tus dispositivos. TL;DR: Activa Windows Enterprise en Applivery para habilitar la Gestión de Dispositivos Windows y las inscripciones inteligentes. Answers: ¿Cómo habilito la Gestión de Dispositivos Windows en Applivery? · ¿Dónde encuentro la sección de Configuración Windows en Applivery? · ¿Qué necesito para activar Windows Enterprise en Applivery? · ¿Qué puedo hacer después de activar Windows Enterprise en Applivery? · ¿Dónde puedo aprender sobre las Inscripciones inteligentes en Applivery? Antes de usar la Gestión de Dispositivos Windows de Applivery, debes habilitar tu Workspace para interactuar con los servicios de Windows y registrar tu organización de Windows Enterprise. #### Activar Windows Enterprise Inicia sesión en el [**panel de Applivery**](https://dashboard.applivery.io/) y ve a la sección de Configuración. Localiza la sección Configuración Windows en el menú de la izquierda. Junto al Paso 1, haz clic en el botón **Activar**. ![windows enterprise](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/a0290b71-fdd3-456a-a609-a17baf7c3584.png) :::tip Asegúrate de tener los permisos necesarios para activar Windows Enterprise en tu cuenta de Applivery. ::: A partir de ese momento podrás personalizar el dominio para inscribir dispositivos y empezar a crear [Inscripciones inteligentes](https://docs.applivery.com/es/device-management/windows/enrollment/smart-enrollment/). --- ## Políticas Source: https://docs.applivery.com/es/device-management/windows/policies/ Description: Políticas de Windows en Applivery — configura ajustes de seguridad, reglas de cumplimiento y restricciones de dispositivos a escala. Answers: ¿Qué es la Gestión de Dispositivos Windows en Applivery? · ¿Qué puedo hacer con la Gestión de Dispositivos Windows en Applivery? · ¿Cómo gestiono dispositivos Windows con Applivery? · ¿Puedo desplegar apps en dispositivos Windows con Applivery? · ¿Puedo aplicar políticas de seguridad en dispositivos Windows con Applivery? · ¿Admite Applivery el modo quiosco para dispositivos Windows? · ¿Puedo gestionar ajustes OEM para dispositivos Windows en Applivery? Las Políticas de Windows en Applivery te permiten aplicar estándares de seguridad y requisitos de configuración en todos tus dispositivos Windows gestionados. Puedes controlar los ajustes del sistema, aplicar el cifrado BitLocker, configurar el Firewall, gestionar usuarios locales, restringir funciones y desplegar scripts. Los ajustes de políticas de Windows están organizados por categoría, con orientación paso a paso para las configuraciones más comunes. --- ## Configuraciones ADMX personalizadas Source: https://docs.applivery.com/es/device-management/windows/policies/admx-configs/ Description: Importa plantillas ADMX y ADML personalizadas en Applivery para gestionar políticas de aplicaciones de terceros en dispositivos Windows, más allá de las categorías integradas. TL;DR: Importa la plantilla ADMX de un fabricante en una política de Windows desde Custom Policies > Import ADMX, y gestiona sus ajustes de directiva de grupo desde el panel como cualquier otra configuración. Answers: ¿Qué es una configuración ADMX personalizada en Applivery? · ¿Cuándo debo importar una plantilla ADMX? · ¿Necesito también el fichero ADML? · ¿Qué hace "Apply to User Scope"? · ¿Tengo que configurar todos los ajustes de la plantilla? · ¿Puedo importar más de una plantilla en la misma política? · ¿Las plantillas importadas son específicas de una política? · ¿Cómo elimino una plantilla ADMX que ya no necesito? Key topics: Plantillas ADMX y ADML, Políticas de aplicaciones de terceros, Categorías de Custom Policies, Biblioteca de plantillas del workspace, Applivery, Windows, Directiva de grupo, Google Chrome Enterprise Applivery incluye un conjunto de categorías de **Custom Policies** integradas para Windows — Application Control, Assigned Access, BitLocker, Device Manageability y más — que cubren de serie los ajustes de directiva de grupo más habituales. Pero buena parte de lo que necesitas gestionar no vive en esas categorías. Aplicaciones de terceros como Google Chrome Enterprise, Adobe o Zoom publican sus propias plantillas **ADMX**, el mismo formato de directiva de grupo que se usa on-premises. Para esos casos puedes importar la plantilla del fabricante directamente en una política: Applivery la lee y convierte cada ajuste que define en una configuración gestionable, con su descripción, su ruta de registro y sus valores posibles, igual que una categoría nativa de Applivery. ### Cuándo usarlo Importa una configuración ADMX personalizada cuando: - Necesites gestionar una aplicación o componente que **no esté entre las categorías de Custom Policies integradas**. - El fabricante de esa aplicación publique una plantilla **ADMX** oficial y, opcionalmente, un fichero **ADML** con los nombres y descripciones localizados. - Quieras gestionar esos ajustes desde el panel, en lugar de recurrir a [scripts](https://docs.applivery.com/es/device-management/windows/policies/scripts/) o a claves de registro en crudo. ### Importar una plantilla **Abrir la categoría Custom Policies** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), abre **Políticas** 1 y elige la política de Windows donde quieras añadir la configuración. En el menú lateral izquierdo, selecciona **\+ Añadir configuración** 2, donde verás la configuración **Políticas personalizadas** 3. Junto a las categorías integradas encontrarás arriba un botón con el que **Importar ADMX** 4. ![admx](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/49c4b081-75d6-42a3-84b0-3e0987fc5221.png) **Elegir o subir la plantilla** Haz clic en **Importar ADMX** para abrir el diálogo de importación. Desde ahí puedes: - **Seleccionar una configuración ADMX existente**: elige entre las plantillas que tu organización ya haya importado. Aparecen en **Recently used**, cada una con su tipo de ajuste y cuántas propiedades contiene, repartidas por ámbito de **dispositivo**, **usuario** y **ambos**. - **Cargar una configuración nueva**: sube un fichero `.admx` nuevo y, opcionalmente, su fichero `.adml` con los nombres y descripciones localizados. :::info El fichero ADML es opcional, pero merece la pena subirlo cuando el fabricante lo proporciona. Sin él, los ajustes aparecen con sus nombres internos en crudo, lo que hace bastante más difícil manejar una plantilla de varios cientos de entradas. ::: **Decidir sobre los ajustes de usuario** Marca **Aplicar al ámbito de Usuario** si también quieres los ajustes de ámbito de usuario de la plantilla, los que están bajo `HKCU`. Sin marcarlo, solo se importan los de ámbito de dispositivo, bajo `HKLM`. **Importar** Haz clic en **Importar**. Applivery analiza la plantilla y la añade en **Políticas personalizadas** como una nueva entrada de configuración, que aparecerá en el menú lateral izquierdo. ### Configurar los ajustes importados Abre la nueva configuración desde el menú lateral izquierdo. Cada ajuste definido en la plantilla aparece por separado con: - Su nombre y su descripción, exactamente como los publica el fabricante. - La ruta de registro a la que corresponde — por ejemplo `Software\\Policies\\Google\\Chrome\\LiveCaptionEnabled`. - Un interruptor para marcarlo como **Configured**, junto con el valor o valores a establecer. :::info **Solo configuras lo que te interesa.** Dejar un ajuste sin tocar significa que Applivery no aplica ningún valor para él: importar una plantilla con cientos de ajustes no significa que ahora gestiones cientos de ajustes. ::: Si el mismo fabricante publica más de una plantilla — ficheros separados para distintos grupos de ajustes, por ejemplo — repite la importación en la misma categoría con **\+ Añadir configuración**, sin salir de la política. Cuando termines, haz clic en **Guardar** en la parte superior de la política para enviar los cambios a los dispositivos asignados. ### Tu biblioteca de plantillas ADMX Las plantillas importadas se guardan **a nivel de workspace**, no por política. Por eso aparecen en **Recently used** la próxima vez que importes una en otra política: subes la plantilla de un fabricante una vez y la reutilizas donde la necesites. Desde el diálogo de importación, **Administrar** 5 abre la lista completa de plantillas subidas a tu workspace, donde puedes revisar cuáles están asignadas actualmente a alguna política y eliminar las que ya no necesites. ![manage admx](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/77dd1737-075d-4ab6-be5a-761814537d7b.png) :::warning Comprueba a qué está asignada una plantilla antes de eliminarla. Como las plantillas se comparten en todo el workspace, quitar una afecta a todas las políticas que la estén usando, no solo a la que tengas abierta. ::: --- ## Agente Source: https://docs.applivery.com/es/device-management/windows/policies/agent/ Description: El agente MDM de Windows de Applivery amplía el MDM nativo de Windows con opciones de Self-Service, control avanzado y Gestión de dispositivos mejorada. TL;DR: El Agente MDM Windows de Applivery mejora el MDM de Windows añadiendo funciones de Self-Service y capacidades de gestión avanzadas más allá de los protocolos MDM estándar. Answers: ¿Qué es el agente MDM de Windows de Applivery? · ¿Cuáles son los beneficios de usar el agente Windows de Applivery? · ¿Qué es la función de Self-Service del agente Windows? · ¿Qué es el catálogo de apps en la función de Self-Service? · ¿Cómo ejecutan los usuarios scripts en la función de Self-Service? · ¿Cómo habilito el agente Windows en Applivery? · ¿Dónde encuentro instrucciones para gestionar apps en el catálogo de apps? · ¿Dónde encuentro instrucciones para asignar un script a Self-Service? El **agente MDM Windows de Applivery** es un componente de software opcional que se puede instalar en dispositivos Windows gestionados para ampliar las capacidades de gestión de Applivery más allá de las limitaciones del protocolo MDM nativo de Windows. Al complementar las APIs MDM estándar, el agente desbloquea funcionalidades avanzadas que de otro modo no estarían disponibles a través del framework de gestión integrado de Microsoft. Antes de desplegar el agente Windows, es importante entender y cumplir con las directrices y requisitos de Microsoft para garantizar un funcionamiento correcto, estabilidad del sistema y alineación de seguridad en entornos empresariales. Al usar el agente Windows, las organizaciones obtienen acceso a opciones de personalización más profundas y un control más completo sobre su flota de dispositivos Windows. Esto permite a los equipos de TI implementar flujos de trabajo avanzados, mejorar la automatización y gestionar los dispositivos de forma más eficaz, manteniendo al mismo tiempo el cumplimiento con las políticas corporativas. El agente proporciona valor añadido tanto para los usuarios finales como para los administradores: los usuarios se benefician de las capacidades del Self-Service que reducen la dependencia de TI, mientras que los administradores obtienen mayor visibilidad, control y eficiencia operativa. ### Self-Service Una de las funciones principales del agente Windows es el **Self-Service**, diseñado para reducir la carga de TI permitiendo a los usuarios resolver solicitudes comunes de forma independiente. A través de la integración con los dispositivos gestionados, Applivery despliega un entorno de Self-Service dedicado donde los usuarios pueden acceder a recursos y acciones aprobadas sin intervención del administrador. Este enfoque mejora la productividad, acorta los tiempos de respuesta y permite a los equipos de TI centrarse en tareas de mayor valor. ![self-service-app-catalog | Applivery](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/77351313-0afd-4f4e-9a0b-d8c8a13ada80.png) #### Catálogo de apps Los administradores pueden definir un catálogo de aplicaciones aprobadas que los usuarios finales pueden instalar bajo demanda. Esto garantiza la consistencia del software mientras da flexibilidad a los usuarios. Las instrucciones detalladas para gestionar aplicaciones están disponibles en la siguiente [documentación](https://docs.applivery.com/es/device-management/windows/app-management/manage-apps/). #### Acciones El Self-Service también permite a los usuarios ejecutar scripts predefinidos para ayudar con tareas comunes o resolver problemas relacionados con el dispositivo. Los resultados de la ejecución de scripts se reportan automáticamente al portal de Applivery, dando a los administradores visibilidad sobre las acciones realizadas en los dispositivos. Los scripts pueden asignarse selectivamente al Self-Service para garantizar que los usuarios solo tengan acceso a operaciones seguras y aprobadas. Puedes aprender cómo asignar un script a Self-Service [aquí](https://docs.applivery.com/es/device-management/windows/policies/scripts/). ### Habilitar el agente Windows En el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a cualquiera de tus **Políticas** 1. En el menú lateral izquierdo, dirígete a **Agente** 2 y **habilítalo** 3. ![windows agent](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/abd4250d-506e-4397-8f6a-4ac14a9f98e0.png) Una vez habilitado y desplegado, el agente comenzará a ampliar las capacidades de gestión de dispositivos según la configuración de política seleccionada. :::info ¡Todas las funciones de seguimiento de actividad del dispositivo estarán **disponibles próximamente**! ::: --- ## Bloquear sitios web en Edge e IE Source: https://docs.applivery.com/es/device-management/windows/policies/block-websites-edge-ie/ Description: Bloquea sitios web específicos en Internet Explorer y Microsoft Edge usando las políticas de Gestión de Dispositivos Windows de Applivery. TL;DR: Bloquea sitios web en Internet Explorer y Microsoft Edge usando las políticas personalizadas de Applivery para controlar el acceso y mejorar la seguridad. Answers: ¿Cómo puedo bloquear URLs en Internet Explorer y Edge con Applivery? · ¿Dónde configuro el bloqueo de URLs en el panel de Applivery? · ¿Qué OMA-URI uso para bloquear sitios web en Applivery? · ¿En qué formato debe estar la lista de URLs bloqueadas? · ¿Cómo agrego una política personalizada en Applivery? · ¿Qué navegadores afecta esta configuración de bloqueo de URLs? · ¿Por qué debería bloquear URLs en Internet Explorer y Edge? Bloquear URLs en Internet Explorer y Microsoft Edge es una forma útil de controlar el acceso a la web en los dispositivos gestionados. Ya sea para mejorar la productividad, limitar distracciones o mejorar la seguridad, restringir el acceso a sitios web concretos puede ayudar a las organizaciones a aplicar sus Políticas de navegación de forma eficaz. Con Applivery, los administradores pueden configurar estas restricciones de forma centralizada para garantizar que los usuarios solo accedan a contenido aprobado, creando un entorno de navegación más seguro y controlado. ### Control del acceso web En el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a **Políticas** 1. Elige la política en la que quieres agregar esta configuración. **Ir a Políticas personalizadas** En el menú de la izquierda, selecciona **\+ Añadir configuración** 2, busca **Políticas personalizadas** 3 y luego haz clic en **\+ Añadir Valor** para crear la nueva configuración. ![custom Policies](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/0e35e04b-4f94-4c3e-8a7b-5066d2f3a91f.png) Recuerda seleccionar la política correcta antes de agregar la configuración personalizada. Usa el siguiente OMA-URI para bloquear sitios web: - **OMA-URI**: `./Vendor/MSFT/Policy/Config/InternetExplorer/DisallowRunOnSites`. - **Formato**: String (chr). - **Valor**: Configura una lista de URLs bloqueadas separadas por punto y coma. ![block websites](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/960c9127-6db1-49c8-9bac-a2827d88afe4.png) --- ## Crear usuarios administradores locales Source: https://docs.applivery.com/es/device-management/windows/policies/create-local-admin-users/ Description: Crea cuentas de administrador local en dispositivos Windows usando políticas personalizadas de Applivery — automatiza la creación de usuarios y simplifica la Gestión de Dispositivos. TL;DR: Crea cuentas de administrador local en dispositivos Windows usando las políticas personalizadas de Applivery y OMA-URI para una gestión simplificada. Answers: ¿Cómo puedo crear una cuenta de administrador local en dispositivos Windows con Applivery? · ¿Qué OMA-URI uso para crear una nueva cuenta de usuario local en Applivery? · ¿En qué formato debe estar el valor de la contraseña al crear una cuenta de usuario local? · ¿Cómo asigno derechos de administrador a un usuario local creado con Applivery? · ¿Qué valor representa el grupo de administradores locales al asignar derechos de admin? · ¿Dónde configuro las políticas personalizadas en el panel de Applivery? · ¿Qué debo hacer si ya gestiono la pertenencia al grupo de administradores locales? Gestionar los permisos de los usuarios es un aspecto crítico de la seguridad y el control de los dispositivos en entornos empresariales. En ciertos escenarios, es necesario crear cuentas de administrador local en dispositivos Windows — por ejemplo, para permitir al personal de TI realizar mantenimiento, desplegar software o resolver problemas sin depender de credenciales de dominio. Con Applivery, puedes automatizar la creación de usuarios admin locales en toda tu flota a través de la configuración de políticas. Esto garantiza un control de acceso consistente, simplifica la gestión de dispositivos y reduce el riesgo de errores manuales. Usando el **Accounts CSP** a través de la configuración de **Políticas personalizadas** de Applivery, puedes desplegar Políticas basadas en OMA-URI para crear un usuario local y asignarle derechos de administrador. **Creación del usuario** En el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a **Políticas** 1. Elige la política en la que quieres crear un usuario admin. A continuación, en el menú de la izquierda, selecciona **\+ Añadir configuración** 2, busca **Políticas personalizadas** 3 y haz clic en + Añadir Valor para crear la nueva configuración. ![custom Policies](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/beb5c7a9-44ca-41c1-91ad-aa66ead38dbd.png) Usa el siguiente OMA-URI para crear una nueva cuenta de usuario local: - **OMA-URI**: `./Device/Vendor/MSFT/Accounts/Users//Password`. `` representa el nombre de usuario local — reemplázalo con el nombre deseado para la nueva cuenta de usuario. - **Formato**: String (chr). - **Valor**: Este valor establece la contraseña de la cuenta local — reemplázalo con la contraseña que quieras asignar. **Hacer al usuario administrador** Para hacer que el usuario recién creado sea administrador local, aplica este OMA-URI: - **OMA-URI**: `./Device/Vendor/MSFT/Accounts/Users//LocalUserGroup`. - **Formato**: Integer (int). - **Valor**: 2 (este valor describe el grupo de administradores locales). :::warning Si ya gestionas las membresías del grupo de administradores locales a través de la plantilla de configuración "Usuarios y Grupos Locales", debes agregar la cuenta recién creada en la configuración XML; de lo contrario, la nueva cuenta podría perder sus permisos de administrador local. ::: --- ## Eliminar perfiles de usuario inactivos Source: https://docs.applivery.com/es/device-management/windows/policies/delete-inactive-user-profiles/ Description: Elimina automáticamente perfiles de usuario inactivos en dispositivos Windows con Applivery para mejorar el rendimiento del sistema y reducir el consumo de almacenamiento. TL;DR: Elimina automáticamente los perfiles de usuario inactivos en Windows para optimizar el rendimiento del sistema y el almacenamiento usando las políticas personalizadas de Applivery. Answers: ¿Qué hace la eliminación de perfiles de usuario inactivos? · ¿Cómo determina Windows si un perfil de usuario está inactivo? · ¿Qué ocurre si se deshabilita la política de eliminación automática de perfiles? · ¿Dónde puedo configurar la eliminación automática de perfiles de usuario? · ¿Cómo se mide el período de inactividad para la eliminación de perfiles? · ¿Por qué debería eliminar perfiles de usuario antiguos? · ¿Cómo habilito la eliminación automática de perfiles de usuario inactivos en Applivery? La **Gestión de Perfiles de Usuario** de Windows incluye un ajuste que permite a los administradores **eliminar automáticamente perfiles de usuario** que han estado inactivos durante un número de días especificado al reiniciar el sistema. Esta función ayuda a las organizaciones a mantener sistemas más limpios eliminando perfiles antiguos y sin uso, lo que puede reducir el consumo de almacenamiento y mejorar el rendimiento general del sistema. Cuando está habilitado, el **Servicio de Perfiles de Usuario** revisará todos los perfiles del dispositivo en el próximo reinicio y eliminará aquellos que no hayan sido accedidos dentro del período de tiempo configurado, medido en períodos de 24 horas desde su último uso. Esta limpieza automática garantiza que solo los usuarios activos mantengan perfiles en el sistema, reduciendo el desorden y los posibles riesgos de seguridad asociados con los perfiles obsoletos. Si esta política está deshabilitada o no está configurada, los perfiles de usuario permanecerán sin cambios, lo que significa que todos los perfiles, independientemente de la actividad, persistirán en el sistema. En entornos gestionados, esta política puede configurarse y desplegarse de forma centralizada en Dispositivos Windows, permitiendo a los equipos de TI aplicar un mantenimiento consistente de perfiles de usuario y optimizar eficazmente el estado del dispositivo y la gestión del almacenamiento. ### Eliminación automática de perfiles inactivos En el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a **Políticas** 1. Elige la política en la que quieres agregar esta configuración. A continuación, en el menú de la izquierda, selecciona **\+ Añadir configuración** 2 y busca **Perfiles de Usuario** 3. ![user profiles](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/830de90e-fe34-4a70-9b18-97a5de1e9376.png) Localiza el ajuste **Eliminar perfiles de usuario con más de un número de días especificado al reiniciar el sistema > Limpiar Perfiles** y especifica el número de días tras los cuales los perfiles de usuario inactivos se eliminarán automáticamente al reiniciar el sistema. ![delete user profiles](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/191c5af9-fe1d-405f-be53-989afe6ab97c.png) --- ## Desplegar BitLocker Source: https://docs.applivery.com/es/device-management/windows/policies/deploy-bitlocker/ Description: Activa el cifrado BitLocker desde una política y guarda la clave de recuperación directamente en Applivery, sin necesidad de unir el dispositivo a Entra ID ni a Active Directory. TL;DR: Cifra un dispositivo Windows desde una política a través del agente de Windows de Applivery y consulta la clave de recuperación en el panel. Sin unión a ningún directorio. Answers: ¿Cómo cifro un dispositivo Windows sin Entra ID? · ¿Dónde está la clave de recuperación de BitLocker en Applivery? · ¿Cómo despliego BitLocker con Applivery? · ¿BitLocker gestionado por el agente necesita TPM? · ¿Por qué mi dispositivo informa de una discrepancia de cifrado? Key topics: BitLocker gestionado por el agente, Método y tipo de cifrado, Obtención de la clave de recuperación, Conflictos con BitLocker nativo, Applivery, BitLocker, Windows, Entra ID, Active Directory, TPM Applivery despliega BitLocker a través del agente de Windows de Applivery, que se encarga él mismo del cifrado y de la custodia de la clave de recuperación, sin necesidad de unir el dispositivo a **Entra ID** ni a **Active Directory**. Cifras el volumen desde una política y la clave de recuperación queda en el panel de Applivery, donde puedes consultarla cuando la necesites. ### Requisitos previos La sincronización de BitLocker la realiza aquí el [agente de Windows](https://docs.applivery.com/es/device-management/windows/policies/agent/). :::warning **Sin el agente instalado en el dispositivo, BitLocker no se puede usar** con esta configuración. Asegúrate de que el agente está activado para el segmento del dispositivo antes de configurar nada. ::: Se recomienda un TPM (Trusted Platform Module), aunque no es estrictamente obligatorio, para una protección de clave más sólida y un arranque seguro del dispositivo. ### Activar BitLocker **Abre la política** En el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a **Políticas** 1. Elige la política en la que quieres configurar Bitlocker 2. ![bitlocker](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/52e2fc22-0d0b-4935-b08b-0e74aab2001d.png) **Elige el estado de cifrado** Configura **Cifrado de BitLocker** con una de estas opciones:

Opción

Efecto

Sin configurar

No hace nada. Deja el estado de cifrado actual del dispositivo tal como está.

Cifrado

Activa el cifrado BitLocker y guarda de forma segura la clave de recuperación en Applivery.

Sin cifrar

Descifra el dispositivo, lo contrario de Cifrado.

![encryption](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/2972fd42-d155-4733-b5d9-d745d273d29d.png) **Define el método y el tipo de cifrado** Cuando lo pones en **Cifrado**, aparecen dos ajustes más: - **Método de cifrado**: el algoritmo que BitLocker usa para cifrar las unidades — `AES-CBC 128-bit`, `AES-CBC 256-bit`, `XTS-AES 128-bit` o `XTS-AES 256-bit`, que es la opción recomendada y la predeterminada. - **Tipo de cifrado**: si se cifra la **unidad completa** o **solo el espacio usado**, que es la opción recomendada y la predeterminada. **Guarda** Haz clic en **Guardar cambios**. ### Obtener la clave de recuperación Cuando un dispositivo informa de que está cifrado, abre su pestaña **Ajustes** y selecciona **BitLocker** en el listado lateral. - **Estado**: una etiqueta de estado (`Encrypted`) más la línea de estado del protector, que distingue un protector `PERMANENT` de uno `ONETIME`, y cuándo se actualizó por última vez. - **Claves de recuperación**: la clave de recuperación permanente del dispositivo, con un botón de copiado en un clic. - **Claves de recuperación temporales**: una clave de recuperación de un solo uso, independiente de la anterior y también copiable. No hay ninguna dependencia de Entra ID ni de Active Directory para consultar nada de esto. Se guarda y se recupera directamente a través de Applivery. ### Evitar conflictos con los ajustes nativos de BitLocker Si la misma política —u otra que afecte al mismo dispositivo— configura además BitLocker de forma nativa, Applivery te avisa en la propia pantalla de configuración. Eso incluye una configuración ADMX personalizada y la categoría CSP nativa **Bit Locker**. :::warning **También configurado de forma nativa** — La sección "Cifrado" configura 1 propiedad nativa de BitLocker que Windows aplica por su cuenta. Los ajustes que contradigan a los de abajo hacen que el dispositivo informe de una discrepancia de cifrado: mantenlos alineados o gestiona BitLocker desde uno solo de los dos sitios. ::: En la práctica: elige **un** método por dispositivo, BitLocker gestionado por el agente o el nativo basado en CSP, en lugar de configurar los dos. Eso es lo que evita que el dispositivo informe de una discrepancia de cifrado. --- ## Deshabilitar la desinscripción manual Source: https://docs.applivery.com/es/device-management/windows/policies/disable-manual-unenrollment/ Description: Evita que los usuarios desinscriban manualmente los dispositivos Windows de Applivery MDM — aplica la gestión persistente con una política. TL;DR: Deshabilita la desinscripción manual del MDM en dispositivos Windows mediante política de Applivery para mantener el control y la seguridad de tu flota. Answers: ¿Por qué deshabilitar la desinscripción manual de MDM en Windows? · ¿Cómo deshabilito la desinscripción manual de MDM en Applivery? · ¿Dónde encuentro la sección 'Políticas' en Applivery? · ¿Qué configuración agrego para deshabilitar la desinscripción manual de MDM? · ¿Qué valor deshabilita la desinscripción manual de MDM? · ¿Qué ocurre cuando se deshabilita la desinscripción manual de MDM? · ¿Cuál es el riesgo de permitir la desinscripción manual de MDM? Por defecto, Windows permite a los usuarios desconectar manualmente su dispositivo de un proveedor de Gestión de Dispositivos Móviles (MDM). En entornos gestionados, esto puede suponer un riesgo, ya que permite a los usuarios finales eludir las configuraciones de seguridad o cumplimiento. Para mantener el control y garantizar una gestión persistente, puedes deshabilitar esta opción configurando una política. ### Deshabilitar la eliminación manual de MDM **Ir a Políticas** En el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a **Políticas** 1. Elige la política en la que quieres agregar esta configuración. **Añadir configuración** En el menú de la izquierda, selecciona **\+ Añadir configuración** 2 y busca **Experiencia** 3. ![experience](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/f631bcc5-3b7d-4a73-82ad-c9f4bc04d5a1.png) **Deshabilitar la desinscripción manual** Localiza el ajuste **Permitir desinscripción manual de MDM** y establece su valor en **0**. Esto evitará que los usuarios desinscriban manualmente el dispositivo de Applivery. ![disallow user unenrollment](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/e52b44b2-6dc1-4186-9b40-b9b14e2eb8c5.png) --- ## Deshabilitar Microsoft Consumer Experiences Source: https://docs.applivery.com/es/device-management/windows/policies/disable-microsoft-consumer-experiences/ Description: Deshabilita Microsoft Consumer Experiences en dispositivos Windows con Applivery para evitar instalaciones de apps no deseadas y mejorar la gestión corporativa. TL;DR: Deshabilita Microsoft Consumer Experiences en Windows para evitar instalaciones de apps no deseadas y mejorar la concentración del usuario. Answers: ¿Qué es Microsoft Consumer Experiences en Windows? · ¿Por qué deshabilitar Microsoft Consumer Experiences en dispositivos corporativos? · ¿Cómo mejora la privacidad de datos deshabilitar Consumer Experiences? · ¿Cómo accedo a las políticas de dispositivos en Applivery? · ¿Dónde encuentro la configuración 'Experiencia' en Applivery? · ¿Cómo deshabilito los consejos de Windows con Applivery? · ¿Cuáles son los beneficios de deshabilitar los consejos de Windows? Microsoft Consumer Experiences es una función integrada en Windows que ofrece recomendaciones de apps, notificaciones y ofertas a los usuarios, incluyendo a menudo la instalación automática de apps sugeridas desde la Microsoft Store. Aunque está diseñada para mejorar la experiencia del usuario proporcionando contenido personalizado, puede llevar a que aparezcan apps no deseadas en los dispositivos corporativos, causando distracciones y posibles problemas de seguridad. Deshabilitar Microsoft Consumer Experiences permite a los administradores de TI evitar estas instalaciones automáticas y sugerencias personalizadas, garantizando un entorno más limpio y controlado en los dispositivos Windows. Esta función limita el uso de datos de diagnóstico para experiencias personalizadas, reduciendo los datos enviados a Microsoft para estos fines y ayudando a las organizaciones a aplicar políticas de privacidad y seguridad más estrictas. Al desactivar estas funciones para el consumidor, las organizaciones pueden gestionar mejor los dispositivos corporativos, evitar instalaciones de software no aprobadas y mantener un entorno de TI más enfocado. ### Deshabilitar Microsoft Consumer Experiences **Ir a Gestión de Dispositivos y Políticas** En el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a **Políticas** 1. Elige la política en la que quieres agregar esta configuración. **Añadir configuración y buscar Experiencia** A continuación, en el menú de la izquierda, selecciona **\+ Añadir configuración** 2 y busca **Experiencia** 3. ![experience](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/3c3da182-fbd4-457d-b8c9-60a1ed45c5ec.png) **Deshabilitar los consejos de Windows** Localiza el ajuste **No mostrar consejos de Windows** y establece su valor en **0**. Esto deshabilitará los consejos de Windows para todos los usuarios. ![do not show windows tips](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/40b5e078-f4bc-416d-a9f7-bcdef0876f7b.png) --- ## Deshabilitar datos móviles Source: https://docs.applivery.com/es/device-management/windows/policies/disable-mobile-data/ Description: Deshabilita los datos móviles en dispositivos Windows usando las políticas de Applivery — controla el uso de datos, mejora la seguridad y aplica restricciones de red. TL;DR: Aprende a deshabilitar los datos móviles en dispositivos Windows con Applivery para controlar el uso de datos y mejorar la seguridad. Answers: ¿Por qué deshabilitar los datos móviles en dispositivos Windows? · ¿Cómo deshabilito los datos móviles en dispositivos Windows con Applivery? · ¿Dónde encuentro la sección 'Políticas' en Applivery? · ¿Cómo mejora la seguridad deshabilitar los datos móviles? · ¿Qué tipo de configuración necesito agregar para deshabilitar los datos móviles? · ¿Cómo se llama el ajuste para deshabilitar los datos móviles? · ¿Cuáles son los beneficios de gestionar los datos móviles? Deshabilitar los datos móviles en dispositivos Windows es un paso esencial para las organizaciones que buscan optimizar la conectividad, controlar los costes de uso de datos y aplicar políticas de seguridad de red. Con la creciente dependencia de portátiles, tablets y dispositivos híbridos Windows que admiten conexiones celulares, gestionar el acceso a los datos móviles de forma remota es crucial para evitar el uso no autorizado y reducir los cargos inesperados. Windows proporciona ajustes y controles de política integrados que permiten a los administradores de TI deshabilitar o restringir el uso de datos móviles en los dispositivos corporativos. Al aprovechar estas capacidades a través de Applivery, las organizaciones pueden configurar de forma centralizada las restricciones de datos móviles, garantizando que los dispositivos cumplan las políticas corporativas mientras se minimiza la interrupción de los flujos de trabajo de los usuarios. Deshabilitar los datos móviles mejora la seguridad al limitar los dispositivos a las redes aprobadas, reduciendo los riesgos asociados con las conexiones celulares no seguras. También admite los requisitos de cumplimiento al evitar fugas de datos y controlar el tráfico de red. Además, gestionar eficazmente los datos móviles ayuda a alargar la batería y garantiza un rendimiento de red predecible. ### Deshabilitar datos móviles Políticas"> En el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a **Políticas** 1. Elige la política en la que quieres agregar esta configuración. **Añadir configuración de Conectividad** En el menú de la izquierda, selecciona **\+ Añadir configuración** 2 y busca **Conectividad** 3. ![connectivity](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/59220abb-6cff-47de-be1d-8666d0728d5c.png) **Configurar datos celulares** Localiza el ajuste **Permitir datos celulares** y establece su valor según tus requisitos específicos. ![disallow celular data](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/cfeb7d10-37b7-4c33-8f35-e2e341a2734c.png) --- ## Gestionar el historial del portapapeles Source: https://docs.applivery.com/es/device-management/windows/policies/manage-clipboard-history/ Description: Gestiona el historial de portapapeles de Windows con las políticas de Applivery — controla el almacenamiento y el uso compartido de datos para equilibrar la productividad del usuario y la seguridad. TL;DR: Gestiona el Historial del Portapapeles de Windows mediante Applivery para equilibrar la productividad del usuario con los requisitos de seguridad de datos empresariales. Answers: ¿Qué es el historial de portapapeles de Windows? · ¿Cómo accedo al historial de portapapeles de Windows? · ¿Puedo sincronizar el historial de portapapeles entre dispositivos? · ¿Cómo controlan los administradores de TI el historial de portapapeles? · ¿Cómo configuro el historial de portapapeles en Applivery? · ¿Dónde está el ajuste 'Permitir historial de portapapeles' en Applivery? · ¿Qué hace el ajuste 'Permitir historial de portapapeles'? El **historial de portapapeles** de Windows es una potente función de productividad que permite a los usuarios almacenar varios elementos copiados — como texto, imágenes y enlaces — en un historial accesible mediante un atajo de teclado simple. Esta función admite anclar los elementos usados con frecuencia para un acceso rápido y sincronizar los datos del portapapeles entre Dispositivos a través de cuentas de Microsoft, permitiendo flujos de trabajo fluidos en varios Dispositivos Windows. Desde el punto de vista de la gestión de TI, controlar el historial de portapapeles de forma centralizada es esencial para equilibrar la productividad de los usuarios con la seguridad. Los administradores pueden habilitar o deshabilitar esta función para evitar que los datos sensibles se almacenen o compartan de forma no intencionada. Entender y gestionar el historial de portapapeles de Windows permite a las organizaciones mejorar la eficiencia de los usuarios mientras protegen la información, convirtiéndolo en un componente clave de la gestión de dispositivos empresariales. ### Configurar tu política **Ir a Gestión de Dispositivos** En el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a **Políticas** 1. Elige la política en la que quieres agregar esta configuración. **Añadir configuración** En el menú de la izquierda, selecciona **\+ Añadir configuración** 2 y busca **Experiencia** 3. ![experience](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/b5946fdf-5443-46e9-894a-f2c3235c0d9d.png) **Configurar el historial de portapapeles** Localiza el ajuste **Permitir historial de portapapeles** para determinar si el historial del contenido del Portapapeles puede almacenarse en memoria. ![allow clipboard history](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/aa1f7db7-aa61-4486-b707-022ab2d47f78.png) --- ## Gestionar administradores locales Source: https://docs.applivery.com/es/device-management/windows/policies/manage-local-admins/ Description: Gestiona de forma centralizada el grupo de administradores locales en dispositivos Windows usando Applivery — agrega o elimina usuarios y grupos a través de políticas. TL;DR: Gestiona de forma centralizada el grupo de Administradores locales en dispositivos Windows con Applivery mediante configuración de políticas. Answers: ¿Cuál es el papel de Applivery en la gestión de administradores locales? · ¿Cómo configuro la gestión de usuarios y grupos locales en Applivery? · ¿Cuáles son las acciones disponibles para gestionar la membresía de grupos en Applivery? · ¿Cómo puedo garantizar una gestión consistente del grupo Administradores en diferentes idiomas de SO? · ¿Puedo degradar a un usuario de administrador a usuario estándar con Applivery? · ¿Cuál es una limitación clave al gestionar la cuenta integrada de Administrador de Windows? · ¿Cómo verifico si una política de usuarios y grupos locales se aplicó correctamente? · ¿Qué significa el error PutOrAddCommandFailedBecauseTargetAlreadyExists? Gestionar el grupo de administradores locales es esencial para mantener la seguridad y el control operativo sobre los dispositivos Windows. Conceder acceso administrativo solo a usuarios o cuentas de servicio de confianza ayuda a evitar cambios no autorizados, limita la superficie de ataque y garantiza el cumplimiento de las políticas organizativas. Con Applivery, puedes gestionar de forma centralizada el grupo de administradores locales en todos los dispositivos Windows inscritos aplicando una configuración de política. Esto permite a los administradores de TI agregar o eliminar usuarios o grupos específicos del grupo de administradores locales en toda la flota de dispositivos — de forma automática y consistente. :::info Esta política de grupo puede gestionar varios grupos locales; los pasos siguientes configuran el grupo de Administradores Locales. ::: ### Usuarios y grupos locales En el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a **Políticas** 1. Elige la política en la que quieres crear un usuario admin. A continuación, en el menú de la izquierda, selecciona **\+ Añadir configuración** 2 y busca **Usuarios y Grupos Locales** 3. ![local users and groups ](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/d6480006-6df0-4a45-85db-5430f31ef94e.png) Usaremos la siguiente plantilla: ```xml ``` Aquí tienes un desglose de los elementos XML: - ``: Incluye toda la configuración de gestión de grupos. - ``: Define el grupo local que quieres gestionar (por ejemplo, Administradores). - ``: Especifica cómo se debe gestionar la membresía del grupo: - **U** = Actualizar: Modifica el grupo agregando o eliminando solo los miembros especificados. Los miembros existentes no mencionados permanecerán sin cambios. - **R** = Reemplazar: Borra todos los miembros actuales y los reemplaza por los definidos. Usa **solo** `` con esta acción. - ``: Agrega un usuario o grupo al grupo de acceso especificado. - ``: Elimina un usuario o grupo del grupo de acceso especificado. :::warning Esta configuración no crea nuevos usuarios o grupos; solo gestiona los que ya existen en el dispositivo. ::: #### Ejemplo de gestión del grupo de Administradores En este ejemplo, nuestro objetivo es **reemplazar todos los miembros actuales** del grupo local de **Administradores** solo con los usuarios definidos explícitamente en la configuración XML. **Estado actual del grupo** El grupo de Administradores existente contiene tres usuarios. ![](https://www.applivery.com/wp-content/uploads/2025/07/image-3.png "members | Applivery") **Grupo objetivo** Definimos el grupo que queremos gestionar — en este caso, el grupo de **Administradores**. Esto puede identificarse de dos formas: - **Por nombre**: Usa **Administrators** si todos tus dispositivos comparten el mismo idioma del SO. - **Por SID**: Usa el **SID conocido S-1-5-32-544** para evitar problemas de localización, ya que el nombre del grupo varía según el idioma del sistema operativo. **Acción de grupo – Reemplazar** Usamos la acción **R (Reemplazar)** en el nodo ``. Esto eliminará todos los miembros actuales del grupo y los reemplazará por los definidos en el XML. **Definir miembros** Usa `` para especificar los usuarios o grupos que quieres incluir. En este caso, queremos que solo **Administrator** y **Applivery** permanezcan en el grupo. ![configure group](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/3cea4f53-2104-4d38-bb43-c190b3989f96.png) **Resultado** Una vez desplegado, el grupo de **Administradores** contendrá **solo** los usuarios definidos en el XML. Todos los demás serán eliminados. ![](https://www.applivery.com/wp-content/uploads/2025/07/image-4.png "final-admins-group | Applivery") :::info Si estás gestionando la **cuenta de Administrador integrada**, recuerda que su nombre también varía según el idioma del SO. Para evitar inconsistencias, puedes renombrarlo en todos los dispositivos usando el ajuste **Cuentas: Cambiar nombre de cuenta Administrador** en la política de grupo **Opciones de Seguridad de Directivas Locales**. ::: ![rename account](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/da2736ce-9407-4372-a136-45c5879806f7.png) #### Degradar usuarios de administrador a estándar Un escenario de cumplimiento habitual — por ejemplo, para cumplir los requisitos de ISO 27001 — es mover usuarios del grupo de Administradores al grupo de Usuarios estándar. Cuando Windows degrada a un usuario de Administrador a estándar, no lo agrega automáticamente al grupo de Usuarios, dejando al usuario sin membresía de grupo e incapaz de acceder al dispositivo. Para gestionar ambas acciones a la vez, configura un único XML con dos bloques — uno para eliminar al usuario de Administradores (`S-1-5-32-544`) y otro para agregarlo a Usuarios (`S-1-5-32-545`): ```xml ``` Reemplaza `ExactUsername` con el nombre de usuario exactamente como aparece en el dispositivo, y `BackupAdminName` con la cuenta de administrador de respaldo de tu organización. :::warning La cuenta integrada de Administrador de Windows no puede eliminarse del grupo de Administradores — esto se aplica a nivel del SO. Incluye siempre al menos un administrador con nombre en la línea `` del bloque de Administradores para evitar este error. ::: :::info Puedes usar `member="*"` para apuntar al usuario que ha iniciado sesión actualmente en lugar de un nombre de usuario específico. Si `*` no produce el resultado esperado, reemplázalo con el nombre de usuario exacto tal como aparece en el dispositivo. ::: :::warning Solo puede haber una configuración XML de usuarios y grupos locales activa por dispositivo. Si necesitas gestionar varios grupos, incluye todos los bloques `` dentro del mismo elemento `` — nunca apliques dos políticas separadas al mismo dispositivo. ::: * * * ### Resolución de problemas #### Verificar que la política se aplicó correctamente Para comprobar si la configuración se aplicó en un dispositivo, abre el **Visor de Eventos** (`eventvwr.exe`), dirígete a **Registros de aplicaciones y servicios → Microsoft → Windows → DeviceManagement-Enterprise-Diagnostics-Provider → Admin** y busca `LocalUsersAndGroups`. #### `PutOrAddCommandFailedBecauseTargetAlreadyExists` :::warning Este error no significa necesariamente que la política haya fallado. Aparece cuando Windows intenta agregar un usuario que ya se considera miembro de ese grupo — directa o implícitamente. Por ejemplo, los miembros del grupo de Administradores heredan los permisos del grupo de Usuarios a nivel del SO, por lo que Windows puede reportar este error aunque el usuario no esté incluido explícitamente en el grupo de Usuarios. ::: Para confirmar si la configuración se ha aplicado correctamente, verifica la membresía del grupo directamente en el dispositivo a través de **Administración de equipos → Usuarios y grupos locales → Grupos**. --- ## Modo quiosco multi-app Source: https://docs.applivery.com/es/device-management/windows/policies/multi-app-kiosk-mode/ Description: Configura el modo quiosco multi-app de Windows en Applivery — restringe el acceso del dispositivo a apps específicas usando configuración OMA-URI y XML. TL;DR: Configura el modo Kiosk de múltiples apps en Windows para ejecutar varias aplicaciones aprobadas bajo control estricto usando Applivery. Answers: ¿Qué es el modo quiosco multi-app de Windows? · ¿Cómo creo un usuario quiosco en Applivery? · ¿Cómo habilito el Modo PC Compartido para un quiosco de Windows? · ¿Qué OMA-URI uso para definir el modelo de cuenta en el Modo PC Compartido? · ¿Cómo configuro el acceso asignado para un quiosco multi-app? · ¿Qué define el XML de configuración de Acceso Asignado? · ¿Cómo configuro el inicio de sesión automático para el usuario quiosco? · ¿Dónde configuro una política de quiosco multi-app de Windows en Applivery? El quiosco de Windows en modo Multi-App está diseñado para escenarios donde un dispositivo debe ejecutar más de una aplicación aprobada bajo control estricto. A diferencia de los quioscos tradicionales de una sola app, esta configuración admite múltiples apps mientras aplica restricciones que evitan el uso no autorizado. Los administradores pueden definir el conjunto de apps y gestionar el acceso de los usuarios de forma consistente en todos los dispositivos. Esto garantiza un entorno bloqueado que es seguro y está alineado con los requisitos organizativos. ### Configuración para un quiosco multi-app En el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a **Políticas** 1 y selecciona la política que quieres configurar para un quiosco multi-app. A continuación, en el menú de la izquierda, selecciona **\+ Añadir configuración** 2, busca **Políticas Personalizadas** 3 y luego haz clic en **\+ Añadir Valor** para crear la nueva configuración. ![custom Policies](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/0eb84727-8321-4553-af4c-a3300066ec3e.png) **Crear un usuario quiosco** Usa el siguiente OMA-URI para crear un usuario quiosco: - **OMA-URI**: `./Device/Vendor/MSFT/Accounts/Users/$USERNAME/Password`. Reemplaza la variable `$USERNAME` en el OMA-URI con el nombre de usuario deseado. - **Formato**: String (chr). - **Valor**: Este valor establece la **contraseña** del usuario quiosco. **Habilitar el Modo PC Compartido** Usa el siguiente OMA-URI para habilitar el Modo PC Compartido: - **OMA-URI**: `./Vendor/MSFT/SharedPC/EnableSharedPCMode`. - **Formato**: Boolean (bool). - **Valor**: `true`. Habilita el Modo PC Compartido, optimizando el dispositivo para múltiples usuarios con acceso restringido. **Definir el modelo de cuenta en el Modo PC Compartido** Define el modelo de cuenta en el Modo PC Compartido: - **OMA-URI**: `./Vendor/MSFT/SharedPC/AccountModel`. - **Formato**: Integer (int). - **Valor**: `2` (indica un modo con cuentas desechables o restringidas). **Configurar el Modo de Acceso Asignado** Define la configuración de Acceso Asignado: - **OMA-URI**: `./Vendor/MSFT/AssignedAccess/Configuration`. - **Formato**: String (chr). - **Valor**: ```xml _[App]_ _[App]_ _[App]_ _[App]_ _[App]_ _[App]_ _[App]_ _[App]_ _[Taskbar]_ _[AutoLogonAccount]_ _[DefaultProfile]_ ``` :::note La **Sección de Perfiles** define un perfil con un ID único (`{9A2A490F-10F6-4764-974A-43B19E722C23}`) y especifica una lista blanca de aplicaciones permitidas en ``. Esto incluye apps UWP como Calculadora de Microsoft, Fotos y Bing Weather, así como Apps de escritorio como Símbolo del sistema, PowerShell y Explorador de archivos. Las **restricciones del Explorador de archivos** (`rs5:FileExplorerNamespaceRestrictions`) se aplican para permitir solo el acceso a la carpeta Descargas, mientras se permite el uso de unidades extraíbles. La sección de **Apps ancladas en el menú Inicio** (`v5:StartPins`) define qué aplicaciones aparecen ancladas en el menú Inicio, correspondientes a las apps permitidas. La configuración de la **barra de tareas** está habilitada (`_[Taskbar]_`), garantizando que la barra de tareas sea visible en el modo quiosco. En la **Sección de Configs**, el **Inicio de sesión automático** inicia la sesión del usuario automáticamente, con `$USERNAME` reemplazado por el nombre de usuario real del quiosco. La asignación de perfil establece el perfil definido como predeterminado. Asegúrate de reemplazar `$USERNAME` en el elemento `` con el nombre de usuario del usuario creado anteriormente destinado a este modo quiosco. ::: :::warning **Instalar la app y permitirla son dos cosas distintas.** La política de apps instala la aplicación en el equipo; el XML de Assigned Access decide qué puede lanzar realmente el usuario de quiosco. Una app que se instaló perfectamente sigue siendo inaccesible en modo quiosco si no figura en ``. Es distinto de Android, donde las apps de la política se permiten automáticamente en modo quiosco. En Windows la lista se mantiene por separado, así que cada app nueva hay que añadirla en los dos sitios. ::: --- ## Políticas de contraseña Source: https://docs.applivery.com/es/device-management/windows/policies/password-policy/ Description: Aplica una política de contraseña o PIN y el bloqueo automático de pantalla en dispositivos Windows con la configuración Passcode de Applivery. TL;DR: Activa Device Password Enabled en la configuración Passcode y define longitud, complejidad, caducidad, historial y bloqueo de pantalla para las cuentas locales de Windows. Answers: ¿Qué versiones de Windows admiten la configuración Passcode? · ¿La política de contraseñas se aplica a cuentas de Entra ID o de dominio? · ¿Por qué se ignoran mis reglas de contraseña? · ¿Cómo bloqueo PIN triviales como 1111 o 1234? · ¿Qué valores de complejidad puedo usar en PC con Windows? · ¿Max Device Password Failed Attempts borra el dispositivo? · ¿Cuándo llegan los cambios a los dispositivos? · ¿Puedo desbloquear en remoto una cuenta local bloqueada? Key topics: Configuración Passcode, Longitud, complejidad y caducidad de la contraseña, Historial de contraseñas y bloqueo de pantalla, Revisión de los OMA URIs, Applivery, Windows, Microsoft Entra ID, BitLocker, OMA URI, CSP Aplica una política de contraseña o PIN y el bloqueo automático de pantalla en tus dispositivos Windows con la configuración **Passcode**. ### Requisitos - Windows 10 1507 o posterior, o Windows 11, en cualquier edición. - Las reglas se aplican a **cuentas locales**. Las cuentas de Microsoft Entra ID y de dominio siguen la política de contraseñas de su propio directorio. ### Configurar la política de contraseñas **Crea o abre la política de Windows** En el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a **Políticas** 1. Elige la política en la que quieres agregar esta configuración. En el menú de la izquierda, selecciona **\+ Añadir configuración** 2 y busca **Código de acceso** 3. ![passcode](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/d8c14a62-d92e-4360-9df4-78d9fa8a5f25.png) **Activa el requisito de contraseña** En **Requisitos básicos**: 1. Define **Contraseña del dispositivo habilitada** en **0 Habilitado** . Es el interruptor general: mientras siga en **1 Deshabilitado**, que es el valor por defecto, el resto de reglas del formulario se ignoran. 2. Pon **Permitir contraseña simple del dispositivo** en **0 No permitido** para bloquear PIN triviales como 1111 o 1234, y las contraseñas de imagen en escritorio. ![basic requirements](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/c7f37ecd-6f16-4d61-a100-080daf27ffbd.png) **Define longitud, complejidad y caducidad** 1. **Se requiere una contraseña alfanumérica para el dispositivo**: **0 Se requiere contraseña o PIN alfanumérico.** 2. **Longitud mínima de la contraseña del dispositivo**: 12. El valor por defecto es 4. 3. **Mínimo de caracteres complejos de la contraseña del dispositivo**: **2 Se requiere dígitos y letras minúsculas**. 4. **Caducidad de la contraseña del dispositivo**: 90 días. Déjalo vacío para que la contraseña no caduque. ![other configs](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/65b9dd3c-ed3d-41d1-a5e7-6608e15ddecd.png) El desplegable de complejidad indica qué valores acepta Windows en escritorio. Los valores **3** y **4** aparecen marcados en la propia lista como no soportados para cuentas de escritorio, así que en PC quédate en **1** o **2**. **Configura el historial y el bloqueo de pantalla** Baja hasta el final de **Requisitos básicos** y configura **Bloqueo y desbloqueo**: 1. **Historial de contraseñas del dispositivo**: 5. No se pueden reutilizar las cinco últimas contraseñas. 2. **Tiempo máximo de inactividad para el bloqueo del dispositivo**: 5 minutos. El dispositivo se bloquea y pide la contraseña tras ese tiempo de inactividad. 3. **Máximo de intentos fallidos de contraseña del dispositivo**: 10. En escritorio **no** borra el dispositivo: lo lleva a la recuperación de BitLocker, y solo funciona si [BitLocker](https://docs.applivery.com/es/device-management/windows/policies/deploy-bitlocker/) está activado. ![lock and unlock](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/941ea8eb-164e-4799-8aaf-f2e8d312deb0.png) **Revisa, guarda y asigna** 1. Abre **Resumen** y cambia **Ver resumen como** **OMA URIs** para comprobar los nodos y valores exactos que se enviarán al dispositivo. 2. Haz clic en **Guardar cambios**. Nada llega a los dispositivos hasta que guardas. Si sales de la página antes de guardar, Applivery te pregunta si quieres descartar el borrador. 3. Asigna la política a un dispositivo desde **Dispositivos asignados** haciendo click en **+ Asignar a un dispositivo**, o a un grupo o segmento. ### Qué ve el usuario Si la contraseña actual del usuario no cumple la política, Windows le pide cambiarla en el siguiente inicio de sesión. ### Notas - Microsoft solo documenta **Allow Idle Return Without Password** para HoloLens. - No existe ningún CSP para desbloquear en remoto una cuenta local bloqueada. Esta política solo previene y limita los intentos fallidos. --- ## Habilitar escritorio remoto Source: https://docs.applivery.com/es/device-management/windows/policies/remote-desktop/ Description: Habilita o deshabilita el escritorio remoto en dispositivos Windows usando las políticas de Applivery para una gestión de acceso remoto segura y controlada. TL;DR: Habilita o deshabilita el Escritorio remoto en dispositivos Windows usando políticas de Windows a través del panel de Applivery. Answers: ¿Cómo habilito el escritorio remoto usando las políticas de Applivery? · ¿Cuál es el propósito de configurar el escritorio remoto a través de políticas de Windows? · ¿Dónde encuentro el ajuste de Servicios de escritorio remoto en Applivery? · ¿Qué grupo de usuarios necesita estar configurado para el acceso al escritorio remoto? · ¿Qué puede hacer Applivery para la configuración del escritorio remoto? · ¿Qué ajuste controla el acceso al escritorio remoto en Applivery? · ¿Por qué usar Applivery para gestionar los Servicios de escritorio remoto? La configuración del escritorio remoto a través de las políticas de Windows permite a los administradores proporcionar acceso remoto seguro y controlado a los dispositivos gestionados. Aprovechando los **Servicios de escritorio remoto**, las organizaciones pueden habilitar conexiones remotas para los usuarios del grupo Usuarios de escritorio remoto, garantizando que el personal autorizado pueda acceder a los recursos corporativos de forma eficiente. Applivery simplifica aún más el despliegue y la gestión centralizada de estas configuraciones en flotas de dispositivos Windows, permitiendo a los equipos de TI mantener una seguridad sólida, aplicar las políticas de la empresa y agilizar la resolución remota de problemas. ### Habilitar el escritorio remoto En el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a **Políticas** 1. Elige la política en la que quieres agregar esta configuración. A continuación, en el menú de la izquierda, selecciona **\+ Añadir configuración** 2 y busca **Servicios de escritorio remoto** 3. ![remote desktop services](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/bee093e8-549d-4494-9916-86859c6f66ac.png) Localiza el ajuste **Permitir que los usuarios se conecten de forma remota mediante Servicios de escritorio remoto** y elige habilitarlo o deshabilitarlo según sea necesario. ![allow users to connect remotely by using remote desktop services](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/d29d7ce7-92ae-4887-a1de-53a9052d7a28.png) --- ## Restringir el acceso a dispositivos externos Source: https://docs.applivery.com/es/device-management/windows/policies/restrict-external-device-access/ Description: Protege tus dispositivos Windows restringiendo el acceso a hardware externo. Aprende cómo bloquear unidades USB, controlar la instalación de dispositivos y proteger los datos de la empresa. TL;DR: Aprende a restringir el acceso a dispositivos externos en Windows con Applivery para mejorar la seguridad y prevenir transferencias de datos no autorizadas. Answers: ¿Cómo bloqueo todos los dispositivos de almacenamiento extraíble con Applivery? · ¿Cuál es la forma más sencilla de restringir el acceso a unidades USB con Applivery? · ¿Cómo puedo evitar la instalación de dispositivos externos no autorizados? · ¿Dónde puedo encontrar el GUID de clase para un dispositivo específico? · ¿Cuáles son algunos GUID de clase comunes para dispositivos? · ¿Qué otros métodos ofrece Applivery para controlar la instalación de dispositivos? · ¿Qué ocurre si un dispositivo ya estaba conectado antes de aplicar una política de bloqueo? Los dispositivos externos como unidades USB, discos duros externos y medios portátiles pueden suponer graves riesgos de seguridad en entornos empresariales. Pueden usarse para transferir datos sensibles, introducir malware o eludir los controles de acceso corporativos. Para las organizaciones que gestionan dispositivos Windows a escala, restringir el uso de dispositivos externos es un paso crítico para mantener el cumplimiento y proteger los datos de la empresa. Applivery permite a los administradores de TI aplicar estas restricciones fácilmente a través de la configuración de políticas. Usando los ajustes de directiva de grupo adecuados, puedes bloquear o limitar el acceso a tipos específicos de dispositivos externos en toda tu flota de dispositivos — sin depender de intervención manual. ### Bloquear dispositivos de almacenamiento extraíble **Ir a Políticas** En el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a **Políticas** 1. Elige la política en la que quieres agregar la configuración. **Añadir configuración de Almacenamiento Extraíble** En el menú de la izquierda, selecciona **\+ Añadir configuración** 2 y busca **Almacenamiento Extraíble** 3. ![removable storage](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/daccba2d-3933-4acb-aece-0805f1dc4218.png) **Denegar todo acceso** Localiza la configuración e introduce **Todas las clases de Almacenamiento Extraíble: Denegar todo acceso**. Cuando está habilitado, bloquea el acceso de lectura, escritura y ejecución a todos los dispositivos de almacenamiento extraíble. ![deny all access](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/17a43dac-4f3d-4668-a476-7476f31a35f0.png) ### Bloquear la instalación de dispositivos externos :::info Si el dispositivo estaba conectado antes de que se aplicara la política, no se bloqueará — su controlador ya está instalado. Este enfoque es más complejo y es más adecuado para escenarios avanzados. Si tu objetivo es simplemente bloquear el almacenamiento extraíble, te recomendamos usar la configuración descrita anteriormente. ::: Otra forma de bloquear dispositivos externos es permitir solo la instalación de tipos específicos de dispositivos. **Añadir configuración de Instalación de dispositivos** En el menú de la izquierda, selecciona **\+ Añadir configuración** 4 y busca **Instalación de dispositivos** 5. ![device installation](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/2575d003-d600-475c-911d-8c91aab7efb4.png) **Habilitar ajustes de Instalación de dispositivos** Localiza la configuración relevante y habilita los siguientes dos ajustes: \- **Impedir la instalación de dispositivos no descritos por otras configuraciones de directiva**. \- **Permitir la instalación de dispositivos que usan controladores que coinciden con estas clases de instalación de dispositivos**. Esta combinación bloquea todas las instalaciones de dispositivos excepto las explícitamente permitidas. Para permitir dispositivos específicos, deberás definir sus **Clases de Instalación de dispositivos**, también conocidas como **GUID de Clase**. Puedes encontrarlos en el **Administrador de dispositivos** en una máquina Windows abriendo las propiedades del dispositivo y navegando a la pestaña **Detalles**. ![](https://www.applivery.com/wp-content/uploads/2025/07/image-2.png "class-guids | Applivery") #### GUID de Clase comunes | Tipo de dispositivo | GUID de clase | | --- | --- | | Ratones y teclados | `{4d36e96f-e325-11ce-bfc1-08002be10318}` | | Punto de conexión de audio | `{c166523c-fe0c-4a94-a586-f1a80cfbbf3e}` | | Cámara | `{ca3e7ab9-b4c3-4ae6-8251-579ef933890f}` | | Monitor | `{4d36e96e-e325-11ce-bfc1-08002be10318}` | | Medios (audio y video) | `{4d36e96c-e325-11ce-bfc1-08002be10318}` | ### Otros métodos para controlar la instalación de dispositivos Controlar la instalación de dispositivos no se limita a los GUID de Clase. Applivery también proporciona otras plantillas de configuración para un control más granular: - Bloquear **IDs de dispositivo** específicos (IDs de Hardware). - Permitir solo **IDs de dispositivo** específicos. - Bloquear **Clases de Instalación de dispositivos** completas (GUID de Clase). - Permitir **Clases de Instalación de dispositivos** completas. - Usar **IDs de Instancia de dispositivo**. - Y más… --- ## Scripts Source: https://docs.applivery.com/es/device-management/windows/policies/scripts/ Description: Crea y asigna scripts a dispositivos Windows usando Applivery para la gestión automatizada de tareas y la eficiencia de los procesos de TI. TL;DR: Aprende a automatizar tareas de gestión de dispositivos creando y asignando scripts con Applivery, mejorando la configuración y seguridad de los dispositivos. Answers: ¿Para qué se usan los scripts de ordenador en Applivery? · ¿Cómo creo un nuevo script en Applivery? · ¿Puede Applivery ayudarme a generar scripts con IA? · ¿Cómo asigno un script a un dispositivo en Applivery? · ¿Cuáles son los diferentes métodos de ejecución para los scripts en Applivery? · ¿Cómo puedo pasar argumentos a mis scripts en Applivery? · ¿Cómo sé si un script se ha ejecutado realmente y qué ha devuelto? · ¿Hay scripts predefinidos disponibles para Applivery? Un script de dispositivo es esencialmente una secuencia de instrucciones (comandos) que el dispositivo ejecuta, lo que lo convierte en una excelente herramienta para automatizar tareas repetitivas. Los scripts son altamente escalables y versátiles. Dado que los scripts se pueden desplegar en los dispositivos de los usuarios a través de soluciones de gestión de dispositivos (como Applivery), son invaluables para los equipos de TI. Te permiten realizar tareas complejas de forma rápida, precisa y sencilla: - **Rápidamente**: Usando scripts junto con la gestión de dispositivos móviles, puedes automatizar procesos tediosos. Por ejemplo, puedes acceder a un programa informático en 100 Dispositivos de la empresa con cero clics en lugar de hacerlo manualmente 100 veces. - **Con precisión**: Un script bien escrito ejecutará consistentemente la misma acción definida cada vez, reduciendo el riesgo de errores que podrían ocurrir si un administrador humano realizara la tarea manualmente, lo que puede provocar inconsistencias y confusión. - **Fácilmente**: Puedes lograr tareas complejas y detalladas dividiéndolas en scripts más pequeños y manejables, haciendo el proceso general mucho más sencillo. **Crear tu primer script** Ve al [**panel de Applivery**](https://dashboard.applivery.io/) y navega a **Recursos** 1, luego a la sección **Scripts** 2 y haz clic en **\+ Crear Script** 2. ![scripts](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/734eb61d-eb12-4337-8276-0ff556f5aa0e.png) Aparecerá un editor de código en la pantalla. Dentro del editor, puedes crear un nuevo script o subir uno existente desde tu dispositivo, permitiéndote adaptar fácilmente los scripts a tus necesidades. Para crear un nuevo script, usa la interfaz del editor y empieza a escribir. Primero, selecciona el lenguaje deseado — **PowerShell** 4 en este caso. Para subir un script existente, haz clic en **Cargar desde archivo** 5, selecciona tu script y estará listo para usar. Por último, proporciona un **Nombre** 6 (y opcionalmente una descripción), luego haz clic en **Crear** 7. ![create script](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/2df9cb03-5e86-4876-a7b3-a9f006ffced9.png) :::info Si necesitas ayuda para crear un script, también puedes usar nuestro **Asistente de IA**. Solo haz clic en el botón correspondiente y aparecerá un cuadro de diálogo donde puedes describir el script que necesitas. Nuestro asistente lo generará por ti. ::: :::warning Ten en cuenta que el Asistente de IA es una función premium que puede no estar disponible en tu plan actual. Comprueba la disponibilidad en nuestra [página de precios](https://www.applivery.com/device-management-pricing/). ::: **Asignar scripts a tus dispositivos** Ahora, dirígete a la sección **Dispositivos** 8, elige el dispositivo al que quieres asignar un script, dirígete a la pestaña **Scripts** 9 y haz clic en el botón **\+ Asignar Script** 10. ![assign script](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/2c307f86-abc3-4bbc-9161-99defc7d8e21.png) Aparecerá una vista modal que te permitirá elegir un script de la sección de scripts o cargarlo desde tu dispositivo. También tendrás la opción de seleccionar el método de ejecución y agregar los argumentos del script: - **Una vez**: El script se ejecutará una vez por dispositivo. También tendrás la opción de repetir la ejecución, incluso si ya se ha ejecutado. - **Bucle**: El script se ejecutará de forma cíclica en el intervalo de tiempo elegido. - **Bajo demanda**: El script nunca se ejecutará automáticamente y solo se ofrecerá como elemento opcional desde el Autoservicio. ![script form](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/7dab607d-f8e2-45f2-8d51-66fd4af7777b.png) Haciendo clic en el botón **Historial de ejecución** 11, puedes ver el historial de ejecución de todos tus scripts. También puedes acceder al historial de ejecución de un script específico haciendo clic en el propio script o en los tres puntos verticales al final del script. Al hacer clic en estos puntos también se mostrarán acciones adicionales: - **Editar**: Editar el script. - **Desasignar**: Desasignar el script del dispositivo. - **Ver**: Ver el script original en la sección de recursos. :::warning Para los scripts con el método de ejecución **Una vez**, también verás la opción **Repetir ejecución**. Además de permitir que un script se reintente tras un fallo, esta opción también determina si un script con el mismo ID puede ejecutarse de nuevo en un dispositivo donde ya se ha ejecutado, incluso si esa ejecución tuvo lugar en el pasado. Esto garantiza que el script se enviará de nuevo, independientemente de su historial de ejecución anterior en ese dispositivo. ::: ![script options](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/411511ef-8a8d-4b00-a323-e10420b6f97f.png) **Asignar scripts a tus políticas** Los scripts no tienen por qué asignarse dispositivo a dispositivo. Asignar uno a una política cubre todos los dispositivos a los que se aplica esa política, que es la vía práctica para cualquier cosa que deba ejecutarse en un parque entero en lugar de en una sola máquina. Desde cualquiera de tus **Políticas** 12, ve a la sección **Scripts** 13 del menú lateral izquierdo y haz clic en **\+ Añadir Script** 14. Aparecerá el mismo modal descrito en el paso anterior, con los mismos métodos de ejecución y argumentos. ![assign to policy](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/6d671e51-70d5-43e4-ab44-4e8087c6a3a7.png) Una vez guardes los cambios, los scripts asignados a esa política se desplegarán en todos los dispositivos que la tengan asignada durante su próxima sincronización. ### Argumentos de script Al asignar un script, el campo **Argumentos** te permite pasar parámetros a tu script en el momento de la ejecución. Applivery divide el campo por espacios en blanco, por lo que cada valor separado por espacios se trata como un parámetro independiente. #### Parámetros de varias palabras Si un parámetro contiene espacios, escríbelo entre comillas dobles para que Applivery lo trate como un único valor: ``` --label "Mi Aplicación" ``` Sin las comillas, `Mi` y `Aplicación` se pasarían como dos parámetros separados en lugar de uno. #### Variables interpoladas Applivery admite variables de estilo mustache que se reemplazan en el momento de la ejecución con datos reales del dispositivo o del usuario. Dado que una variable puede expandirse a un valor que contiene espacios, escribe siempre las variables interpoladas entre comillas dobles cuando necesites que se traten como un único parámetro: ``` "{{user.name}}" ``` Si `{{user.name}}` se resuelve como `Juan García`, las comillas garantizan que se pase como un parámetro en lugar de dos. Sin ellas, `Juan` y `García` llegarían a tu script como argumentos separados. Las siguientes variables están disponibles:

Variable

Se resuelve como

{{device.id}}

Identificador único del dispositivo

{{device.displayName}}

Nombre para mostrar del dispositivo

{{device.serialNumber}}

Número de serie del dispositivo

{{device.osVersion}}

Versión del sistema operativo

{{device.chip}}

Tipo de procesador/chip

{{device.hostName}}

Nombre de host del dispositivo

{{user.id}}

Identificador único del usuario asignado

{{user.email}}

Dirección de correo electrónico del usuario asignado

{{user.name}}

Nombre completo del usuario asignado

#### Escapar caracteres especiales Para incluir un carácter especial literalmente en un argumento, precédelo con una barra invertida (`\`). Esto es útil cuando se pasan valores como rutas de Windows o cadenas que contienen comillas dobles: ``` C:\\Program Files\\MyApp ``` Esto pasa `C:\Program Files\MyApp` como valor del argumento. Para incluir una comilla doble literal dentro de un parámetro entre comillas: ``` "He said \"hello\"" ``` * * * ### Revisar qué ha hecho realmente un script Asignar un script le dice al dispositivo qué debe ejecutar. La pestaña **Scripts** de ese dispositivo te dice qué ocurrió cuando lo hizo. Todos los scripts asignados aparecen ahí con sus ajustes y un recuento de sus resultados:

Columna

Qué muestra

Nombre

El nombre del script y su fichero, por ejemplo Restart Device.ps1.

Argumentos

Los argumentos que se le pasan en el momento de la ejecución, si los hay.

Ejecución

Su método de ejecución: Una vez, Bucle con su intervalo configurado, o Bajo demanda.

Ámbito

Si se ejecuta como Machine, con la cuenta SYSTEM, o como el usuario que ha iniciado sesión.

Ejecuciones

Cuántas veces se ha ejecutado en este dispositivo hasta ahora.

Desde

Si viene de una política o se asignó directamente a este dispositivo.

Segmento

El segmento al que pertenece la asignación.

Última fecha

Cuándo se ejecutó por última vez.

Entre **Ejecuciones** y **Última fecha** se suele ver de un vistazo si algo está atascado: un script en bucle cuya última ejecución es de hace días, o uno de tipo Una vez que sigue con cero ejecuciones, es un script que nunca llegó al dispositivo. #### ¿Es un problema de entrega o de ejecución? La pestaña **Scripts** del dispositivo lo responde de un vistazo, con las columnas **Ejecuciones** y **Última fecha**: - **Ejecuciones a cero**: el script nunca llegó al dispositivo. Es un problema de entrega, así que revisa la asignación y la sincronización del dispositivo. - **Ejecuciones con fecha antigua**: sí llegó y se ejecutó, y algo lo dejó atascado después. Cuatro causas cubren la mayoría de los casos: - El método de ejecución **Una vez** no vuelve a ejecutarse en un dispositivo donde ya se ejecutó, salvo que actives **Repetir ejecución**. - El método **Bajo demanda** nunca se ejecuta solo. Solo se lanza desde el Autoservicio. - **Ámbito**: un script que necesite el perfil del usuario falla en silencio si se ejecuta como Machine (SYSTEM), y al revés. - Los **argumentos** se separan por espacios, así que los valores compuestos necesitan comillas dobles. #### Interpretar el historial de ejecución El botón **Historial de ejecución** muestra todas las ejecuciones del dispositivo. Abrirlo desde el menú **⋮** de un script concreto lo acota a ese script, junto con los argumentos y el ámbito con los que se ejecutó. Cada entrada te da: - **Estado**: un círculo verde con un check cuando la ejecución fue correcta, y un triángulo naranja cuando falló. - **Script**: su nombre y su fichero. - **Resumen**: un fragmento de la salida real de consola de esa ejecución, tal cual la imprimió el script. - **Creado**: cuánto hace que se ejecutó. El resumen es la parte a la que merece la pena prestar atención: es la salida de tu propio script, así que lo que imprimas es lo que leerás aquí. Un script que registra una línea clara por cada fase es mucho más fácil de diagnosticar después que uno que se ejecuta en silencio. :::info **Si un script de PowerShell escribe en el flujo de error, el resumen puede mostrar CLIXML en lugar de texto plano**: un marcador `#< CLIXML` seguido de un bloque serializado ``. No es un problema de visualización de Applivery: es el formato nativo de PowerShell para serializar los objetos que se envían al flujo de error. Cuando lo veas, interprétalo como _esta ejecución ha producido salida de error_, y revisa qué parte del script está escribiendo en ese flujo. ::: #### Cambiar cómo se ejecuta un script **Editar**, en ese mismo menú **⋮**, cambia cómo se ejecuta un script ya asignado sin tener que desasignarlo y volver a asignarlo: - **Método de ejecución**: alterna entre Una vez, Bucle y Bajo demanda. - **Tiempo de bucle**: cuando eliges Bucle, cada cuánto se repite. - **Argumentos**: el mismo campo descrito en [Argumentos de script](https://docs.applivery.com/es/device-management/windows/policies/scripts/#argumentos-de-script), variables interpoladas incluidas. ### ¡Hazlo tú mismo! Para ayudar a los administradores a acelerar las configuraciones comunes y las tareas operativas, Applivery proporciona un [Repositorio Público de Scripts](https://github.com/applivery/applivery-mdm-scripts) con scripts de Windows listos para usar. Este repositorio incluye scripts útiles para acciones rápidas y configuraciones estándar, permitiendo a los equipos de TI desplegar soluciones comunes sin tener que crear scripts desde cero. El objetivo de esta iniciativa es **no solo proporcionar recursos reutilizables, sino también fomentar la colaboración**. La comunidad puede contribuir activamente enviando scripts que aborden casos de uso del mundo real, ayudando a expandir y mejorar la biblioteca compartida con el tiempo. Al aprovechar el **Repositorio Público de Scripts**, las organizaciones pueden reducir el tiempo de implementación, estandarizar los procedimientos operativos y beneficiarse de la experiencia colectiva. --- ## Tiempo de espera para suspensión Source: https://docs.applivery.com/es/device-management/windows/policies/sleep-timeout/ Description: Configura el tiempo de espera automático para la suspensión en dispositivos Windows usando las políticas de Applivery para mejorar la seguridad y optimizar la gestión de energía. TL;DR: Configura el tiempo de espera para el modo suspensión en Windows con Applivery para optimizar la gestión de energía y mejorar la seguridad. Controlar los ajustes de gestión de energía es esencial para optimizar el rendimiento del dispositivo, conservar energía y mejorar la seguridad en entornos empresariales. Un ajuste clave es el tiempo de espera de suspensión automático, que determina cuánto tiempo debe permanecer inactivo un dispositivo Windows antes de pasar al modo de suspensión. Con Applivery, los administradores pueden aplicar este comportamiento aplicando una política que especifica el número de segundos de inactividad permitidos antes de que se active la suspensión. Esto garantiza la consistencia en todos los dispositivos gestionados y evita que los usuarios anulen configuraciones críticas de energía o seguridad. ### Configurar el tiempo de espera de suspensión Applivery te permite gestionar los ajustes de energía en Dispositivos Windows usando la política de grupo de configuración de **Energía**. Esto incluye ajustes como la suspensión, el comportamiento en modo sleep y otros controles relacionados con la energía. **Acceder a Gestión de Dispositivos y Políticas** En el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a **Políticas** 1. Elige la política en la que quieres configurar el tiempo de espera de suspensión. **Añadir configuración de Energía** A continuación, en el menú de la izquierda, selecciona **\+ Añadir configuración** y busca **Avanzado** 2. ![advanced](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/1a125879-d4e2-46b0-bf83-3f9f46742507.png) Haz clic en el botón **\+ Añadir sección** y busca la configuración **Energía**. ![add section](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/691ecf5a-310e-4e9e-b5a7-590273703273.png) **Especificar el tiempo de espera de suspensión desatendida** Localiza la configuración **Especificar el tiempo de espera de suspensión desatendida (con batería y enchufado)** e introduce el valor de tiempo de espera deseado en **segundos**. Por ejemplo, para poner el dispositivo en suspensión después de 5 minutos de inactividad, establece el valor en **300 segundos**. ![specify sleep timeout](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/43c3cdb3-db88-470a-a14e-21a6e234e44a.png) ### Añadir solicitud de contraseña al reactivarse Para mejorar la seguridad cuando un dispositivo se reactiva desde la suspensión, puedes combinar el ajuste anterior con la configuración **Requerir una contraseña cuando el equipo se reactive (con batería y enchufado)**. Al habilitar esta política, se pedirá a los usuarios que introduzcan su contraseña cada vez que el dispositivo se reactive desde la suspensión, ya sea con batería o enchufado. Esto garantiza que los dispositivos desatendidos permanezcan seguros después de entrar en suspensión. ![require password](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/c9a64184-3fdb-440d-8aba-697c204e97d0.png) --- ## Configuración del fondo de pantalla Source: https://docs.applivery.com/es/device-management/windows/policies/wallpaper-configuration/ Description: Configura fondos de pantalla personalizados de escritorio y pantalla de bloqueo en dispositivos Windows usando las políticas de Applivery para reforzar la imagen corporativa. TL;DR: Configura fondos de pantalla personalizados en dispositivos Windows de empresa con Applivery para reforzar la imagen y la identidad corporativa. Answers: ¿Cómo configuro un fondo de pantalla de escritorio personalizado en Applivery? · ¿Cómo configuro un fondo de pantalla de pantalla de bloqueo personalizado en Applivery? · ¿Cómo garantizo que los fondos de pantalla personalizados se apliquen de forma consistente? · ¿Por qué no se aplican mis fondos de pantalla personalizados en dispositivos Windows? · ¿Es necesario el ajuste 'Establecer políticas EDU' para todos los dispositivos Windows? · ¿Dónde encuentro la configuración de Personalización en Applivery? · ¿Qué formatos de imagen se admiten para fondos de pantalla personalizados? · ¿Dónde encuentro la configuración de Inicio de sesión en Applivery? Personalizar el fondo de pantalla del escritorio se considera a menudo una forma de reforzar la imagen corporativa en los dispositivos gestionados por la organización. Los ajustes de fondo de pantalla de Windows permiten a las empresas garantizar que cada dispositivo propiedad de la empresa muestre el logotipo o marca de la empresa. Los administradores pueden configurar el fondo de pantalla con el logotipo de la organización o cualquier imagen que elijan y aplicarlo a toda una flota de dispositivos. Esta personalización también les permite establecer fondos de pantalla para todos los usuarios de un dispositivo y decidir si deben actualizarse periódicamente. ### Configurar un fondo de pantalla **Personalización** En el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a **Políticas** 1. Elige la política en la que quieres agregar esta configuración. A continuación, en el menú de la izquierda, selecciona **\+ Añadir configuración** 2 y busca **Personalización** 3. ![personalization](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/c3168606-0bd9-4c16-a9a4-40244e1eda33.png) Localiza los ajustes **URL de imagen del escritorio** y **URL de imagen de la pantalla de bloqueo** para configurar los fondos de pantalla del escritorio y la pantalla de bloqueo. Agrega una URL HTTP o HTTPS que apunte a un archivo de imagen `.jpg`, `.jpeg` o `.png`. ![personalization settings](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/19d42b3c-0143-4454-9dd5-f15cbac32b2f.png) **Inicio de sesión** Ahora, en el menú de la izquierda, selecciona **\+ Añadir configuración** 4 y busca **Inicio de sesión** 5. ![logon](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/3c72db9d-d343-454f-b4fa-5bf083d303de.png) Localiza el ajuste **Usar siempre fondo de inicio de sesión personalizado** y habilítalo para garantizar que los fondos de pantalla de escritorio y pantalla de bloqueo que configures se apliquen de forma consistente. Este ajuste aplica el uso de las imágenes que especifiques, anulando los fondos predeterminados o elegidos por el usuario. ![always use custom logon background](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/f0d79eab-268e-487b-8def-fc635b515931.png) **PC Compartido** Ahora, en el menú de la izquierda, selecciona **\+ Añadir configuración** 6 y busca **PC Compartido** 7. ![shared pc](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/c02a4dc6-177b-4b30-aaa8-a922f5e51398.png) Para garantizar que los fondos de pantalla personalizados de escritorio y pantalla de bloqueo se apliquen correctamente en los dispositivos Windows, debes habilitar el ajuste **Establecer políticas EDU**. Windows aplica las restricciones del fondo de pantalla a través de los controles de política EDU. Si este ajuste no está habilitado, la configuración del fondo de pantalla puede no aplicarse de forma consistente o los usuarios podrían anularla. ![set edu Policies](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/726130a5-eb70-4ffa-8286-59d2e292931d.png) :::info Esta configuración solo es necesaria para dispositivos Windows con **licencias Pro**. ::: --- ## Soporte Remoto Source: https://docs.applivery.com/es/device-management/windows/remote-support/ Description: Soporte remoto para dispositivos Windows gestionados en Applivery: conéctate a un dispositivo a través de TeamViewer sin salir del panel. TL;DR: Habilita TeamViewer Remote en una política de Windows y conéctate a cualquier dispositivo de esa política desde su menú Acción, sin configurar nada en el propio dispositivo. Answers: ¿Cómo controlo remotamente un dispositivo Windows con Applivery? · ¿Applivery es compatible con TeamViewer en Windows? · ¿Cómo inicio una sesión remota en un dispositivo Windows? Key topics: Soporte remoto en Windows, Integración con TeamViewer, Sesiones remotas, Applivery, Windows, TeamViewer El soporte remoto te permite conectarte a un dispositivo Windows gestionado directamente desde el panel de Applivery: para ver lo mismo que la persona que está delante, guiarla paso a paso o resolverlo tú mismo cuando no hay nadie. En Windows, el soporte remoto funciona con **TeamViewer**. Lo habilitas una vez en una política, Applivery instala de forma silenciosa la app TeamViewer Host en todos los dispositivos a los que se aplica esa política, y a partir de ahí inicias las sesiones desde el menú **Acción** del dispositivo. No hay nada que configurar en el propio dispositivo, ni nada que la persona que lo usa tenga que instalar. :::warning Esta es una función premium que puede no estar disponible en tu plan actual. Consulta la disponibilidad en nuestra [página de precios](https://www.applivery.com/device-management-pricing/). ::: --- ## Soporte Remoto con TeamViewer Source: https://docs.applivery.com/es/device-management/windows/remote-support/teamviewer-remote-support/ Description: Habilita el soporte remoto con TeamViewer para dispositivos Windows en Applivery: instalación silenciosa, tipos de sesión, licencias y resolución de problemas. TL;DR: Habilita TeamViewer Remote en una política, deja que Applivery instale TeamViewer Host de forma silenciosa e inicia las sesiones desde el menú Acción del dispositivo. Answers: ¿Cómo habilito TeamViewer en dispositivos Windows con Applivery? · ¿Cómo se contabilizan las licencias de TeamViewer en Applivery? · ¿Por qué mi dispositivo muestra "App not installed"? · ¿Qué diferencia hay entre una sesión atendida y una desatendida? · ¿Puedo conectarme a un dispositivo Windows sin que el usuario acepte? · ¿Qué pasa si una política habilita TeamViewer y otra lo deshabilita? Key topics: Habilitar TeamViewer Remote en una política, Instalación silenciosa de TeamViewer Host, Tipos de sesión y licencias, Resolución de problemas de sesiones remotas, Applivery, TeamViewer, Windows, Agente de Windows :::warning Esta es una función premium que puede no estar disponible en tu plan actual. Consulta la disponibilidad en nuestra [página de precios](https://www.applivery.com/device-management-pricing/). ::: Al habilitar **TeamViewer Remote** en una política de Windows, Applivery instala de forma silenciosa la app TeamViewer Host en todos los dispositivos a los que se aplica esa política, y los registra en TeamViewer. A partir de ahí, inicias una sesión remota desde el menú **Acción** del dispositivo: sin configurar nada en el propio dispositivo, y sin que la persona que lo usa tenga que instalar ni aceptar nada de antemano. :::info También disponible en macOS. Consulta [Soporte remoto con TeamViewer para macOS](https://docs.applivery.com/es/device-management/apple/macos/remote-support/teamviewer-remote-support/). ::: ### Antes de empezar TeamViewer Remote depende del [agente de Windows](https://docs.applivery.com/es/device-management/windows/policies/agent/): el agente es lo que instala y registra TeamViewer Host en el dispositivo. Antes de habilitar la política, asegúrate de que el segmento del dispositivo tiene el **Agente Self-Service de Windows** habilitado, **con los scripts habilitados**: la instalación de TeamViewer Host se entrega como un script que ejecuta el agente. Si falta cualquiera de los dos, la función no funcionará aunque la política esté en **Activado**. El propio aviso de la política enlaza directamente a los ajustes del agente de ese segmento, así que puedes comprobarlo sin salir de la página. ### Habilitar TeamViewer Remote **Abrir la política** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a **Políticas** 1 y abre la política en la que quieres habilitar el soporte remoto. **Ir a la sección TeamViewer Remote** En el menú lateral izquierdo, selecciona la sección **TeamViewer Remote** y busca la configuración **TeamViewer Remote** 2. **Ponerlo en Enabled** Elige **Activado** y guarda los cambios. Todos los dispositivos a los que se aplica esa política recibirán ahora TeamViewer Host de forma automática. ![enable teamviewer](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/98604492-1eba-4788-abb7-62daec53ab16.png) #### Los tres estados de configuración TeamViewer Remote usa el patrón **No configurado / Activado / Desactivado**. Esto importa porque un dispositivo puede tener [más de una política aplicada](https://docs.applivery.com/es/device-management/general-settings/policy-composition/): lo que llega realmente al dispositivo es el resultado compuesto de todas las políticas de su conjunto, no el valor de ninguna en concreto. Así que cada estado es, en realidad, lo que *esta* política aporta a esa composición:

Estado

Qué aporta esta política

Activado

Activa TeamViewer Remote. Se instala TeamViewer Host, el dispositivo se registra en TeamViewer y consume una licencia de tu pool

Desactivado

Desactiva TeamViewer Remote. Todo dispositivo que acabe sin la función activa se da de baja en TeamViewer y su licencia vuelve al pool

No configurado

No aporta nada. Esta política se mantiene al margen de la decisión, y el resultado lo determinan las demás políticas del conjunto

#### Qué política prevalece Las políticas se evalúan de forma **secuencial**, en el orden que marca su prioridad dentro de la composición. La primera política que fija un valor decide el resultado: `No configurado` se salta, y ninguna política posterior sobrescribe un valor que ya se ha fijado. Dicho de otro modo, ni `Activado` ni `Desactivado` gana al otro: **lo que decide es el orden**. Así queda en un dispositivo con dos políticas, donde la política 1 se evalúa primero:

Política 1

Política 2

Resultado compuesto

No configurado

Activado

Activado: la política 1 no fija nada, así que decide la política 2

Desactivado

Activado

No activo: la política 1 ha llegado antes, y la política 2 no la sobrescribe

Activado

Desactivado

Activado: la misma regla al revés, la política 1 ha llegado antes

Usa **No configurado** cuando una política no tenga por qué decidir sobre el soporte remoto, por ejemplo una que solo despliega apps. Usa **Desactivado** cuando quieras que una política mantenga el soporte remoto desactivado de forma activa, y comprueba que se evalúa **antes** que cualquier política que lo habilite, o no tendrá ningún efecto. #### Instalación automática Applivery despliega TeamViewer Host de forma silenciosa: la persona que usa el dispositivo no tiene que hacer nada, y no se le pedirá que apruebe nada. El dispositivo aparece como **Listo** en cuanto la app ha recogido su configuración, lo que suele tardar unos minutos. #### Cómo se contabilizan las licencias Cada dispositivo con TeamViewer Remote activo en su configuración compuesta consume una licencia de TeamViewer de tu plan, **se conecte alguien a él o no**. Lo que cuenta es el número de dispositivos con la función activa, no el número de sesiones que abres. En cuanto un dispositivo deja de tener TeamViewer Remote activo a través de sus políticas, **se da de baja en TeamViewer y su licencia se libera** automáticamente. Da igual cómo haya cambiado la composición: poner una política en **Desactivado**, quitar la política que lo habilitaba o mover el dispositivo a otro sitio tienen el mismo efecto. ### Iniciar una sesión remota **Abrir el dispositivo** Dirígete a cualquiera de tus **dispositivos** Windows y haz clic en el botón **Acción** 1. **TeamViewer Remote** 2 es la primera opción del menú. ![action button](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/a24909c2-e4a6-402a-9dd8-9272ff9b32fe.png) **Elegir cómo quieres conectarte** Se abre la ventana **TeamViewer Remote Support**. Elige el **Tipo de control** y la opción **Abrir con** para esta sesión 3. ![controls](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/82cf4d74-3a88-4f31-858b-02887ff88071.png) **Iniciar la sesión** Haz clic en **Iniciar sesión remota**. Si has elegido **Cliente de TeamViewer**, la sesión se entrega a la app de escritorio de TeamViewer de tu equipo, que se conecta al dispositivo. ![connecting](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/d4eed369-134b-4f38-9c7c-4acca27d3eb4.png) El tipo de sesión no se fija al habilitar la política: todas las opciones están disponibles siempre, y eliges en cada sesión.

Ajuste

Opciones

Tipo de control

Desatendido: se conecta sin que nadie tenga que aceptar en el dispositivo, para equipos que no está usando nadie. Atendido: alguien en el dispositivo tiene que aceptar la sesión entrante. View only: alguien en el dispositivo también tiene que aceptar, y tú ves la pantalla sin que se envíe ninguna entrada de teclado ni de ratón

Abrir con

Pestaña nueva: se ejecuta en el cliente web de TeamViewer, sin instalar nada en tu equipo. Cliente de TeamViewer: entrega la sesión a la app de escritorio de TeamViewer, con todas sus funciones

Puedes cambiar de opción tantas veces como quieras antes de hacer clic en **Iniciar sesión remota**: el valor que se muestra al hacer clic es el que se usa. #### Qué puedes hacer durante una sesión Una vez conectado, TeamViewer te ofrece portapapeles compartido, pantalla en negro, transferencia de archivos, chat, llamada de audio, realidad aumentada, reinicio remoto, grabación de pantalla y la posibilidad de dejar notas al usuario. En el propio dispositivo gestionado, TeamViewer Host aparece instalado junto al agente de Applivery: los dos los ha puesto ahí la instalación automática descrita más arriba. ![teamviewer next to agent](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/c25a6bcc-3d9a-4899-a30d-5f51d1358ed7.png) ### Resolución de problemas La ventana **TeamViewer Remote Support** muestra una etiqueta de estado junto al dispositivo, para que sepas de un vistazo si se puede iniciar una sesión. Pasa el ratón por el icono ⓘ que hay al lado para ver una explicación breve. #### Listo TeamViewer Host está instalado y configurado en el dispositivo. Puedes iniciar una sesión. #### No activado en la política La política asignada al dispositivo no tiene TeamViewer Remote en **Activado**. Vuelve a [Habilitar TeamViewer Remote](#habilitar-teamviewer-remote) y comprueba que estás editando la política a la que ese dispositivo está realmente asignado. ![not enabled in policy](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/42d327ef-ab9f-4377-bf34-f99df4c40ae9.png) #### App no instalada La política está habilitada, pero TeamViewer Host todavía no ha terminado de instalarse en ese dispositivo o no ha podido. Como la instalación es silenciosa y puede tardar unos minutos, espera y vuelve a intentarlo. Si persiste, comprueba que el segmento del dispositivo cumple de verdad el [requisito del agente y los scripts](#antes-de-empezar). Es con diferencia la causa más habitual, porque la instalación se entrega mediante un script que ejecuta el agente. ![app not installed](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/9961af89-b34b-49cb-a708-e04b0ce736f0.png) Iniciar una sesión contra un dispositivo en este estado falla, elijas el Tipo de control y el Abrir con que elijas. #### El dispositivo se desconecta a mitad de sesión Si el dispositivo se desconecta justo después de hacer clic en **iniciar sesión remota**, la ventana de la sesión remota se cierra sola. Espera a que el dispositivo vuelva a estar en línea e inicia una sesión nueva. #### No pasa nada al hacer clic en Iniciar sesión remota Dale un momento antes de volver a hacer clic: un doble clic en **Iniciar sesión remota** no abre dos sesiones, así que pulsar otra vez no acelera nada. --- ## Resolución de problemas Source: https://docs.applivery.com/es/device-management/windows/troubleshooting/ Description: Resuelve problemas comunes de Gestión de Dispositivos Windows en Applivery — soluciona problemas de inscripción, errores de sincronización de configuración, problemas de despliegue de apps y conflictos de configuración. Answers: ¿Cómo resuelvo problemas de inscripción de Windows en Applivery? · ¿Qué hago si las políticas no se sincronizan en un dispositivo Windows? · ¿Cómo soluciono problemas de despliegue de apps en dispositivos Windows? · ¿Cómo soluciono conflictos de configuración en dispositivos Windows gestionados? Diagnostica y resuelve problemas comunes de la Gestión de Dispositivos Windows en Applivery — incluyendo fallos de inscripción, errores de sincronización de políticas, problemas de despliegue de apps y conflictos de configuración. Cada artículo explica la causa probable y los pasos para resolverlo, para que puedas volver a gestionar los dispositivos sin escalar al soporte. --- ## Android Enterprise Source: https://docs.applivery.com/es/glossary/android-enterprise/ Description: Android Enterprise ofrece múltiples modos de implementación, incluidos perfiles de trabajo, dispositivos totalmente administrados y dispositivos dedicados para satisfacer diversas necesidades comerciales. TL;DR: Android Enterprise explicado para casos de uso de administración de dispositivos y distribución de aplicaciones empresariales. Android Enterprise reemplazó a Android for Work en 2017, introduciendo la inscripción sin intervención y funciones de seguridad mejoradas para implementaciones empresariales. --- ## AOSP (Proyecto de código abierto de Android) Source: https://docs.applivery.com/es/glossary/aosp/ Description: En movilidad empresarial, la administración AOSP permite el control de políticas y aplicaciones en dispositivos Android sin Google utilizados en escenarios industriales, de quiosco y resistentes. TL;DR: Los dispositivos AOSP se pueden administrar en flotas empresariales incluso cuando los servicios de Google no están disponibles. AOSP es especialmente relevante para operaciones logísticas, minoristas y de campo donde los dispositivos resistentes priorizan el control, la durabilidad y la gestión sin conexión a los servicios de Google para el consumidor. --- ## Análisis de aplicaciones Source: https://docs.applivery.com/es/glossary/app-analytics/ Description: Los análisis de aplicaciones brindan información procesable sobre el comportamiento del usuario para tomar decisiones basadas en datos sobre la calidad, la experiencia del usuario y la distribución de la aplicación. TL;DR: App Analytics explicado para casos de uso de administración de dispositivos y distribución de aplicaciones empresariales. La integración con plataformas de análisis permite el seguimiento de métricas de distribución, tasas de adopción y correlación entre los métodos de implementación y la participación de los usuarios. --- ## Catálogo de aplicaciones Source: https://docs.applivery.com/es/glossary/app-catalog/ Description: Los catálogos de aplicaciones agilizan el descubrimiento y la implementación de aplicaciones, brindando a los usuarios acceso a aplicaciones verificadas y compatibles, manteniendo al mismo tiempo la seguridad y la gobernanza. TL;DR: Catálogo de aplicaciones explicado para casos de uso de administración de dispositivos y distribución de aplicaciones empresariales. Los catálogos de aplicaciones empresariales reducen la carga de trabajo de TI al permitir a los usuarios instalar aplicaciones aprobadas bajo demanda mientras mantienen el control y el seguimiento centralizados. --- ## Ajuste de aplicaciones Source: https://docs.applivery.com/es/glossary/app-wrapping/ Description: El empaquetado de aplicaciones permite a las organizaciones agregar controles de seguridad, prevención de pérdida de datos y funciones de cumplimiento a aplicaciones heredadas o de terceros. TL;DR: App Wrapping explicado para casos de uso de administración de dispositivos y distribución de aplicaciones empresariales. El ajuste de aplicaciones es particularmente útil para extender las capacidades de MDM a aplicaciones que no admiten de forma nativa las API de administración empresarial. --- ## Reglas de automatización Source: https://docs.applivery.com/es/glossary/automation-rules/ Description: Las reglas de automatización reducen las operaciones manuales al vincular los estados del dispositivo y las condiciones de la audiencia con acciones de respuesta predefinidas. TL;DR: Las reglas de automatización desencadenan acciones de gestión automáticamente según las condiciones. Las reglas de automatización son clave para mantener la coherencia en flotas grandes donde la ejecución manual de tareas de gestión repetitivas no es sostenible. --- ## Pruebas beta Source: https://docs.applivery.com/es/glossary/beta-testing/ Description: Los programas de prueba beta permiten una distribución controlada a grupos de usuarios específicos, proporcionando información valiosa que mejora la calidad de la aplicación y la experiencia del usuario. TL;DR: Pruebas Beta explicadas para casos de uso de administración de dispositivos y distribución de aplicaciones empresariales. Las pruebas beta exitosas combinan una selección de usuarios específica, mecanismos de retroalimentación claros y ciclos de lanzamiento iterativos para perfeccionar las aplicaciones antes del lanzamiento de producción. --- ## BYOD (Traiga su propio dispositivo) Source: https://docs.applivery.com/es/glossary/byod/ Description: Los programas BYOD equilibran la flexibilidad del usuario con la seguridad corporativa a través de la contenedorización, capacidades de borrado selectivo y aplicación de políticas. TL;DR: BYOD (Traiga su propio dispositivo) explicado para casos de uso de administración de dispositivos y distribución de aplicaciones empresariales. Las implementaciones efectivas de BYOD utilizan perfiles de trabajo o contenedores para aislar los datos corporativos respetando al mismo tiempo la privacidad de los empleados en los dispositivos personales. --- ## Gestión de certificados Source: https://docs.applivery.com/es/glossary/certificate-management/ Description: La gestión adecuada de certificados garantiza que las aplicaciones puedan distribuirse y ser confiables, que los dispositivos puedan autenticarse de forma segura y que las comunicaciones permanezcan cifradas y verificadas. TL;DR: Gestión de certificados explicada para casos de uso de distribución de aplicaciones empresariales y gestión de dispositivos. La gestión de certificados empresariales incluye perfiles de aprovisionamiento para iOS, claves de firma para Android y certificados SSL/TLS para comunicaciones seguras. --- ## CI/CD (Integración continua/Implementación continua) Source: https://docs.applivery.com/es/glossary/ci-cd/ Description: Las canalizaciones CI/CD automatizan la creación, prueba e implementación de aplicaciones, lo que garantiza ciclos de iteración rápidos y una calidad constante en todas las versiones. TL;DR: CI/CD (Integración continua/Implementación continua) explicado para casos de uso de administración de dispositivos y distribución de aplicaciones empresariales. Los flujos de trabajo modernos CI/CD se integran con plataformas de distribución de aplicaciones para implementar automáticamente compilaciones para probadores beta y usuarios de producción una vez que pasan los controles de calidad. --- ## Enlace profundo Source: https://docs.applivery.com/es/glossary/deep-linking/ Description: Los enlaces profundos mejoran la experiencia del usuario al permitir la navegación directa al contenido de la aplicación desde fuentes externas como correos electrónicos, sitios web o notificaciones automáticas. TL;DR: Deep Linking explicado para casos de uso de administración de dispositivos y distribución de aplicaciones empresariales. Los enlaces profundos son esenciales para la atribución de instalaciones, las campañas de reactivación y la creación de recorridos de usuario fluidos en plataformas web y móviles. --- ## Audiencias de dispositivos Source: https://docs.applivery.com/es/glossary/device-audiences/ Description: Las audiencias de dispositivos permiten a los administradores automatizar la gestión a escala aplicando configuraciones y flujos de trabajo a los dispositivos coincidentes. TL;DR: Las audiencias de dispositivos automatizan la orientación de políticas agrupando dispositivos mediante reglas. Las audiencias de dispositivos reducen la administración manual y mejoran la coherencia al garantizar que las políticas y acciones estén alineadas automáticamente con el estado y los atributos actuales del dispositivo. --- ## Cumplimiento del dispositivo Source: https://docs.applivery.com/es/glossary/device-compliance/ Description: El monitoreo del cumplimiento garantiza que los dispositivos mantengan las posturas de seguridad requeridas, restringiendo automáticamente el acceso a los recursos corporativos cuando se detectan violaciones. TL;DR: Device Compliance explicado para casos de uso de administración de dispositivos y distribución de aplicaciones empresariales. Los dispositivos que no cumplen con las normas se pueden poner en cuarentena automáticamente o borrarse de forma remota, protegiendo los datos de la organización de los puntos finales comprometidos. --- ## Inscripción de dispositivos Source: https://docs.applivery.com/es/glossary/device-enrollment/ Description: La inscripción de dispositivos establece una conexión segura entre un dispositivo y la infraestructura de administración, lo que permite la configuración y políticas remotas. TL;DR: La inscripción de dispositivos crea una conexión segura entre un dispositivo y la infraestructura de administración para la configuración remota y la aplicación de políticas. Key topics: Inscripción de dispositivos, Conexión segura, Configuración remota, Aplicación de políticas, MDM La inscripción de dispositivos establece una conexión segura entre un dispositivo y la infraestructura de administración, lo que permite la configuración remota y la aplicación de políticas. --- ## Distribución de aplicaciones Source: https://docs.applivery.com/es/glossary/distribucion-de-apps/ Description: La distribución de aplicaciones abarca todo el ciclo de vida, desde la carga de la compilación hasta la instalación del usuario, incluidas las pruebas, la preparación y las implementaciones de producción. TL;DR: Distribución de aplicaciones explicada para casos de uso de administración de dispositivos y distribución de aplicaciones empresariales. Las estrategias eficaces de distribución de aplicaciones equilibran la seguridad, la accesibilidad y la experiencia del usuario, ofreciendo múltiples canales para llegar a diferentes audiencias y casos de uso. --- ## Ficha de inscripción Source: https://docs.applivery.com/es/glossary/enrollment-token/ Description: Los tokens de inscripción simplifican los flujos de trabajo de aprovisionamiento y al mismo tiempo controlan quién puede inscribir dispositivos y bajo qué condiciones. TL;DR: Los tokens de inscripción protegen y agilizan los flujos de trabajo de incorporación de dispositivos. Los tokens de inscripción ayudan a las organizaciones a estandarizar la incorporación y, al mismo tiempo, reducen el riesgo de eventos de inscripción no autorizados. --- ## FileVault Source: https://docs.applivery.com/es/glossary/filevault/ Description: FileVault ayuda a las organizaciones a aplicar la protección y el cumplimiento de los datos de los terminales al evitar el acceso no autorizado sin conexión a los datos del dispositivo. TL;DR: FileVault cifra el almacenamiento de macOS para proteger los datos empresariales confidenciales. FileVault es un control básico en muchos marcos de seguridad porque reduce significativamente el riesgo de exposición a dispositivos perdidos o robados. --- ## Proveedor de identidad (IdP) Source: https://docs.applivery.com/es/glossary/identity-provider/ Description: Los proveedores de identidad impulsan SSO y la federación centralizando la autenticación, las políticas de acceso y los controles del ciclo de vida del usuario. TL;DR: Los proveedores de identidad centralizan el inicio de sesión y la aplicación de políticas de acceso en todas las aplicaciones. Los proveedores de identidad mejoran la postura de seguridad al consolidar el inicio de sesión, reducir la dispersión de credenciales locales y permitir la aplicación consistente de políticas en todas las plataformas integradas. --- ## Modo quiosco Source: https://docs.applivery.com/es/glossary/kiosk-mode/ Description: El modo quiosco es ideal para dispositivos de uso dedicado, como terminales de punto de venta, señalización digital, escáneres de inventario o tabletas orientadas al cliente. TL;DR: Modo quiosco explicado para casos de uso de administración de dispositivos y distribución de aplicaciones empresariales. Las configuraciones de quiosco pueden variar desde el modo de una sola aplicación hasta el modo de múltiples aplicaciones con cambio controlado de aplicaciones, según los requisitos comerciales. --- ## LDAP (Protocolo ligero de acceso a directorios) Source: https://docs.applivery.com/es/glossary/ldap/ Description: La integración LDAP permite a las organizaciones reutilizar credenciales de directorio y grupos para inicio de sesión, control de acceso y sincronización de usuarios. TL;DR: LDAP centraliza el acceso a la identidad y comúnmente se integra en los flujos de autenticación empresarial. LDAP se usa a menudo junto con SSO y el mapeo de roles para imponer un acceso de usuario consistente y permisos basados ​​en grupos en todas las aplicaciones empresariales. --- ## Gestión de aplicaciones móviles (MAM) Source: https://docs.applivery.com/es/glossary/mam/ Description: MAM permite un control granular sobre aplicaciones individuales (acceso a datos, permisos para compartir y autenticación) sin una administración completa del dispositivo. TL;DR: Gestión de aplicaciones móviles (MAM) explicada para casos de uso de administración de dispositivos y distribución de aplicaciones empresariales. MAM es particularmente valioso para BYOD escenarios donde los usuarios desean aplicaciones corporativas en dispositivos personales sin ceder el control total del dispositivo a TI. --- ## Managed Google Play Source: https://docs.applivery.com/es/glossary/managed-google-play/ Description: Managed Google Play se integra con las plataformas Android Enterprise y EMM/UEM para proporcionar una implementación de aplicaciones segura y basada en políticas. TL;DR: Managed Google Play es la ruta empresarial controlada para la distribución de aplicaciones de Android. Managed Google Play es un componente central de la movilidad empresarial de Android porque combina la disponibilidad de aplicaciones, el control de versiones y la aplicación de políticas en un único canal administrado. --- ## Gestión de dispositivos móviles (MDM) Source: https://docs.applivery.com/es/glossary/mdm/ Description: MDM proporciona control centralizado sobre las configuraciones, políticas y aplicaciones de dispositivos, lo que garantiza el cumplimiento y la seguridad en toda la flota de una organización. TL;DR: Administración de dispositivos móviles (MDM) explicada para casos de uso de administración de dispositivos y distribución de aplicaciones empresariales. La administración de dispositivos móviles (MDM) es una metodología y un conjunto de herramientas probados que se utilizan para proporcionar a la fuerza laboral herramientas y aplicaciones de productividad móviles mientras se mantienen seguros los datos corporativos. --- ## OEMConfig Source: https://docs.applivery.com/es/glossary/oemconfig/ Description: OEMConfig estandariza controles avanzados de proveedores, para que los administradores puedan configurar funciones del fabricante sin integraciones EMM personalizadas. TL;DR: OEMConfig expone la configuración avanzada del fabricante de dispositivos de forma escalable para la administración empresarial de Android. OEMConfig es fundamental para implementaciones de Android resistentes y especializadas donde los equipos empresariales necesitan controles de hardware granulares más allá de las políticas básicas de administración de Android. --- ## Por aire (OTA) Source: https://docs.applivery.com/es/glossary/ota/ Description: Las actualizaciones OTA permiten una implementación perfecta de versiones de aplicaciones y actualizaciones del sistema, lo que mejora las tasas de adopción y reduce la fricción en el proceso de actualización. TL;DR: Over-the-Air (OTA) explicado para casos de uso de administración de dispositivos y distribución de aplicaciones empresariales. La tecnología OTA es fundamental para la gestión moderna de dispositivos móviles, ya que permite una rápida implementación de actualizaciones críticas y parches de seguridad en flotas de dispositivos distribuidos. --- ## OTP (Contraseña de un solo uso) Source: https://docs.applivery.com/es/glossary/otp/ Description: El acceso basado en OTP proporciona autenticación temporal controlada sin requerir cuentas de usuario permanentes, que a menudo se usa para colaboradores externos o flujos de acceso seguros a corto plazo. TL;DR: OTP permite la autenticación temporal de un solo uso para un acceso seguro y controlado. La autenticación OTP es útil cuando las organizaciones necesitan otorgar acceso seguro a usuarios que no tienen cuentas completas y, al mismo tiempo, mantener controles de vencimiento y auditabilidad. --- ## PPPC (Control de política de preferencias de privacidad) Source: https://docs.applivery.com/es/glossary/pppc/ Description: Los perfiles PPPC permiten a los administradores aprobar previamente o denegar permisos de privacidad para reducir las solicitudes y hacer cumplir la política de seguridad a escala. TL;DR: Los perfiles PPPC controlan los permisos de aplicaciones confidenciales en dispositivos macOS administrados. PPPC se usa ampliamente en implementaciones empresariales de macOS para mantener estrictos los controles de seguridad y al mismo tiempo evitar solicitudes excesivas de permisos del usuario. --- ## Aprovisionamiento Source: https://docs.applivery.com/es/glossary/provisioning/ Description: El aprovisionamiento automatiza la configuración de dispositivos y aplicaciones, lo que garantiza una configuración coherente en toda la organización y reduce la carga de trabajo manual de TI. TL;DR: Explicación del aprovisionamiento para casos de uso de administración de dispositivos y distribución de aplicaciones empresariales. Las soluciones de aprovisionamiento modernas permiten una implementación sin intervención, donde los dispositivos se pueden configurar automáticamente en el primer arranque sin intervención manual de TI. --- ## Notificaciones push Source: https://docs.applivery.com/es/glossary/push-notifications/ Description: Las notificaciones push permiten la comunicación en tiempo real con usuarios y dispositivos — mensajes de cara al usuario y comandos silenciosos en segundo plano para la administración. TL;DR: Notificaciones push explicadas para casos de uso de administración de dispositivos y distribución de aplicaciones empresariales. Los sistemas MDM aprovechan las notificaciones automáticas para activar actualizaciones inmediatas de políticas, iniciar comandos de borrado remoto o notificar a los usuarios sobre violaciones de cumplimiento. --- ## Limpieza remota Source: https://docs.applivery.com/es/glossary/remote-wipe/ Description: El borrado remoto es una característica de seguridad que previene las filtraciones de datos al eliminar información corporativa de los dispositivos comprometidos o fuera de servicio. TL;DR: Remote Wipe explicado para casos de uso de administración de dispositivos y distribución de aplicaciones empresariales. Las soluciones modernas MDM ofrecen eliminación selectiva para eliminar solo datos y aplicaciones corporativas y al mismo tiempo preservar la información personal en los dispositivos BYOD. --- ## SAML (Lenguaje de marcado de afirmación de seguridad) Source: https://docs.applivery.com/es/glossary/saml/ Description: SAML permite el inicio de sesión único empresarial al delegar la autenticación a un sistema de identidad confiable y pasar afirmaciones de identidad firmadas a las aplicaciones. TL;DR: SAML permite el inicio de sesión federado pasando afirmaciones de identidad firmadas entre las plataformas de identidad y aplicación. SAML se usa comúnmente en arquitecturas de identidad empresarial para centralizar la autenticación y reducir la dispersión de contraseñas, preservando al mismo tiempo un control de acceso seguro basado en políticas. --- ## SCIM (Sistema de gestión de identidad entre dominios) Source: https://docs.applivery.com/es/glossary/scim/ Description: SCIM mantiene los datos de la cuenta sincronizados en todos los sistemas creando, actualizando y desactivando usuarios automáticamente, lo que reduce la administración manual de identidades. TL;DR: SCIM automatiza el aprovisionamiento de usuarios y grupos en plataformas de aplicaciones e identidades. SCIM comúnmente se combina con SSO para brindar autenticación y administración automatizada del ciclo de vida de la cuenta, lo que garantiza que los usuarios y grupos permanezcan alineados entre los proveedores de identidad y las aplicaciones posteriores. --- ## Segmentos Source: https://docs.applivery.com/es/glossary/segments/ Description: En la administración de dispositivos, los segmentos ayudan a delegar la administración y aislar dispositivos, políticas y permisos según los límites organizacionales. TL;DR: Los segmentos dividen el alcance de la gestión para mejorar la delegación, el control y la seguridad. Los segmentos son especialmente útiles en organizaciones de varios equipos donde la seguridad y la propiedad operativa deben separarse sin duplicar la infraestructura. --- ## Cuentas de servicio Source: https://docs.applivery.com/es/glossary/service-accounts/ Description: Las cuentas de servicio admiten CI/CD y flujos de trabajo de integración al proporcionar credenciales revocables y con alcance independientes de las cuentas de usuario personales. TL;DR: Las cuentas de servicio brindan autenticación segura de máquina a máquina para flujos de trabajo automatizados. El uso de cuentas de servicio en lugar de credenciales de usuario mejora la seguridad, la trazabilidad y la continuidad operativa de los flujos de trabajo de integración e implementación. --- ## Carga lateral Source: https://docs.applivery.com/es/glossary/sideloading/ Description: La descarga permite la implementación de aplicaciones empresariales, pruebas beta y flujos de trabajo de desarrollo sin necesidad de aprobación de la tienda de aplicaciones pública. TL;DR: Descarga lateral explicada para casos de uso de administración de dispositivos y distribución de aplicaciones empresariales. Si bien la descarga es esencial para la movilidad empresarial, requiere una gestión de certificados adecuada y medidas de seguridad para evitar instalaciones de aplicaciones no autorizadas. --- ## Atributos inteligentes Source: https://docs.applivery.com/es/glossary/smart-attributes/ Description: Los atributos inteligentes enriquecen los datos de inventario de dispositivos sin procesar con un contexto procesable, lo que permite una orientación precisa y una orquestación de políticas. TL;DR: Los atributos inteligentes mejoran la precisión de la orientación al agregar contexto dinámico a los datos del dispositivo. Los atributos inteligentes son fundamentales para la automatización avanzada porque permiten que las políticas y los flujos de trabajo reaccionen al contexto real del dispositivo en lugar de a una agrupación estática. --- ## Inicio de sesión único (SSO) Source: https://docs.applivery.com/es/glossary/sso/ Description: SSO centraliza la autenticación y reduce la fatiga de las contraseñas al tiempo que mejora la seguridad, la gestión del acceso y la incorporación de usuarios en todos los sistemas empresariales. TL;DR: SSO permite a los usuarios iniciar sesión una vez y acceder de forma segura a múltiples aplicaciones empresariales. El inicio de sesión único (SSO) mejora la experiencia del usuario y fortalece la seguridad al enrutar la autenticación a través de un proveedor de identidad central, lo que permite una aplicación consistente de políticas y una administración de acceso más simple. --- ## TestFlight Source: https://docs.applivery.com/es/glossary/testflight/ Description: TestFlight proporciona una forma simplificada de recopilar comentarios, realizar un seguimiento de los fallos y validar la funcionalidad de la aplicación antes de enviarla a la App Store. TL;DR: TestFlight explicado para casos de uso de administración de dispositivos y distribución de aplicaciones empresariales. TestFlight se integra con App Store Connect y admite hasta 10 000 evaluadores externos por aplicación, lo que lo hace esencial para los flujos de trabajo de desarrollo de aplicaciones iOS. --- ## Autenticación de dos factores (2FA) Source: https://docs.applivery.com/es/glossary/two-factor-authentication/ Description: 2FA reduce el riesgo de comprometer la cuenta al agregar una segunda prueba más allá de las contraseñas, como códigos OTP, aplicaciones de autenticación o claves de hardware. TL;DR: 2FA agrega una segunda capa de verificación para reducir el acceso no autorizado a la cuenta. La autenticación de dos factores es un control esencial en entornos empresariales para mitigar el robo de credenciales y reducir el impacto de la reutilización de contraseñas. --- ## Gestión unificada de terminales (UEM) Source: https://docs.applivery.com/es/glossary/uem/ Description: UEM centraliza políticas, seguridad, entrega de aplicaciones y operaciones del ciclo de vida en diversos sistemas operativos y tipos de dispositivos. TL;DR: UEM consolida la administración de terminales en dispositivos móviles, de escritorio y especializados. UEM va más allá de la gestión móvil tradicional al combinar seguridad de endpoints, gobernanza de políticas y herramientas operativas en una sola estrategia de gestión empresarial. --- ## Audiencias de usuarios Source: https://docs.applivery.com/es/glossary/user-audiences/ Description: Las audiencias de usuarios respaldan la distribución automatizada y el control de acceso mediante la asignación de publicaciones y permisos a los usuarios que coinciden con los criterios definidos. TL;DR: Las audiencias de usuarios automatizan la orientación a nivel de usuario para el acceso y distribución de aplicaciones. Las audiencias de usuarios son valiosas en organizaciones grandes donde los atributos de los usuarios cambian con frecuencia y la selección manual de grupos no puede seguir el ritmo. --- ## Webhooks Source: https://docs.applivery.com/es/glossary/webhooks/ Description: Webhooks permite la automatización y las integraciones enviando cargas útiles de eventos a servicios externos sin sondeo. TL;DR: Webhooks envía cargas útiles de eventos en tiempo real a puntos finales externos para acciones automatizadas. Webhooks se usan comúnmente para conectar eventos de lanzamiento, actualizaciones del ciclo de vida del dispositivo y notificaciones de seguridad a sistemas de monitoreo, chat y emisión de tickets. --- ## Inscripción sin intervención Source: https://docs.applivery.com/es/glossary/zero-touch-enrollment/ Description: La inscripción sin intervención elimina el aprovisionamiento manual, lo que permite una implementación perfecta de dispositivos a escala con seguridad y cumplimiento desde el primer arranque. TL;DR: Zero-Touch Enrollment explicado para casos de uso de administración de dispositivos y distribución de aplicaciones empresariales. La inscripción automatizada de dispositivos de Apple (anteriormente DEP) y la inscripción sin intervención de Android permiten una verdadera implementación empresarial lista para usar para dispositivos iOS y Android. --- ## Intelligence Source: https://docs.applivery.com/es/intelligence/ Description: Applivery Intelligence — pregunta por tu parque de dispositivos en lenguaje natural, obtén respuestas en vivo desde tu Workspace, crea cuadros de mando, automatiza lo que viene después y deja que los agentes vigilen por ti. TL;DR: Pregunta por tus dispositivos en lenguaje natural y obtén respuestas con datos en vivo de Applivery. El Propietario del Workspace compra y asigna las licencias; tú lo abres desde el botón ✨ de la barra superior del panel. Answers: ¿Qué es Applivery Intelligence? · ¿Cómo activo Applivery Intelligence? · ¿Puede la IA gestionar mi parque de dispositivos? · ¿Qué puede hacer Applivery Intelligence? · ¿Cuánto cuesta Applivery Intelligence? Key topics: Qué es Applivery Intelligence, Las cuatro superficies, Licencias y acceso, Permisos y aprobaciones, Applivery, Applivery Intelligence, Applivery MCP, Endpoint Manager ## Intelligence Encontrar algo en un parque de dispositivos suele implicar abrir una lista, filtrarla y leerla. **Applivery Intelligence** cambia eso por una pregunta: > ¿Qué Macs llevan 30 días sin conectar? > Muéstrame todos los dispositivos sin cifrado de disco, agrupados por política. > Bloquea el portátil que David perdió ayer. Responde con datos **en vivo** de Applivery — la misma API que usa el panel, nunca una copia en caché —, muestra el resultado como una tabla, un gráfico, un mapa o una ficha de dispositivo interactivos, y te pide confirmación antes de cambiar nada. :::info **Disponible de forma general y en evolución continua.** Applivery Intelligence está disponible de forma general y con soporte. También es un producto de IA en investigación y mejora continuas: las respuestas se generan, las capacidades cambian entre versiones y puede equivocarse. Lee lo que produce antes de actuar sobre ello. ::: ### Las cuatro superficies | Superficie | Qué es | Plan necesario | | --- | --- | --- | | **Chat** | Pregunta, obtén respuestas interactivas y ejecuta acciones | Free, Pro, Max, Ultra | | **Insights** | Cuadros de mando con widgets en vivo, actualizados según una programación, con alertas | Max, Ultra | | **Workflows** | Automatizaciones visuales lanzadas por una alerta, una programación, un webhook o un clic | Max, Ultra | | **Cowork** | Agentes que examinan el parque en segundo plano y te traen lo que encuentran | Max, Ultra | ### Cómo se entra Applivery Intelligence se licencia **por persona, mediante licencias**. El Propietario de la organización de Applivery las compra y las asigna; cualquier persona con licencia abre Intelligence desde el **botón ✨** de la barra superior del panel de Applivery. No hay nada que instalar, ninguna clave de API que generar y ningún segundo inicio de sesión: reutiliza tu sesión activa de Applivery y arranca sobre el Workspace que ya estás viendo. :::warning Intelligence actúa **como tú**. Tu rol de Applivery es el techo: si no puedes borrar un dispositivo desde el panel de Applivery, tampoco podrás borrarlo pidiéndoselo a Intelligence. ::: ### Traer tu propio asistente Si prefieres trabajar desde Claude, ChatGPT o tus propias herramientas, [Applivery MCP](https://docs.applivery.com/es/intelligence/applivery-mcp/) expone ese mismo parque de dispositivos a través del Model Context Protocol. Las mismas capacidades, los mismos permisos, otro asistente. --- ## Applivery MCP Source: https://docs.applivery.com/es/intelligence/applivery-mcp/ Description: El servidor MCP de Applivery permite que cualquier asistente de IA compatible con MCP trabaje con tu Workspace de Applivery: cómo conectarlo, qué puede hacer y qué lo protege. TL;DR: Applivery Intelligence es el asistente que Applivery ha construido para ti. Applivery MCP es la puerta para que traigas el tuyo: Claude, ChatGPT o cualquier cosa que hable Model Context Protocol. Key topics: Qué es Applivery MCP, Conectar Claude y ChatGPT, Permisos y seguridad, Qué controla Applivery, Privacidad y tratamiento de datos, Applivery, Applivery MCP, Model Context Protocol, Claude, ChatGPT El **Model Context Protocol (MCP)** es un estándar abierto para dar a un asistente de IA un conjunto de acciones bien definidas y con permisos sobre un sistema real. El **servidor MCP de Applivery** es la implementación de Applivery: un único endpoint que lleva tu parque de dispositivos a Claude, ChatGPT o tus propias herramientas. :::info **Disponible de forma general y en evolución continua.** El servidor MCP de Applivery está disponible de forma general y con soporte. También es un producto orientado a IA en investigación y mejora continuas: el catálogo de herramientas, los listados en los directorios y las integraciones con clientes cambian entre versiones. Los asistentes pueden malinterpretar resultados, así que revisa cualquier cosa importante antes de aprobarla. ::: ### Cómo se relaciona con Applivery Intelligence | | **Applivery Intelligence** | **Applivery MCP** | | --- | --- | --- | | Qué es | Un producto completo: chat, cuadros de mando, workflows, monitorización proactiva | Un conector: un endpoint con el que habla un asistente | | Dónde se usa | Dentro del panel de Applivery | Dentro de Claude, ChatGPT o tus propias herramientas | | Quién elige el modelo | Applivery | Tú | | Cómo se licencia | Por licencias — consulta [Planes, licencias y facturación](https://docs.applivery.com/es/intelligence/plans-and-billing/) | Tu plan de Applivery, más lo que te cobre tu proveedor de IA | Más que alternativas, son dos puertas al mismo parque de dispositivos. Applivery Intelligence consume internamente ese mismo catálogo MCP: lo que obtienes en Claude es el mismo conjunto de capacidades, movido por otro asistente. :::tip Usa **Intelligence** cuando quieras cuadros de mando, automatización y monitorización que sigan funcionando al cerrar la pestaña. Usa **MCP** cuando quieras tener tu parque de dispositivos dentro de una conversación que ya estás teniendo, junto a tus otras herramientas. ::: ### Qué puedes hacer con él | Área | Ejemplos | | --- | --- | | **Inventario de dispositivos** | Buscar en el parque, inspeccionar un dispositivo, revisar apps instaladas, almacenamiento, versión de sistema, estado de cifrado | | **Acciones sobre dispositivos** | Bloquear, reiniciar, renombrar, borrar, activar el modo perdido, limpiar el código de acceso, desinscribir | | **Políticas** | Listar e inspeccionar políticas, ver qué tiene aplicado un dispositivo, revisar el estado de sincronización, crear y actualizar | | **Segmentos y audiencias** | Explorar el árbol de segmentos, revisar reglas de pertenencia, previsualizar a quién afectaría un cambio | | **Usuarios e inscripción** | Consultar personas, revisar plantillas de inscripción y tokens | | **Distribución de apps** | Revisar apps publicadas, builds, tiendas y quién ha descargado qué | | **Inventario y activos** | Seguir activos no gestionados y vincularlos a dispositivos inscritos | | **Scripts** | Revisar scripts, sus asignaciones y sus registros de ejecución | | **Auditoría** | Consultar el registro de auditoría: quién hizo qué, cuándo y sobre qué entidad | El catálogo expone actualmente alrededor de 146 acciones individuales. Cuáles de ellas ve tu asistente depende de tus plataformas, tu plan de Applivery, tus permisos y cuáles publica Applivery en el canal que estés usando. ### Requisitos - **Una cuenta de Applivery** con acceso a al menos un Workspace. El conector nunca crea cuentas ni Workspaces. - **Applivery Endpoint Manager (UEM/MDM)** o **distribución de apps**, según las acciones que quieras. Un Workspace que solo tenga distribución de apps no devuelve resultados de gestión de dispositivos. - **Permisos en Applivery.** El conector actúa como tú. - **Un asistente de IA en un plan que admita conectores.** La disponibilidad la controlan Anthropic, OpenAI o tus propias herramientas, no Applivery. No hay nada que instalar, ni agente, ni cambios de red, ni clave de API que generar. Inicias sesión con tu cuenta de Applivery en una pantalla de consentimiento OAuth estándar. ### Cómo funciona ```text Tú → Claude / ChatGPT → mcp.applivery.ai → api.applivery.io → tu Workspace ``` 1. Le preguntas al asistente algo sobre tu parque de dispositivos. 2. El asistente elige una de las acciones del conector y llama al servidor MCP de Applivery. 3. El servidor valida tu token de acceso, resuelve a qué Workspace de Applivery pertenece y llama a la API de Applivery con tus credenciales. 4. El resultado vuelve a la conversación. Todos los saltos van por HTTPS. El asistente nunca guarda una copia duradera de tus credenciales de Applivery: la autorización es una sesión OAuth que puedes revocar cuando quieras. ### Conectar con Claude **URL del conector:** `https://mcp.applivery.ai/mcp/anthropic` **Desde el directorio de conectores** 1. En Claude, abre **Settings > Connectors**. 2. Busca **Applivery** y selecciona **Connect**. 3. Inicia sesión con tu cuenta de Applivery en la ventana que se abre. 4. Revisa la pantalla de consentimiento — indica sobre qué Workspace actuará el conector — y selecciona **Authorize**. 5. Vuelves a Claude con el conector activado. **Como conector personalizado** Usa esta vía si tu organización prefiere añadirlo a mano. 1. Abre **Settings > Connectors > Add custom connector**. 2. Introduce **Name** `Applivery` y **Remote MCP server URL** `https://mcp.applivery.ai/mcp/anthropic`. 3. Selecciona **Add**, luego **Connect**, y completa el inicio de sesión de Applivery. :::tip En organizaciones Team y Enterprise, un propietario o administrador puede añadir el conector una vez para todo el mundo. Cada miembro sigue autorizando individualmente y sigue actuando con sus propios permisos de Applivery. ::: ### Conectar con ChatGPT **URL del conector:** `https://mcp.applivery.ai/mcp/openai` **Desde el directorio** 1. En ChatGPT, abre **Settings > Apps & Connectors**. 2. Busca **Applivery** y selecciona **Connect**. 3. Inicia sesión con tu cuenta de Applivery, revisa la pantalla de consentimiento y pulsa **Authorize**. **Como conector personalizado** 1. Abre **Settings > Apps & Connectors > Advanced > Developer mode** y actívalo. La disponibilidad depende de tu plan de ChatGPT. 2. Selecciona **Create** e introduce **Name** `Applivery`, **MCP server URL** `https://mcp.applivery.ai/mcp/openai` y **Authentication** OAuth. 3. Guarda, selecciona **Connect** y completa el inicio de sesión de Applivery. Según la superficie, puede que tengas que traer la app a la conversación explícitamente: escribe `@` y elige **Applivery**, o nómbrala en la petición: > Usando Applivery, lista los dispositivos Android que llevan 30 días sin conectar. ### Otros clientes MCP Cualquier cliente que hable MCP sobre Streamable HTTP con OAuth 2.1 puede conectarse. Apúntalo a `https://mcp.applivery.ai/mcp/anthropic` (el catálogo con forma de Anthropic) o pregunta a tu contacto de Applivery qué canal encaja con tu cliente. La autorización es OAuth 2.1 con PKCE; no hay ninguna clave de API fija que pegar. ### Elegir un Workspace Si tu cuenta de Applivery llega a más de un Workspace, el conector arranca en el que tengas por defecto. Para moverte entre ellos dentro de una conversación, basta con pedirlo: > ¿A qué workspaces de Applivery puedo acceder? > Cambia al workspace de Acme Corp. El cambio se aplica al resto de esa conversación y no cambia tu Workspace por defecto en el panel de Applivery. Los datos de un Workspace nunca se mezclan en una petición contra otro. ### Comprobar que funciona Pide primero algo de solo lectura: > ¿Cuántos dispositivos hay inscritos en mi workspace de Applivery? El asistente debería llamar al conector y responder con un número real. Si responde con conocimiento general, o dice que no tiene acceso, confirma que Applivery aparece como conectado en los ajustes del asistente y abre una conversación nueva. ### Permisos y seguridad **Actúa como tú, nunca por encima de ti.** La autorización es tu propia cuenta de Applivery. Tu rol de Applivery es el techo: no hay cuenta de servicio compartida, ni modo elevado, ni ruta de escalado. **Cada acción está hecha a medida.** No existe una acción genérica de «llama a la API». Cada capacidad es una acción independiente con un endpoint fijo, un esquema de entrada validado y un comportamiento documentado. Las lecturas y las escrituras son siempre acciones distintas, nunca una sola acción con un parámetro `method`. **Lectura y escritura vienen etiquetadas para el asistente.** Cada acción publica pistas legibles por máquina: | Pista | Significado | Efecto en Claude o ChatGPT | | --- | --- | --- | | Solo lectura | Solo lee datos | Puede ejecutarse sin preguntar cada vez | | Destructiva | Cambia o elimina datos existentes | **Siempre** pide confirmación | | Mundo cerrado | Opera solo dentro de tu tenant de Applivery | Indica un dominio predecible | Applivery etiqueta a propósito de más y no de menos: todo lo que modifica el estado se marca como destructivo, incluidas las actualizaciones, los comandos remotos de dispositivo (bloquear, reiniciar, apagar, limpiar el código de acceso, modo perdido), los movimientos entre segmentos y las notificaciones que llegan a usuarios finales. La única acción que sale de tu tenant es la búsqueda pública en tiendas de apps. **Confirmación antes de cualquier cosa irreversible.** Ante una acción destructiva, el asistente muestra qué va a hacer y sobre qué dispositivo, y espera. :::warning Para borrar, desinscribir y eliminar: pide primero la lista, léela tú y solo después pide actuar sobre ella. Aprobar un lote que no has leído es la forma más fiable de sacar un mal resultado de una buena herramienta. ::: **Límites de frecuencia.** Se aplican por cliente y por identidad autenticada, así que un bucle descontrolado en un asistente no puede machacar tu Workspace. Cuando se alcanza un límite, el asistente recibe un error claro y se para en lugar de reintentar a ciegas. **Transporte.** Solo HTTPS, sin alternativa en texto plano. OAuth 2.1 con PKCE. Los tokens que se emiten al asistente son opacos y de vida corta; los tokens de Applivery que hay detrás se guardan cifrados. ### Qué controla Applivery Applivery decide qué capacidades se publican, **por canal**: Claude, ChatGPT e integraciones directas o internas. - El conjunto de acciones disponible en Claude puede ser distinto del disponible en ChatGPT, y ambos pueden ser más estrechos que el que usan las integraciones internas. - Una acción que no se publica en ningún canal no se sirve a nadie. - Un despliegue de solo lectura es una configuración admitida: publica solo las acciones de lectura en el canal correspondiente y ningún asistente de ese canal podrá cambiar nada. Una acción que no está publicada en un canal no existe para los clientes de ese canal: se filtra antes de que se le cuente al asistente, no se limita a estar oculta. Applivery opera una consola dedicada para el conector, con las herramientas publicadas, los límites de frecuencia, las estadísticas de uso, los registros de peticiones y las trazas por llamada. No es una superficie para clientes; si necesitas un despliegue de solo lectura, un catálogo más estrecho o un informe de uso, pídeselo a tu contacto de Applivery. ### Privacidad y tratamiento de datos **Qué se envía a Applivery:** la acción a ejecutar y sus parámetros — un identificador de dispositivo, un término de búsqueda, un rango de fechas — más tu token de acceso. Applivery **no** recibe tu conversación, tu historial de prompts, tus archivos ni la memoria del asistente. **Qué vuelve:** el resultado de esa acción, recortado a lo que la petición necesita. Ese resultado pasa a formar parte de la conversación y queda sujeto al tratamiento de datos de tu proveedor de IA, no al de Applivery. **Qué registra Applivery:** registros operativos para soporte, depuración, prevención de abuso y calidad del servicio — qué acción se ejecutó, con qué parámetros, un resumen de la respuesta, si falló, cuánto tardó, para qué Workspace y usuario fue, de qué asistente vino, y la dirección IP y el user agent. :::warning Los parámetros de las acciones y los resúmenes de respuesta pueden incluir nombres de dispositivo, nombres de usuario y direcciones de correo de tu parque, y se conservan en los registros operativos de Applivery. Si tu organización tiene normas sobre qué datos de dispositivos pueden salir de tus sistemas, aplícalas en el momento de decidir **a quién** le das el conector. ::: Consulta la [política de privacidad de Applivery](https://www.applivery.com/legal/privacy-policy/) para la versión autorizada. ### Desconectar - **Claude:** **Settings > Connectors > Applivery > Disconnect**. - **ChatGPT:** **Settings > Apps & Connectors > Applivery > Disconnect**. - **Desde Applivery:** revoca la autorización en los ajustes de tu cuenta de Applivery. Las tres vías invalidan la misma sesión OAuth de inmediato. Volver a conectar exige iniciar sesión otra vez. ### Resolución de problemas | Síntoma | Qué significa | | --- | --- | | El asistente responde sin llamar a Applivery | El conector no está activado para esa conversación. Confirma que está conectado y abre un chat nuevo; en ChatGPT, nombra la app explícitamente. | | `403 — insufficient permissions` | Tu rol de Applivery no permite esa acción. No es un fallo del conector. | | Falta una acción que esperabas | No está publicada en ese canal. Pregunta a tu contacto de Applivery. | | Resultados del Workspace equivocado | Pide al asistente que cambie de Workspace explícitamente. | | Errores repetidos de límite de frecuencia | Demasiadas llamadas en poco tiempo, normalmente un asistente en bucle. Abre una conversación nueva. | --- ## Qué puede hacer Applivery Intelligence Source: https://docs.applivery.com/es/intelligence/capabilities/ Description: Chat, Insights, Workflows y Cowork — las cuatro superficies de Applivery Intelligence, los agentes especialistas que hay detrás y cómo funciona cada una. TL;DR: Chat responde preguntas y ejecuta acciones. Insights convierte las respuestas en cuadros de mando en vivo. Workflows automatiza lo que viene después. Cowork vigila el parque sin que se lo pidas. Key topics: Chat y artefactos, Permisos y aprobaciones, Cuadros de mando y alertas de Insights, Workflows y la puerta de aprobación, Monitores y hallazgos de Cowork, Applivery, Applivery Intelligence, Cowork, Insights, Workflows Applivery Intelligence se compone de cuatro superficies. **Chat** responde preguntas y ejecuta acciones. **Insights** convierte las respuestas en cuadros de mando en vivo. **Workflows** automatiza lo que viene después. **Cowork** vigila el parque sin que se lo pidas.

Superficie

Plan necesario

Chat

Free, Pro, Max, Ultra

Insights

Max, Ultra

Workflows

Max, Ultra

Cowork

Max, Ultra

:::info **Disponible de forma general y en evolución continua.** Applivery Intelligence está disponible de forma general y con soporte. También es un producto de IA en investigación y mejora continuas: las respuestas se generan, las capacidades cambian entre versiones y puede equivocarse. Revisa lo que produce antes de actuar sobre ello, sobre todo cualquier cosa que cambie un dispositivo. ::: ### Chat Chat es la puerta de entrada. Preguntas en lenguaje natural y responde con datos en vivo de Applivery. #### Cómo se produce una respuesta Un solo mensaje no lo gestiona un solo modelo. Intelligence ejecuta un **coordinador** que lee lo que estás pidiendo y lo enruta a uno o varios **agentes especialistas**, cada uno con su propio cometido, sus propias instrucciones y su propio conjunto restringido de herramientas de Applivery. El coordinador no tiene ningún acceso a tus dispositivos: toda respuesta que lleve datos viene de un especialista que ha tenido que ir a buscarlos.

Especialista

De qué se ocupa

Compliance Agent

Cumplimiento, auditorías, quién cumple o se desvía, incumplimientos

Security Agent

Acciones sobre dispositivos — mover, renombrar, bloquear, borrar, instalar — y triaje de riesgo

Impact Agent

Simulaciones de solo lectura: antes y después, composición simulada de políticas

Policy Agent

Diseño de políticas, comparación, ajuste de prioridades, permisos de segmentos

Insights Agent

Analítica del parque: tendencias, distribuciones, informes con gráficos

Knowledge Agent

Documentación de producto y de la API REST, con enlaces citados

Policy Architect

Diseña y crea políticas listas para aplicar en Apple, Android, AOSP y Windows

Scripts Engineer

Escribe, crea y asigna scripts de Bash para macOS y PowerShell para Windows

Vulnerability Agent

CVE conocidas de una versión de sistema o de app, con severidad, KEV y probabilidad de explotación

Cuando una petición abarca varios dominios — «¿qué dispositivos no cumplen, y qué rompería arreglar la política?» — el coordinador delega en varios especialistas en paralelo y después escribe una sola respuesta. La etiqueta de cada respuesta te dice qué especialista la ha producido. #### Artefactos: respuestas con las que puedes trabajar Cuando una respuesta tiene estructura, se muestra como **artefacto** en el panel lateral en lugar de como un muro de texto: una tabla de dispositivos ordenable, una comparación de políticas, un mapa, un gráfico, un desglose de CVE. Los artefactos son interactivos. Según el tipo, puedes: - **Ordenar y filtrar** columnas, y hacer clic en una fila para entrar en ese dispositivo o esa política. - **Descargar los datos en CSV**, desde el propio botón de descarga de la tabla. - **Añadirlo a un cuadro de mando** con **Add to dashboard**, que convierte la respuesta en un widget en vivo que se actualiza solo. - **Copiar el JSON** que hay detrás. Los tipos incluyen listas y fichas de dispositivo, mapas de dispositivos, listas de políticas, detalle de política, composición y comparación de políticas, informes de uso de apps y de datos, informes de datos con varios gráficos, tablas genéricas, documentación citada, referencias de endpoints REST y las tres vistas de vulnerabilidades. ![List of devices](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/041b09c1-5020-4153-a1cf-c067ac627344.png) #### Referenciar objetos con `@` Escribe `@` en el cuadro de mensaje para buscar e insertar un objeto concreto en lugar de describirlo. Puedes mencionar **dispositivos, políticas, usuarios MDM, segmentos, audiencias de dispositivos, reglas de automatización** y **plantillas de inscripción**. La referencia lleva la identidad del objeto, así que el asistente no tiene que adivinar a qué «MacBook Pro» te referías. #### Permisos y aprobaciones Esta es la parte que conviene leer dos veces. **Intelligence actúa como tú.** Llama a la API de Applivery con tus propias credenciales del Workspace, bajo tu identidad. Tu rol de Applivery es el techo: no hay cuenta de servicio, ni modo elevado, ni forma de que el asistente escale privilegios. Las acciones aparecen en el registro de auditoría de Applivery con tu nombre. **Lecturas y escrituras están separadas por diseño.** Todo lo que solo lee (`get`, `list`, `search`, `preview`) se clasifica como lectura; todo lo demás se clasifica como escritura, incluidas capacidades que no existían cuando se escribió la regla. La lista de lecturas es una lista de permitidos, no una lista de cosas a vigilar, así que una capacidad nueva con un verbo desconocido se trata como escritura hasta que alguien decida otra cosa. Esta clasificación es sobre la que corren las reglas de seguridad de la plataforma, y no es lo mismo que tus ajustes de aprobación, que controlas capacidad por capacidad. **Algunas acciones preguntan siempre, y no se puede desactivar.** Borrar un dispositivo, bloquearlo y cualquier cosa que elimine están vetados de forma permanente tras una confirmación, independientemente de lo que hayas guardado. Cuando se propone una de ellas ves exactamente qué acción, sobre qué dispositivo y con qué parámetros, y no se ejecuta nada hasta que apruebas. **El resto lo ajustas tú.** Abre el icono del engranaje de la barra superior y ve a **Integrations > Applivery MDM > Tool Permissions**. Cada capacidad aparece con lo que hace y puedes ponerla en:

Ajuste

Efecto

Always allow

Se ejecuta sin preguntarte

Needs approval

Te pregunta cada vez

Blocked

No se ejecuta nunca — al asistente se le dice que la capacidad no está disponible

De dónde vive este ajuste se derivan dos cosas: - **Es tuyo, no del Workspace.** Solo se aplica a tus conversaciones. Relajar una capacidad para ti no evita que se la pregunten a un compañero, y bloquear una no se la quita a él. No hay una política de herramientas a nivel de Workspace: el respaldo compartido es tu rol de Applivery. - **Todo empieza en «Needs approval»**, también las lecturas. A una licencia recién creada se le pregunta por cada llamada hasta que repasas la lista y permites las que te resulten cómodas. Es deliberadamente ruidoso el primer día; diez minutos en esta página lo arreglan. Las acciones vetadas de forma permanente muestran una etiqueta **Locked** y no se pueden sacar de _Needs approval_, guardes lo que guardes. La pestaña **History**, justo al lado, lista las llamadas hechas desde tus propias sesiones de chat — la capacidad, su entrada, la respuesta, la latencia y la hora — de los últimos 7 días, 30 días o 3 meses. ![approval required](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/d6daac18-bbf7-45e9-b003-3c71e45cf0bc.png) :::warning Para cualquier cosa irreversible — borrar, desinscribir, eliminar — pide primero la lista, léela tú y solo después pide actuar sobre ella. Aprobar un lote que no has leído es la forma más fiable de sacar un mal resultado de una buena herramienta. ::: #### Protecciones Chat está acotado a la gestión de dispositivos. En cada mensaje corren varias protecciones: - **Filtrado de inyección de prompts**: se rechazan los intentos de anular las instrucciones del asistente o de extraer su configuración. - **Filtrado de alcance**: el asistente declina peticiones que no tengan que ver con tu parque de dispositivos. - **Límites de longitud de mensaje y de frecuencia**, que fija Applivery por Workspace. - **Bloqueo total a responder sin datos.** Si el Workspace no expone herramientas de Applivery — un Workspace mal configurado, un rol sin permisos — el chat se niega a responder en lugar de inventarse un parque plausible. - **Reglas contra la fabricación.** El asistente no puede afirmar que ha producido un archivo, un gráfico o una tabla que no ha generado, ni que una acción ha funcionado si la herramienta no lo ha confirmado en ese mismo turno. #### Gestionar las conversaciones Tus conversaciones son **tuyas**. Se guardan en tu propia cuenta, se listan en el panel izquierdo, se titulan automáticamente a partir de la primera pregunta y ahí mismo puedes renombrarlas, archivarlas o borrarlas. Los compañeros con licencia en el mismo Workspace no las ven: lo que se comparte a nivel de Workspace son los cuadros de mando, los workflows y los hallazgos de Cowork, no el chat. Cambiar de Workspace cambia la lista: una conversación pertenece al Workspace en el que se inició, además de a ti. Cada respuesta va seguida de sugerencias de próximas preguntas, basadas en lo que Applivery puede hacer de verdad y no en prompts genéricos. ### Insights **Insights** convierte las respuestas en una vista monitorizada. Disponible en Max y Ultra. #### Cuadros de mando y widgets Un cuadro de mando es una rejilla de widgets que colocas arrastrando y redimensionando. Los widgets se crean de dos formas: - **Promocionando un artefacto del chat**: haces una pregunta, obtienes una tabla o un gráfico y haces clic en **Add to dashboard**. El widget se queda con la consulta que hay detrás del artefacto y a partir de ahí la reejecuta solo. - **Añadiendo uno directamente** a un cuadro de mando existente. ![insights dashboard](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/3cf793d7-224d-4423-ad4c-f9a7215c4eed.png) Los formatos de widget son **KPI** (un número con su tendencia), **línea**, **barras**, **donut**, **tabla**, **mapa** y **ficha**. Qué formatos están disponibles depende de cuáles sean los datos de base: una lista de dispositivos puede ser una tabla o un KPI; una consulta de ubicación puede ser un mapa. :::tip La forma más rápida de montar un cuadro de mando es tener antes la conversación. Haz las cuatro o cinco preguntas que harías un lunes por la mañana y fija cada respuesta. ::: #### Actualización Cada cuadro de mando es **manual** o **programado**. Los programados se actualizan según una expresión cron con soporte completo de zonas horarias, desde cada 5 minutos hasta a diario. La cabecera muestra la última actualización, la siguiente y te avisa cuando una actualización va con retraso en lugar de enseñarte números viejos sin decírtelo. **Refresh all** reejecuta todos los widgets bajo demanda. Un widget suelto también se puede actualizar por su cuenta, y su consulta se puede editar desde el menú del widget: **Edit query** genera un formulario a partir del esquema real de parámetros, así que puedes cambiar un filtro sin volver al chat. ![refresh schedule](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/d4b9e8da-7487-4bab-9761-a8f563c2abbc.png) #### Alertas Cualquier widget puede llevar reglas de alerta, que se evalúan en cada actualización, programada o manual.

Condición

Se dispara cuando

Umbral

Un número cruza un límite (>, >=, <, <=, ==, !=)

Cambio

El valor se mueve más de un N %, o N en términos absolutos, hacia arriba o hacia abajo

Ausencia

El widget no se ha actualizado dentro de una ventana de tiempo

Entre «se cumple la condición» y «te avisan» hay dos filtros independientes: - **Modo de notificación**: _on change_ (el predeterminado) se dispara solo en la transición de sano a activado, y se calla mientras la condición siga siendo cierta. _Every_ se dispara en cada evaluación. - **Enfriamiento**: un número mínimo de minutos entre notificaciones, sea cual sea el modo. Cada disparo se registra en el histórico de alertas del widget con el valor que lo provocó. Una alerta disparada también puede lanzar un workflow. ### Workflows Los **workflows** son automatizaciones visuales: un lienzo de nodos unidos por aristas, que se ejecutan en orden, con ramificaciones, bucles, aprobación humana y pasos de IA. Disponible en Max y Ultra. #### Disparadores Cada workflow tiene exactamente un disparador:

Disparador

Se dispara cuando

Alerta

Se dispara una regla de alerta de un cuadro de mando. Una alerta puede lanzar varios workflows.

Programación

Una expresión cron, en la zona horaria que elijas

Webhook

Un sistema externo hace una petición a una URL privada (Jira, PagerDuty, un script)

Manual

Alguien pulsa Run

Un workflow también puede ser invocado por otro como subworkflow, de forma síncrona o en segundo plano. #### Qué puede hacer un nodo

Grupo

Nodos

Acciones

Llamar a cualquier capacidad de Applivery; enviar una petición HTTP; ejecutar otro workflow

IA

Pedir a un modelo que clasifique, resuma o redacte, y usar el resultado más adelante

Notificaciones

Email, Slack, Google Chat, webhook genérico

Lógica

Condicional, switch, filtro, transformación, agregación, fusión

Bucles

For-each sobre una lista; reintento con retroceso exponencial

Humano

Puerta de aprobación: pausa la ejecución y espera a una persona

Utilidades

Espera, evaluación de expresiones

Los valores fluyen entre nodos como `{{plantillas}}` — `Dispositivo {{trigger.deviceName}} — batería {{trigger.battery}}%`. ![workflow](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/4520b400-e5c6-4176-8e88-57ea7ecaaa10.png) #### La puerta de aprobación Un nodo de **aprobación** pausa la ejecución y envía un enlace. Quien lo recibe aprueba o rechaza, y el workflow continúa por la rama correspondiente. Si nadie responde antes de que expire el tiempo, la ejecución toma la rama **rechazada** y registra que ha caducado: ni se queda pausada para siempre, ni continúa por defecto. Es el nodo que hay que poner delante de cualquier cosa que toque dispositivos de forma masiva. #### El AI Workflow Builder En vez de dibujar el grafo tú, descríbelo: > Crea una alerta de Slack cuando un dispositivo deje de cumplir. > Todos los lunes a las 9 de la mañana, envía por Google Chat un resumen del total de dispositivos por plataforma. El builder propone un conjunto concreto de cambios y **espera a que los apruebes** antes de tocar el lienzo. Los turnos aplicados se pueden revertir de uno en uno. #### Integraciones Los nodos de notificación y de IA necesitan credenciales, que se configuran una vez por Workspace en el icono del engranaje > **Integrations**: claves de API de Anthropic, OpenAI o Google, una clave de Resend para email y URLs de webhook entrante para Slack y Google Chat. Cada entrada lleva instrucciones de configuración con enlaces a la página correspondiente del proveedor. Están cifradas en reposo, pertenecen al Workspace y no a ti, y son independientes de las credenciales que usa el chat. #### Histórico Cada ejecución se registra con su disparador, su duración, su resultado y la entrada y salida de cada nodo, para que un fallo se pueda leer en vez de adivinarlo. El histórico a nivel de nodo se guarda 30 días; el estado de la ejecución, indefinidamente. ### Cowork **Cowork** invierte la iniciativa. En lugar de esperar a que le pregunten, los **agentes especialistas** de Applivery Intelligence se ejecutan en segundo plano, examinan el parque según una cadencia y producen **hallazgos**: elementos de bandeja que reconoces, aceptas, comentas o apruebas para ejecutar. Disponible en Max y Ultra. #### Monitores, comprobaciones y hallazgos Una **comprobación** es algo fijo que buscar, que viene de fábrica en Applivery. Un **monitor** es la instancia de esa comprobación en tu Workspace: activada o desactivada, con una cadencia, un alcance, unos umbrales y una severidad mínima. Las ejecutan dos agentes especialistas. El **Posture Auditor** se encarga de las comprobaciones de higiene, acceso, inventario y configuración, y puede proponer una remediación de un catálogo fijo de acciones. El **Threat Analyst** se encarga de las comprobaciones de anomalías y nunca propone una escritura: su trabajo termina en contarte qué ha cambiado. Tú configuras monitores. No escribes comprobaciones, y eso es precisamente el punto. La detección es código determinista, no un especialista decidiendo qué le parece raro. El especialista recibe lo que la comprobación ya ha encontrado, junto con las evidencias, y su trabajo es triarlo, redactarlo con claridad y, donde la comprobación lo permita, proponer una remediación. Un número dentro de un hallazgo se ha calculado, no generado, y se recalcula después para confirmarlo. #### Qué cubre el catálogo - **Postura e higiene**: conexiones obsoletas, desviaciones de cumplimiento, políticas sin asignar, versiones de sistema obsoletas, batería baja, audiencias vacías, reglas de automatización inertes. - **Acceso y personas**: permisos demasiado amplios, roles en conflicto, colaboradores sin acceso a MDM, cuentas privilegiadas sin 2FA, cuentas privilegiadas inactivas, cuentas nunca activadas, permisos que no llegan a nadie, roles de app redundantes. - **Inventario**: activos vinculados a dispositivos borrados, números de serie duplicados, tipo de activo que contradice el hardware, dispositivos gestionados sin ficha de activo. - **Configuración efectiva**: conflictos de composición de políticas, huecos de refuerzo en modo kiosco, secretos triviales en una configuración aplicada, políticas que no componen nada. - **Uso y anomalías**: activos gestionados inactivos, picos de uso de datos, picos de uso de apps, picos en el ritmo de inscripción, cambios en permisos privilegiados. Las comprobaciones de anomalías comparan un dispositivo solo contra **su propio** histórico, así que a un usuario intensivo no se le marca por ser un usuario intensivo. #### Leer la bandeja Los hallazgos llegan como **lista** o como **tablero**, filtrables por monitor. Cada tarjeta nombra la comprobación que lo ha producido, su severidad y los dispositivos o personas a los que afecta. ![cowork list](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/53420cbf-fb65-44b4-a934-de49a8163906.png) ![cowork detail](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/a6a18bd1-e13e-4c60-8f0b-33d70b134bc4.png) El estado de una ejecución importa tanto como su resultado. Cowork distingue «la comprobación se ejecutó y no encontró nada» de «la comprobación no pudo ejecutarse» — un problema de credenciales, una población vacía, una parada por presupuesto. Una bandeja vacía solo muestra el estado verde _Nothing to review_ cuando hay evidencia positiva de que el parque se ha examinado de verdad. De cada hallazgo puedes: - **Comentarlo** en un chat lateral con el especialista que lo produjo, que todavía tiene las evidencias. - **Aceptarlo**: sigue detectado y registrado, pero deja de preguntar. Los hallazgos aceptados se listan aparte y las aceptaciones se pueden revisar y deshacer. - **Descartarlo**. - **Aprobar** la remediación propuesta, cuando la comprobación ofrece una. #### Aprobar, ejecutar, revertir Cuando apruebas una remediación: - Se ejecuta una **plantilla fija y versionada** que viene de Applivery, no un plan compuesto por el modelo. Cowork puede nombrar una remediación; no puede inventarse una. - Se aplica **solo** a los sujetos del hallazgo que han superado la reverificación. El modelo tiene estructuralmente impedido nombrar un objetivo propio. - Se ejecuta con **tus** credenciales de Applivery, así que los permisos de Applivery son el respaldo real y el registro de auditoría nombra a la persona correcta. - **Revertir** deshace solo los pasos que sí funcionaron, y solo los cambios exactos que hizo la ejecución, dispositivo a dispositivo. Revertir no reabre el hallazgo: el problema vuelve a estar exactamente como estaba. #### Límites y cómo pararlo Cowork es la única superficie que gasta sin que haya una persona esperando, así que está acotada aparte: su propio presupuesto diario de tokens, un tope de ejecuciones por Workspace y día, y topes por ejecución de iteraciones, llamadas a herramientas, hallazgos emitidos y acciones ejecutadas. Tus controles son por monitor, en **Cowork > Monitors**: activa o desactiva una comprobación, cambia su cadencia, acota su alcance, mueve sus umbrales, sube su severidad mínima. Una comprobación desactivada no se ejecuta y no reporta nada, y la página lo dice en la tarjeta en vez de dejarla con aspecto de estar sana. Para parar Cowork por completo en un Workspace, desactiva todos los monitores activos. Applivery también opera interruptores a nivel de plataforma que pueden suspender la detección, la entrega o la ejecución de Cowork en todo el servicio, por un incidente o a petición tuya. No están en tu panel; pídeselo a tu contacto de Applivery. --- ## Preguntas frecuentes sobre Applivery Intelligence Source: https://docs.applivery.com/es/intelligence/faq/ Description: Respuestas a las dudas más habituales sobre Applivery Intelligence: acceso y licencias, qué puede hacer, aprobaciones y seguridad, límites de uso, protecciones y tratamiento de datos. TL;DR: Intelligence actúa como tú, pregunta antes de actuar y nunca entrena con los datos de tus dispositivos. Insights, Workflows y Cowork necesitan una licencia Max o Ultra. Answers: ¿Es seguro Applivery Intelligence? · ¿Applivery Intelligence entrena con mis datos? · ¿Qué puede borrar Applivery Intelligence? · ¿Por qué Applivery Intelligence me pide aprobar todo? Key topics: Acceso y licencias, Qué puede y qué no puede hacer, Aprobaciones y seguridad, Límites y consumo, Datos y privacidad, Applivery, Applivery Intelligence, Cowork, Endpoint Manager :::info **Disponible de forma general y en evolución continua.** Applivery Intelligence está disponible de forma general y con soporte. También es un producto de IA en investigación y mejora continuas: las respuestas se generan, las capacidades cambian entre versiones y puede equivocarse. Revisa lo que produce antes de actuar sobre ello. ::: ### Acceso y licencias **¿Cómo consigo acceso?** El Propietario de tu organización de Applivery compra una licencia y te la asigna. Después abres Intelligence desde el botón ✨ de la barra superior del panel de Applivery. No hay nada que instalar ni configurar. Consulta [Primeros pasos](https://docs.applivery.com/es/intelligence/get-started/). **¿Tengo que introducir una clave de API o conectar mi cuenta de Applivery?** No. Intelligence se ejecuta integrado en el panel de Applivery y reutiliza tu sesión activa. Si ves el panel, ya estás autenticado. **¿Quién puede comprar licencias?** Solo el **Propietario** de la organización de Applivery. El rol se lee en vivo desde el directorio de Applivery, así que siempre coincide con quién es Propietario ahora mismo. **¿Por qué no veo Insights, Workflows o Cowork en mi navegación?** Esas tres requieren una licencia **Max** o **Ultra**. Chat está disponible en todos los niveles. **Tengo varios Workspaces. ¿Necesito una licencia en cada uno?** Sí: una licencia se concede en un Workspace. Las conversaciones, los cuadros de mando, los workflows y los monitores también están acotados a un Workspace, así que cambiar de Workspace los cambia todos. **¿Qué pasa con mi trabajo si me desasignan la licencia?** No se borra nada. Los cuadros de mando, los workflows y los monitores pertenecen al Workspace y siguen funcionando. ### Qué puede y qué no puede hacer **¿De dónde saca los datos?** De tu Workspace de Applivery en vivo, a través de la misma API que usa el panel. No hay una copia aparte de tu parque de dispositivos ni una instantánea en caché desde la que responda. **¿Puede cambiar cosas o solo leer?** Ambas. Puede bloquear, renombrar, reiniciar, borrar, mover, desinscribir, instalar y desinstalar; crear y actualizar políticas; escribir y asignar scripts; gestionar segmentos y audiencias. Todo eso te lo pregunta antes. **¿Puede hacer cosas que yo no puedo hacer?** No. Actúa como tú, con tu rol de Applivery. Si el panel te lo denegaría, Intelligence también. **¿Responderá preguntas que no tengan que ver con mis dispositivos?** No. Las peticiones ajenas a la gestión de dispositivos se declinan. Está acotado a propósito. **¿Puede responder preguntas sobre el propio producto Applivery?** Sí. El Knowledge Agent responde a partir de la documentación pública de Applivery y de la referencia de la API REST, con enlaces a las páginas que ha usado. **¿Por qué dijo que había creado un CSV, un informe o una política, y no apareció nada?** No debería, y hay reglas explícitas contra exactamente eso. Si lo ves, trata la afirmación como falsa: comprueba en el registro de auditoría de Applivery o en el panel de artefactos qué pasó de verdad, y repórtalo. El CSV, en concreto, no es una acción aparte: cualquier artefacto de tabla lleva su propio botón de descarga. **¿Por qué me dio una respuesta distinta a la misma pregunta?** Las respuestas se generan y el parque de dispositivos se mueve por debajo. Para cualquier cosa que necesites reproducible, fíjala como widget de Insights: un widget reejecuta una consulta fija en lugar de volver a decidir cómo responder. ### Aprobaciones y seguridad **¿Qué necesita mi aprobación antes de ejecutarse?** De serie, todo, también las lecturas. Todas las capacidades empiezan en **Needs approval**, así que a una licencia nueva se le pregunta por cada llamada hasta que relajas las que te fíes. Eso se hace en **Settings > Integrations > Applivery MDM > Tool Permissions**. **¿Dónde cambio eso?** En el icono del engranaje de la barra superior, luego **Integrations > Applivery MDM > Tool Permissions**. Cada capacidad se puede poner en *Always allow*, *Needs approval* o *Blocked*. Un punto de partida razonable es permitir las lecturas que uses constantemente — listar dispositivos, obtener un dispositivo, obtener las apps de un dispositivo — y dejar en *Needs approval* todo lo que cambie algo. **¿Ese ajuste es mío o del Workspace?** Tuyo. Solo se aplica a tus conversaciones. Relajar una capacidad no evita que se la pregunten a un compañero, y bloquear una no se la quita a él. No hay una política de herramientas a nivel de Workspace en Intelligence: el respaldo compartido es tu rol de Applivery, que ningún ajuste de aquí puede ampliar. **¿Qué acciones preguntan siempre, pase lo que pase?** **Borrar** un dispositivo, **bloquear** un dispositivo y **cualquier cosa que elimine**. Nadie puede ponerlas en *Always allow*, tampoco Applivery. Muestran una etiqueta **Locked** en la lista. **¿Puedo ver qué se ha llamado de verdad?** Sí: la pestaña **History**, junto a Tool Permissions, lista las llamadas de tus propias sesiones de chat con su entrada, su respuesta, su latencia y su hora, de los últimos 7 días, 30 días o 3 meses. **¿Qué me muestra un aviso de aprobación?** La capacidad exacta que se va a llamar, sobre qué objeto y con qué parámetros, antes de que pase nada. **¿Y si ignoro un aviso de aprobación?** Caduca y la acción no se ejecuta. Nada continúa por defecto. **¿Los workflows tienen la misma protección?** Los workflows se ejecutan con la identidad de la persona o la programación que los lanzó, con los mismos permisos de Applivery. Para operaciones masivas, pon un **nodo de aprobación** delante del paso destructivo: la ejecución se pausa y espera a una persona, y si nadie responde antes de que expire el tiempo toma la rama de rechazo. **¿Puede Cowork cambiar mi parque por su cuenta?** No. Cowork propone; una persona aprueba. Cuando apruebas, la remediación es una plantilla fija que viene de Applivery, limitada a los objetos de ese hallazgo y ejecutada con **tus** credenciales. Se puede revertir, y la reversión solo deshace lo que la ejecución cambió de verdad. **¿Hay parada de emergencia?** Para Cowork: desactiva los monitores en **Cowork > Monitors**. Una comprobación desactivada no se ejecuta y no reporta nada, y desactivarlas todas detiene Cowork en ese Workspace. Para el chat: pon la capacidad en *Blocked* en tus propios Tool Permissions, lo que la para para ti, o acota el rol de Applivery de esa persona, lo que la para en todas partes, incluido el propio panel de Applivery. Applivery además opera interruptores a nivel de plataforma que pueden suspender Cowork en todo el servicio; pídeselo a tu contacto de Applivery si lo necesitas. **¿Las acciones aparecen en el registro de auditoría de Applivery?** Sí, con el nombre de la persona que las ejecutó o las aprobó. ### Límites y consumo **¿Cómo se cuenta el consumo?** En créditos, contra el consumo incluido en tu licencia para el periodo de facturación. Leer dispositivos, razonar sobre ellos y generar los resultados gastan una parte. **¿Hay límite por hora o por día?** No. El único límite es el del periodo de facturación completo. **¿Qué pasa cuando me quedo sin consumo?** Primero se gasta el de tu plan, después los créditos comprados del Workspace si tu licencia puede usarlos. Si no queda ninguno, el chat se pausa hasta la fecha de reinicio. No se pierde nada. **¿Se acumula lo que no gasto?** No. Se renueva entero en la fecha de reinicio. **¿Los workflows programados y los monitores de Cowork se comen mi consumo personal?** No, y es deliberado. El trabajo en segundo plano gasta de un fondo compartido aparte que financian las licencias Max y Ultra, para que un proceso nocturno no te deje sin chat por la mañana. **¿Por qué mi Workspace no tiene fondo de automatización?** Porque ninguna de sus licencias es Max ni Ultra. Las licencias Free y Pro no aportan nada. **¿Hay un límite de cuántos cuadros de mando, workflows o monitores puedo crear?** No hay límite numérico. Esos objetos pertenecen al Workspace y no a una persona, así que limitarlos por licencia no tendría sentido. **¿Cuánto tiempo se guarda el histórico?** El histórico de workflows a nivel de nodo, 30 días; el histórico de alertas y de actualizaciones de cuadros de mando, 60 días; los registros de consumo, 90 días. El estado de las ejecuciones de workflows se guarda indefinidamente. Las conversaciones, los cuadros de mando, los artefactos, los workflows y los hallazgos se guardan hasta que los borras. ### Protecciones **¿Qué se filtra antes de que el asistente vea mi mensaje?** Los intentos de anular sus instrucciones o de extraer su configuración, las peticiones ajenas a la gestión de dispositivos y los mensajes que superan el límite de longitud configurado. El alcance y los límites los fija Applivery por Workspace, no se tocan desde tu panel; pídeselo a tu contacto de Applivery si los valores por defecto no te encajan. **¿Puede alguien conseguir que filtre datos de otro cliente?** Cada petición se resuelve contra un Workspace, y las credenciales se resuelven por Workspace en cada llamada. No hay cuenta compartida ni ruta de consulta entre Workspaces. **¿Qué impide que se invente un parque de dispositivos cuando no puede acceder a ninguno?** Si el Workspace no expone capacidades de Applivery — un Workspace mal configurado, o un rol sin permisos — el chat se niega a responder en lugar de tirar de conocimiento general. Ves un aviso explícito en vez de una ficción plausible. **¿Qué impide que un monitor de Cowork llene la bandeja de ruido?** Topes por ejecución de hallazgos, llamadas a herramientas e iteraciones; un tope diario de ejecuciones por Workspace; un tope diario de acciones ejecutadas; y su propio presupuesto de tokens, independiente del del chat. **¿Una bandeja de Cowork vacía significa que todo está bien?** Solo cuando lo dice. Cowork distingue «se ejecutó y no encontró nada» de «no pudo ejecutarse», y solo da el visto bueno con evidencia de que el parque se ha examinado. ### Datos y privacidad **¿Se usan los datos de mis dispositivos para entrenar modelos?** No. Tus datos se usan para responder a tu petición. **¿Qué se almacena?** Tus conversaciones y los artefactos que produjeron, tus cuadros de mando y sus últimos datos actualizados, tus workflows y su histórico de ejecuciones, tus monitores y hallazgos de Cowork, y registros operativos de consumo para facturación y soporte. **¿Dónde se ejecuta?** En la infraestructura de Applivery, sobre HTTPS de punta a punta. Las credenciales de Applivery que usa se guardan cifradas y se resuelven por Workspace en el momento de la llamada. **¿Puedo borrar una conversación?** Sí, desde el menú de la conversación. Los cuadros de mando, los workflows y los hallazgos también se pueden borrar. **¿Quién ve qué dentro de mi organización?** Las conversaciones son solo tuyas: se listan en tu propia cuenta y los compañeros del mismo Workspace no las ven. Tus Tool Permissions también son tuyos. Los cuadros de mando, los workflows, los hallazgos de Cowork y las credenciales de integración del Workspace son de nivel Workspace y se comparten con todo el que tenga licencia. ### Resolución de problemas **Aparece «Connect Applivery» en lugar del chat.** La sesión integrada no se ha traspasado. Recarga el panel de Applivery y vuelve a abrir Intelligence. **«Session expired».** Tu sesión de Applivery ha terminado. Vuelve a iniciar sesión en el panel. **Responde, pero nunca lee datos reales.** Normalmente es un Workspace sin Endpoint Manager, o un rol de Applivery sin permisos sobre dispositivos. Confirma ambas cosas en el panel de Applivery. **Un widget muestra «Overdue — refresh may not be running».** La programación del cuadro de mando no se ha disparado dentro de su ventana prevista. Prueba **Refresh all**; si sigue pasando, comprueba que el Workspace todavía tiene fondo de automatización, es decir, licencias Max o Ultra. **Una alerta no se dispara nunca.** Comprueba el modo de notificación: *on change* se queda callado mientras la condición siga siendo cierta de forma continua. Comprueba también el enfriamiento, y confirma que el widget se está actualizando. **Un monitor no produce nada.** Abre el estado de la ejecución. `skipped` y `credential error` son distintos de «no encontró nada», y la bandeja te dice cuál de los dos fue. **Una respuesta larga se corta a mitad.** El turno se quedó sin presupuesto de salida. Pide una porción más estrecha — una plataforma, un segmento, una página — en lugar de todo el parque de golpe. --- ## Primeros pasos con Applivery Intelligence Source: https://docs.applivery.com/es/intelligence/get-started/ Description: Activa Applivery Intelligence en tu organización: compra y asigna licencias, ábrelo desde el panel de Applivery y haz tu primera pregunta sobre tu parque de dispositivos. TL;DR: El Propietario del Workspace compra las licencias y las asigna. Quien tiene licencia abre Intelligence desde el botón ✨ de la barra superior del panel de Applivery: sin credenciales, sin configuración y sin un inicio de sesión aparte. Key topics: Requisitos, Comprar licencias, Asignar licencias, Abrir Intelligence, La primera pregunta, Applivery, Applivery Intelligence, Endpoint Manager, Propietario del Workspace **Applivery Intelligence** es una capa conversacional sobre tu Workspace de Applivery. En lugar de ir a una lista, filtrarla y leerla, preguntas: > ¿Qué Macs llevan 30 días sin conectar? > Muéstrame todos los dispositivos sin cifrado de disco, agrupados por política. > Bloquea el portátil que David perdió ayer. Responde con datos **en vivo** de Applivery, muestra el resultado como una tabla, un gráfico, un mapa o una ficha de dispositivo interactivos y, cuando le pides que cambie algo, te pide confirmación antes de hacerlo. :::info **Disponible de forma general y en evolución continua.** Applivery Intelligence está disponible de forma general y con soporte. También es un producto de IA en investigación y mejora continuas: las respuestas se generan, las capacidades cambian entre versiones y puede equivocarse. Lee lo que produce antes de actuar sobre ello, y lee [Permisos y aprobaciones](https://docs.applivery.com/es/intelligence/capabilities/) antes de relajar los avisos de aprobación de cualquier cosa que escriba sobre dispositivos reales. ::: ### Requisitos Antes de que nadie pueda usarlo, necesitas: - **Una cuenta de Applivery** con acceso a al menos un Workspace. Intelligence nunca crea cuentas ni Workspaces. - **Applivery Endpoint Manager (UEM/MDM)** en ese Workspace. Intelligence lee y actúa a través de la misma API de Applivery que usa el panel, así que un Workspace que solo tenga distribución de apps devuelve muy poca información. - **Una licencia**, asignada por el Propietario del Workspace. Consulta [Planes, licencias y facturación](https://docs.applivery.com/es/intelligence/plans-and-billing/). - **Nada más.** No hay agente que instalar, ni clave de API que generar, ni cambios de red, ni una contraseña aparte. Intelligence reutiliza tu sesión de Applivery. :::warning Intelligence actúa **como tú**. Tu rol de Applivery es el techo: si no puedes borrar un dispositivo desde el panel de Applivery, tampoco podrás borrarlo pidiéndoselo a Intelligence — la API devuelve el mismo error de permisos de siempre. ::: **Compra las licencias** Applivery Intelligence se licencia **por persona, mediante licencias**. El Propietario de la organización compra una cantidad de licencias de un nivel concreto; nadie más compra nada. 1. Abre Intelligence y ve a **Plan & billing > Seats & billing**. 2. Elige un **Tier** — Pro, Max o Ultra — e introduce el número **total** de licencias con las que debe quedarse el Workspace. 3. Confirma. Se cobra de inmediato en la tarjeta registrada de la organización, prorrateado por lo que queda del periodo actual. Solo el **Propietario** de la organización de Applivery ve los controles de compra. El rol se resuelve en vivo desde el directorio de Applivery cada vez, así que ascender a alguien a Propietario en Applivery le da los controles sin tocar nada en Intelligence. Los niveles, los precios y lo que incluye cada uno están en [Planes, licencias y facturación](https://docs.applivery.com/es/intelligence/plans-and-billing/). **Asigna las licencias** Una licencia comprada no hace nada hasta que se la das a alguien. 1. Ve a **Plan & billing > Seats & billing > Who has a seat**. 2. Busca a la persona y asígnale una licencia del nivel que quieras. 3. Si lo necesitas, define su **Extra credits cap**: cuánto puede gastar esa persona del saldo de créditos compartido del Workspace una vez agotado el consumo incluido en su plan. Déjalo vacío para no poner límite; ponlo a `0` para que no toque el saldo compartido en absoluto. Desasignar una licencia la libera **de inmediato**, así que puedes dársela a otra persona ese mismo día. No se reembolsa: sigue pagada hasta que acabe el periodo. :::tip No puedes reducir el número de licencias por debajo de las que hay asignadas. Desasigna primero y baja la cantidad después. ::: **Abre Intelligence** Cualquier persona con licencia abre Intelligence desde el **panel de Applivery**, con el **botón ✨** de la barra de navegación superior, junto al icono de búsqueda. ![intelligence](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/74884cd7-e28a-4e7f-941a-ee7e52a345be.png) Intelligence se abre **integrado dentro del panel**, sobre el Workspace que ya estás viendo. Esa es toda la configuración: - **Ninguna credencial que configurar.** Reutiliza tu sesión activa de Applivery. - **Ningún segundo inicio de sesión.** Cerrar sesión en Applivery te la cierra también en Intelligence. - **Ningún selector de workspace que puedas equivocar.** Arranca sobre el Workspace en el que está el panel. Si tu cuenta llega a varios Workspaces, cambia desde el selector de Workspace de la barra superior de Intelligence. Cada Workspace tiene sus propias conversaciones, cuadros de mando, workflows, monitores y licencias. **Pregunta algo** Empieza solo con lecturas. Una buena primera pregunta demuestra que la conexión funciona de punta a punta: > ¿Cuántos dispositivos hay inscritos en este workspace? Después prueba algo que genere un artefacto — un resultado interactivo que puedes ordenar, explorar, descargar como CSV o fijar en un cuadro de mando: > Muéstrame todos los dispositivos Android con su versión de sistema operativo y su última conexión. > ¿Qué dispositivos están por debajo de macOS 26.3? Agrúpalos por empleado. > ¿Dónde están ahora mismo mis dispositivos en modo perdido? ### Tres cosas que conviene saber el primer día - **Escribe** `@` **para referenciar un objeto concreto.** Puedes mencionar por su nombre un dispositivo, una política, un usuario MDM, un segmento, una audiencia de dispositivos, una regla de automatización o una plantilla de inscripción, en vez de describirlos. - **Bajo cada respuesta aparecen sugerencias.** Están basadas en lo que Applivery puede hacer de verdad, así que son una forma rápida de descubrir la herramienta. - **Pregunta antes de actuar y, al principio, antes de todo.** Todas las capacidades empiezan en _Needs approval_, también las lecturas, así que tus primeras preguntas generarán un aviso cada una. Ve al icono del engranaje > **Integrations > Applivery MDM > Tool Permissions** y pon en _Always allow_ las lecturas que uses constantemente. Borrar, bloquear y eliminar siguen pidiendo confirmación elijas lo que elijas. ### Lo que no tendrás en todos los planes Chat está disponible en todos los niveles, incluido Free. **Insights, Workflows, Cowork y el AI Workflow Builder requieren una licencia Max o Ultra.** Si la navegación muestra una superficie que no puedes abrir, el motivo es el nivel de tu licencia — consulta [Planes, licencias y facturación](https://docs.applivery.com/es/intelligence/plans-and-billing/). ### Si algo no funciona

Síntoma

Causa más probable

Aparece «Connect Applivery» en lugar del chat

La sesión integrada todavía no se ha traspasado. Recarga el panel de Applivery.

«Session expired»

Tu sesión de Applivery ha terminado. Vuelve a iniciar sesión en el panel.

Intelligence responde pero nunca lee datos reales

El Workspace no expone herramientas MDM — normalmente un Workspace sin Endpoint Manager, o un rol de Applivery sin permisos sobre dispositivos.

Falta una superficie en la navegación

El nivel de tu licencia no la incluye.

«No seat assigned» en Plan & billing

Pide a tu Propietario que te asigne una.

--- ## Planes, licencias y facturación Source: https://docs.applivery.com/es/intelligence/plans-and-billing/ Description: Cómo se licencia Applivery Intelligence: los cuatro niveles, cómo se compran y asignan las licencias, cómo funcionan el consumo incluido y los créditos compartidos, y quién paga la automatización en segundo plano. TL;DR: El Propietario compra licencias por nivel y se las asigna a personas. Cada licencia lleva su propio consumo mensual incluido. La automatización en segundo plano gasta de un fondo compartido aparte, así que un proceso de las 3 de la mañana nunca deja sin chat a un compañero. Answers: ¿Cuánto cuesta Applivery Intelligence? · ¿Qué diferencia hay entre Max y Ultra? · ¿Cómo funcionan los créditos de Applivery Intelligence? · ¿Quién puede comprar licencias de Applivery Intelligence? Key topics: Licencias y asignación, Los niveles, Consumo y créditos, Saldos compartidos, Compra y datos de facturación, Applivery, Applivery Intelligence, Stripe, Propietario del Workspace Applivery Intelligence se licencia **por persona**. El **Propietario** de la organización de Applivery compra una cantidad de licencias de un nivel y se las asigna a personas concretas. Nadie más compra nada, y nadie se suscribe por su cuenta. :::info **Disponible de forma general y en evolución continua.** Applivery Intelligence está disponible de forma general y con soporte. También es un producto de IA en investigación y mejora continuas: las capacidades, los límites de uso y los precios pueden cambiar entre versiones. Lo que sigue describe cómo funciona hoy. ::: ### Licencias, no suscripciones Tres reglas rigen las licencias, y las tres son deliberadas: 1. **No puedes asignar más licencias de las que has comprado.** La comprobación ocurre dentro de la propia asignación, así que dos Propietarios actuando a la vez no pueden quedarse los dos con la última. 2. **Desasignar libera la licencia de inmediato, y no se reembolsa.** Sigue pagada hasta el final del periodo, así que puedes dársela a otra persona ese mismo día. 3. **No puedes bajar la cantidad por debajo de las licencias asignadas.** Desasigna primero y baja el número después. Todo lo que produce una licencia — conversaciones, cuadros de mando, workflows, monitores — pertenece al **Workspace**, no a la persona. Cuando alguien se va, su trabajo se queda. ### Los niveles | | **Free** | **Pro** | **Max** | **Ultra** | | --- | --- | --- | --- | --- | | Precio | — | 29 € /licencia/mes | 99 € /licencia/mes | 199 € /licencia/mes | | Chat | ✅ | ✅ | ✅ | ✅ | | Insights (cuadros de mando y alertas) | — | — | ✅ | ✅ | | Workflows de automatización | — | — | ✅ | ✅ | | AI Workflow Builder | — | — | ✅ | ✅ | | Monitorización proactiva Cowork | — | — | ✅ | ✅ | | Consumo por periodo | Una muestra limitada | Capacidad base | 5× la capacidad de Pro | 10× la capacidad de Pro | | Aporta créditos de automatización compartidos | — | — | 30.000 /mes | 100.000 /mes | Los precios se indican sin IVA, que Stripe añade a partir de la dirección de facturación de la organización. La facturación es mensual y recurrente. **Max y Ultra tienen las mismas funcionalidades.** La diferencia entre ambos es el margen de uso, no la capacidad: Ultra existe para quien se queda corto con Max. :::tip Todos los niveles pueden usar los mismos modelos. Los niveles se diferencian en **a qué superficies llegas** y en **cuánto puedes usarlas**, nunca en darle a un cliente un asistente más listo que a otro. ::: ### Cómo se mide el consumo Cada licencia lleva un **consumo incluido para el periodo de facturación**, expresado en créditos. Todo lo que el asistente hace por ti — leer dispositivos, razonar sobre ellos, dibujar un gráfico — gasta una parte. - **Se renueva entero en la fecha de reinicio y no se acumula.** Lo que no gastas no se guarda. - **No hay límite por hora ni por día.** El único límite es el del periodo completo. - **El trabajo en segundo plano nunca lo toca.** Los workflows programados y los monitores de Cowork gastan del fondo compartido que se describe más abajo. Tu consumo actual, la fecha de reinicio y el desglose por superficie están en **Plan & billing > Usage**. #### Qué pasa cuando te quedas sin consumo 1. Primero se gasta el consumo incluido en tu plan. 2. Después los **créditos de uso** comprados por el Workspace, si los hay y si tu licencia puede usarlos. 3. Si no hay ninguno disponible, el chat se pausa hasta la fecha de reinicio. No se borra nada ni se pierde nada: se reanuda solo. ### Uso compartido Existen dos saldos compartidos distintos, y resuelven problemas diferentes. #### Créditos de uso compartidos (comprados) El Propietario puede comprar paquetes de créditos de prepago en un saldo que pertenece a **todo el Workspace**. Una licencia solo tira de él **después** de agotar el suyo. Cada asignación lleva un **Extra credits cap**: cuánto puede gastar esa persona de ese saldo compartido una vez agotado el suyo. | Valor | Efecto | | --- | --- | | **Vacío** | Sin límite | | **Un número** | Esa cantidad de créditos, y después se para | | **`0`** | Nunca tira del saldo compartido | El límite existe para que un usuario intensivo no pueda gastarse el saldo del Workspace en una tarde. Nunca limita el consumo incluido en su propio plan, que siempre es suyo al completo. La **recarga automática** puede comprar otro paquete cuando el saldo baja de un umbral, con su propio techo mensual. Se pausa sola tras varios cobros fallidos en lugar de reintentar sin fin. #### Créditos de automatización compartidos (derivados) Este saldo **no se compra**: se deriva de las licencias. Cada licencia **Max** aporta 30.000 créditos al mes y cada **Ultra**, 100.000. Free y Pro no aportan nada. Los workflows programados, los monitores de Cowork y los procesos por lotes gastan de este fondo en lugar del consumo personal de nadie. El motivo es concreto: un monitor que se ejecuta a las 03:00 no puede dejar a alguien sin chat por la mañana, y no puede morir cuando la persona que lo creó se va de la empresa. :::warning Un Workspace sin ninguna licencia Max o Ultra no financia fondo de automatización. Los workflows programados y los monitores de Cowork no tienen de dónde gastar y no se ejecutarán. ::: ### Quién puede comprar **Solo el Propietario de la organización de Applivery.** El rol se resuelve **en vivo** desde el directorio de Applivery cada vez que se abre la página, no desde un registro de pertenencia en caché ni desde tu sesión. Asciende a alguien a Propietario en Applivery y los controles le aparecen; quítaselo y desaparecen. El resto ve su propio plan, su propio consumo y su propio límite de créditos, y nada más. ### Comprar y cambiar la cantidad En **Plan & billing > Seats & billing**: 1. Elige el **Tier**. 2. Introduce el número **total** de licencias con las que debe quedarse el Workspace, no las que quieres añadir. 3. Confirma. Se cobra **de inmediato** en la tarjeta guardada de la organización, prorrateado por lo que queda del periodo actual. Si no hay tarjeta guardada, o el banco pide autenticación reforzada, se te lleva a Stripe para completar el pago una vez; a partir de ahí las compras se confirman sin salir. Antes de cobrar, el panel de confirmación muestra exactamente a quién se factura, qué tarjeta se usa y si se añadirá IVA. ### De dónde salen los datos de facturación La razón social, el NIF, el email de facturación, la dirección y la tarjeta salen de **tu organización de Applivery**. Intelligence los lee; no son suyos. Para cambiar cualquiera de ellos, ve al panel de Applivery > **Workspace > Facturación**. Los cambios aparecen en Intelligence en la siguiente carga. Los cargos de las licencias aparecen en la factura normal de Applivery de la organización. El registro de **Credit purchases** dentro de Intelligence solo lista los paquetes de créditos de prepago. :::warning Si la tarjeta registrada ha caducado, las renovaciones fallan. Un pago fallido no te corta el servicio esa misma hora — la licencia sigue activa durante la ventana de reintentos de pago — pero acabará caducando si no se arregla. ::: ### Pagar con tu contrato de Applivery Para clientes con contrato, las licencias se pueden conceder fuera de Stripe. Habla con tu contacto de Applivery si prefieres no pagar con tarjeta. --- ## Inventario Source: https://docs.applivery.com/es/inventory/ Description: Módulo Inventario de Applivery — registra todos los activos de tu organización, incluyendo dispositivos enrollados, hardware, periféricos y licencias de software. TL;DR: El módulo Inventario de Applivery ofrece una plataforma centralizada para registrar y gestionar todos los activos de tu organización, incluyendo dispositivos, hardware y software. Answers: ¿Para qué sirve el módulo Inventario de Applivery? · ¿Cómo se añaden los dispositivos al Inventario? · ¿Qué tipos de activos puedo registrar en el Inventario? · ¿Puedo importar activos en bloque? · ¿Se elimina un dispositivo del Inventario al desinscribirlo? Key topics: Inventario de activos, Gestión de dispositivos, Seguimiento de hardware, Seguimiento de software, Applivery, CSV El módulo Inventario de Applivery te ofrece un lugar centralizado para registrar todos los activos físicos y virtuales de tu organización — no solo los dispositivos enrollados en Device Management, sino cualquier activo de hardware o software del que necesites llevar un registro. Los dispositivos enrollados en Applivery se añaden automáticamente a tu Inventario. Para los activos que no pueden enrollarse — como hardware obsoleto, equipos de terceros o licencias de software — puedes añadirlos manualmente o importarlos en bloque mediante CSV. --- ## Gestión de activos Source: https://docs.applivery.com/es/inventory/asset-management/ Description: Registra y gestiona todos los activos de tu organización con el módulo Inventario de Applivery — desde dispositivos hasta licencias de software — y simplifica la gestión del ciclo de vida de los activos. TL;DR: El módulo Inventario de Applivery simplifica la gestión de activos proporcionando una plataforma centralizada para registrar y gestionar todo el hardware y software de tu organización. Answers: ¿Para qué sirve el módulo Inventario de Applivery? · ¿Cómo se añaden dispositivos al Inventario de Applivery? · ¿Qué información de dispositivo puedo registrar en el Inventario? · ¿Cómo añado varios activos a la vez? · ¿Qué ocurre con los activos del Inventario al desinscribir un dispositivo? Key topics: Identificación de activos, Seguimiento de activos, Gestión del ciclo de vida de activos, Importación masiva del inventario, Informes del inventario, Applivery, CSV, Microsoft Excel, Google Sheets El módulo Inventario de Applivery te ofrece un lugar centralizado para registrar todos los activos físicos y virtuales de tu organización — no solo los dispositivos enrollados en Device Management, sino cualquier activo de hardware o software del que quieras llevar un registro. Piensa en portátiles, monitores, servidores, equipos de red, smartphones, licencias de software y mucho más. Esto facilita mantener registros precisos de lo que tienes, dónde está, quién lo usa y en qué estado se encuentra — todo desde la misma plataforma que ya usas para gestionar dispositivos. El módulo Inventario cubre el ciclo de vida completo del activo: - **Identificación**: cataloga todos los activos de tu organización, estén o no enrollados en Applivery. - **Seguimiento**: almacena información detallada de cada elemento — nombre del dispositivo, modelo, número de serie, ubicación, usuario asignado, detalles de compra y más. - **Monitorización y actualizaciones**: mantén los registros actualizados a medida que los dispositivos se añaden, mueven, actualizan o dan de baja. - **Gestión del ciclo de vida**: registra garantías, vida útil esperada y contratos de mantenimiento desde la adquisición hasta la baja. ### Añadir dispositivos al inventario En el [**panel de Applivery**](https://dashboard.applivery.io/), haz clic en el menú de 9 puntos de la parte superior y selecciona Inventario. ![inventory](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/5940f5c1-e934-4d5f-a620-c2cd4f12bd00.png) Al enrollar un dispositivo en Applivery, este se añade automáticamente a tu inventario. Para los activos que no pueden enrollarse en la plataforma — como hardware obsoleto, equipos de terceros o licencias de software — puedes añadirlos manualmente con el botón **\+ Crear elemento de inventario** 1, o importar múltiples entradas a la vez mediante un archivo CSV usando el botón **Importar** 2. ![add inventory item](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/695465ef-a6f2-41bf-a155-0d0f1ed6004a.png) Todas las entradas del inventario son completamente editables y están organizadas en las siguientes secciones. ### Básico Información general de identificación del activo: - **Tipo de dispositivo**: categoría del elemento. Al importar mediante CSV, usa uno de los siguientes valores: `accessControl`, `accessPoint`, `barcodeScanner`, `cardReader`, `cameraCctv`, `cameraIp`, `desktopComputer`, `device`, `dockStation`, `externalDevice`, `externalHardDrive`, `firewall`, `hdmiAdapter`, `headphones`, `keyboard`, `laptop`, `microphone`, `monitor`, `mouse`, `posTerminal`, `printer`, `router`, `scanner`, `server`, `smartphone`, `smartwatch`, `softwareLicense`, `speaker`, `switch`, `tablet`, `ups`, `usbFlashDrive`, `videoConference`, `virtualMachine`, `webcam`. - **Nombre visible**: el nombre que se muestra para el activo. - **Propietario**: la persona o equipo responsable del activo. - **Ubicación**: ubicación física del activo (ej: Barcelona, Madrid). - **Estado**: refleja la fase o condición actual del activo dentro de su ciclo de vida. Es independiente del estado de enrollment que aparece en la sección **Hardware**, que proviene del sistema MDM. Puedes actualizar este campo manualmente en cualquier momento. Valores aceptados: `active`, `inactive`, `provisioning`, `deleted`, `delete_requested`, `retired`, `lost`, `stolen`, `destroyed`, `sold`, `inStock`, `toBeReturned`, `expired`, `inRepair`, `assigned`, `external`, `available`, `damaged`, `emergency`, `unknown`, `disabled`, `returnedToProvider`, `laptopNotRequired`, `personalLaptop`, `clientLaptop`. - **Clasificación**: nivel de criticidad — `low`, `medium` o `high`. - **Descripción**: campo de texto libre para cualquier información adicional o notas sobre el activo. - **Miembros asociados**: el usuario o usuarios asignados a este activo — normalmente alguien de tu organización. Puedes asignar uno o varios empleados. Los usuarios pueden seleccionarse de los registros existentes en Applivery o crearse en el momento. ![inventory fields](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/efd74fcd-2a0f-45a1-96a4-a09b717a05d1.png) ### Hardware Especificaciones técnicas y detalles de enrollment: - **Fabricante**: la marca del dispositivo. - **Modelo**: el nombre o número de modelo específico. - **Número de serie**: el número de serie único del dispositivo. - **IMEI**: identificador único para dispositivos móviles. - **UDID**: identificador único del dispositivo — especialmente útil para dispositivos Apple. - **ID externo**: campo opcional para cualquier identificador externo o de terceros. - **Nombre del SO / Versión del SO**: el nombre y la versión del sistema operativo instalado en el dispositivo. - **Dispositivo enrollado**: indica si el dispositivo está actualmente gestionado por Applivery y su estado de enrollment o aprovisionamiento. Valores posibles: `active`, `deleted`, `delete_requested`, `provisioning`, `unknown`. Este campo se obtiene en tiempo real de Applivery Device Management y no puede editarse manualmente. También incluye un enlace directo al registro del dispositivo y una imagen en miniatura. ### Red Detalles de conectividad de red: - **Nombre de host**: el nombre asignado por la red al dispositivo. - **Dirección IP**: la dirección IP del dispositivo, ya sea estática o dinámica. - **Dirección MAC**: la dirección MAC (Media Access Control) única del dispositivo. ### Compra Información de compra y facturación: - **Proveedor**: el proveedor al que se compró el dispositivo. - **Número de pedido**: el número de referencia del pedido de compra. - **Número de pieza**: el número de pieza o catálogo del dispositivo. - **Precio**: coste del dispositivo, incluyendo la moneda. - **Fecha de pedido**: la fecha de compra. - **Frecuencia**: si es una compra única o un coste recurrente (mensual, anual, etc.). ### Ciclo de vida Seguimiento del ciclo de vida del activo: - **Garantía**: la fecha de vencimiento de la garantía del activo. - **Vida útil esperada**: la vida útil estimada del activo, expresada en meses o años. ### Puestos Útil cuando un activo se comparte entre varias licencias: - **Puestos disponibles**: el número de puestos actualmente disponibles. - **Puestos totales**: el número total de puestos asignados a este activo. ### Metadatos Añade propiedades personalizadas a cualquier elemento del inventario mediante pares clave/valor o directamente en formato JSON. Esto es útil para capturar campos específicos de tu organización que no encajan en las secciones estándar anteriores. ### Notas Campo de texto libre para observaciones, problemas conocidos, historial de escalaciones o cualquier otro contexto adicional. ### Añadir elementos del inventario en bloque La función de importación masiva te permite añadir o actualizar múltiples activos a la vez usando un archivo CSV, sin necesidad de introducirlos uno por uno. Es especialmente útil cuando configuras el inventario por primera vez o sincronizas grandes volúmenes de dispositivos tras una renovación de hardware. Las principales ventajas son: - Ahorra tiempo en la entrada de datos a gran escala. - Minimiza el riesgo de errores manuales. - Admite tanto subidas iniciales como actualizaciones continuas. **Exportar o descargar la plantilla CSV** Haz clic en el botón **Importar** y descarga la plantilla CSV proporcionada. Incluye todos los campos necesarios y el formato correcto para una importación satisfactoria. **Preparar tu archivo CSV** Abre la plantilla en un editor de hojas de cálculo como Microsoft Excel o Google Sheets y rellena los detalles de cada activo que quieras añadir. No cambies los encabezados de las columnas ni dejes filas vacías entre entradas. Cuando termines, guarda el archivo en **formato CSV** para garantizar la compatibilidad. **Cargar el archivo CSV** Vuelve al panel de Importación del inventario en Applivery. Haz clic en **Seleccionar archivo CSV**, elige el archivo que has preparado y súbelo. ![select csv file](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/9c0189fd-6a1b-40c5-8042-12ca0a700698.png) **Revisar y confirmar** Una vez subido el archivo, Applivery mostrará una previsualización de los datos. Revisa la información cuidadosamente para confirmar que todo es correcto y, a continuación, confirma la importación. Applivery procesará el archivo y añadirá o actualizará los elementos en consecuencia. **Verificar los resultados** Tras completar la importación, dirígete a la sección **Inventario** y comprueba que todos los elementos se han añadido o actualizado correctamente. Si alguna entrada se ha omitido o marcado con errores, corrige el archivo CSV y repite el proceso para esas entradas. :::tip Antes de una importación masiva, exporta tu inventario actual como copia de seguridad. Si trabajas con un conjunto de datos muy grande, considera dividirlo en varios archivos CSV para evitar límites de filas o problemas de tiempo de espera. Usa siempre la plantilla oficial de Applivery exactamente como se proporciona — cambiar nombres de columnas o añadir columnas extra puede causar errores de validación durante la importación. ::: :::warning Si desinscribes un dispositivo de Applivery, **no** se eliminará automáticamente del inventario. Solo los elementos creados manualmente o importados mediante CSV pueden eliminarse. Los dispositivos enrollados permanecen en la lista del inventario incluso después de desinscribirlos. ::: --- ## Plataforma Source: https://docs.applivery.com/es/platform/ Description: Ajustes de administración, roles, facturación y gestión de la organización en Applivery. TL;DR: La sección Plataforma cubre todos los ajustes de administración transversal de Applivery: Workspaces, roles, autenticación, facturación y API. Answers: ¿Qué cubre la sección Plataforma de Applivery? · ¿Dónde configuro los roles y permisos en Applivery? · ¿Cómo configuro el SSO en Applivery? · ¿Dónde gestiono la facturación de mi Workspace? · ¿Cómo accedo a la API de Applivery? Key topics: Gestión del Workspace, Roles y permisos, Autenticación y SSO, API de la plataforma, Applivery, Workspace, SSO, API La sección Plataforma cubre la capa de administración transversal de Applivery — los ajustes y herramientas que se aplican tanto a la Distribución de Apps como a la Gestión de Dispositivos. Incluye la configuración del Workspace y la organización, los roles y permisos de usuario, la autenticación, la facturación y la API de la plataforma. Tanto si estás configurando un nuevo Workspace, como si quieres configurar el SSO, gestionar el acceso de los Colaboradores o crear integraciones con la API de Applivery, este es el lugar por donde empezar. --- ## API Source: https://docs.applivery.com/es/platform/api/ Description: API de la plataforma Applivery — gestiona Cuentas de servicio, autenticación y control de acceso para la integración programática con tus sistemas. TL;DR: La API de Applivery permite la interacción programática con la plataforma mediante Cuentas de servicio, autenticación con token Bearer y una referencia completa de la API. Answers: ¿Cómo me autentico con la API de Applivery? · ¿Qué son las Cuentas de servicio en Applivery? · ¿Dónde encuentro la referencia de la API de Applivery? · ¿Cómo integro mis sistemas con la API de Applivery? · ¿Qué formatos de solicitud admite la API? Key topics: API, Cuentas de servicio, Autenticación, Referencia de la API, Integración, Applivery La API de Applivery te permite interactuar programáticamente con la plataforma — creando Cuentas de servicio para la autenticación segura y usando los endpoints disponibles para automatizar tareas en la Distribución de Apps y la Gestión de Dispositivos. Gestiona las Cuentas de servicio y consulta la referencia completa de la API, con detalles sobre endpoints, formatos de solicitud y ejemplos de respuesta. --- ## Cuentas de servicio Source: https://docs.applivery.com/es/platform/api/service-accounts/ Description: Cuentas de servicio de Applivery para acceso a la API seguro y automatizado — roles, permisos y buenas prácticas para la gestión de tokens. TL;DR: Las Cuentas de servicio de Applivery permiten el acceso a la API seguro y automatizado para entidades no humanas usando tokens Bearer y permisos a nivel de Workspace. Answers: ¿Qué es una Cuenta de servicio de Applivery? · ¿Cómo se autentican las Cuentas de servicio? · ¿Cuándo debo usar una Cuenta de servicio en lugar de un App API Token? · ¿Qué roles puedo asignar a una Cuenta de servicio? · ¿Cómo creo una Cuenta de servicio en Applivery? Key topics: Creación de Cuentas de servicio, Roles y permisos, Uso del token Bearer, Almacenamiento seguro de tokens, Cuenta de servicio vs App API Token, Applivery, Workspace API, BrowserStack App Live, GitHub Actions, Azure Pipelines, Bitrise, Jenkins Una Cuenta de servicio es un tipo especial de cuenta de Applivery diseñada para la autenticación no humana, de máquina a máquina. A diferencia de las cuentas de usuario, que están vinculadas a una persona, una Cuenta de servicio representa un sistema automatizado, una integración o un pipeline que necesita interactuar con la API de Applivery por su propia cuenta. Las Cuentas de servicio se autentican contra la **Workspace API** (API de Organizaciones) usando un token Bearer. Esto les da acceso a nivel de Workspace a los recursos de todas las apps y módulos de tu organización, lo que las convierte en las credenciales adecuadas para la automatización transversal de apps y las integraciones a nivel de plataforma. * * * ### Cuentas de servicio vs. App API Tokens Applivery tiene dos mecanismos de autenticación distintos. Elegir el correcto para tu caso de uso es importante: | | Cuenta de servicio | App API Token | | --- | --- | --- | | **Ámbito** | A nivel de Workspace — todas las apps de la organización | Solo una app | | **Se usa para** | Workspace API (API de Organizaciones) | API de Integraciones (subida por app, Publicaciones, Builds) | | **Casos de uso típicos** | Automatización transversal de apps, BrowserStack App Live, scripts a nivel de Workspace | Subidas de Builds desde CI/CD, integraciones por app | | **Formato del token** | Token Bearer | Cadena de App Token | | **Se crea en** | Ajustes del Workspace → Cuentas de servicio | Ajustes de la app → API Tokens | Si necesitas subir Builds desde un pipeline de CI/CD para una sola app, usa un [App API Token](https://docs.applivery.com/es/app-distribution/api/app-api-token/). Si necesitas consultar o gestionar recursos en múltiples apps, o conectar una plataforma de terceros como BrowserStack App Live, usa una Cuenta de servicio. * * * ### Roles y permisos Al crear una Cuenta de servicio, le asignas uno de tres roles. El rol determina qué operaciones puede realizar la Cuenta de servicio en todo el Workspace: | Rol | Descripción | | --- | --- | | **Admin** | Acceso completo a todos los recursos y ajustes del Workspace. Puede crear, modificar y eliminar cualquier recurso. | | **Editor** | Acceso de lectura y escritura a los recursos de la app (Builds, Publicaciones, configuraciones). No puede gestionar los ajustes del Workspace ni otros usuarios. | | **Visualizador** | Acceso de solo lectura a los recursos del Workspace. No puede crear ni modificar ningún dato. | :::tip Sigue el principio de mínimo privilegio: asigna el rol más restrictivo que permita a la Cuenta de servicio realizar su función prevista. ::: * * * ### Crear una Cuenta de servicio Las Cuentas de servicio se gestionan desde los Ajustes del Workspace. Solo los usuarios con permisos de **Admin** pueden crear o eliminar Cuentas de servicio. En el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a los **Ajustes del Workspace** 1 desde el menú desplegable superior, luego abre **Cuentas de servicio** 2 en el menú de la izquierda y haz clic en el botón **\+ Crear Cuenta de Servicio** 3. ![Service Account](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/7b329256-a6af-40b1-a101-837f11ca1866.png) Introduce un nombre descriptivo para la cuenta (ej: `ci-pipeline`, `browserstack-integration`) y selecciona un **Rol**: Admin, Developer o Viewer. Una vez listo, haz clic en **Crear**. :::warning Recuerda que también tendrás que conceder permisos a la Cuenta de servicio según el segmento en el que quieras usarla. Puedes leer más sobre la asignación de permisos basada en segmentos en el siguiente [enlace](https://docs.applivery.com/es/device-management/general-settings/segments/#cómo-crear-segmentos-y-permisos). ::: Se mostrarán los detalles de la Cuenta de servicio: | Campo | Descripción | | --- | --- | | **Cuenta** | El identificador de la Cuenta de servicio, con el formato `{service-account-id}@{organization-id}.iam.applivery.io` | | **Token Bearer** | El token de autenticación utilizado en las solicitudes a la API. | :::warning Copia el token Bearer de inmediato. Por razones de seguridad, Applivery no vuelve a mostrar el token completo después de salir de esta pantalla. Si pierdes el token, tendrás que eliminar la Cuenta de servicio y crear una nueva. ::: * * * ### Usar el token Bearer en las solicitudes a la API Incluye el token Bearer en la cabecera `Authorization` de cada solicitud a la Workspace API: ```bash curl 'https://api.applivery.io/v1/organizations/{organizationId}/...' \ -H 'Authorization: Bearer YOUR_SERVICE_ACCOUNT_TOKEN' ``` Sustituye `YOUR_SERVICE_ACCOUNT_TOKEN` por el token copiado durante la creación, y `{organizationId}` por el identificador de tu organización. * * * ### Almacenar el token de forma segura El token Bearer concede acceso a nivel de Workspace. Trátalo como una contraseña: - **Nunca lo confirmes en el control de versiones.** Guárdalo como secreto en tu plataforma de CI/CD, gestor de secretos o variable de entorno. - **Una Cuenta de servicio por integración.** Crea una Cuenta de servicio separada para cada sistema externo (ej: una para BrowserStack, otra para un script de automatización del Workspace). Esto limita el impacto si un token se ve comprometido y facilita su rotación sin afectar a otros sistemas. - **Rota los tokens periódicamente.** Elimina y recrea las Cuentas de servicio como parte de tu política regular de rotación de credenciales. **Plataformas de CI/CD — dónde guardar el token:** | Plataforma | Dónde guardar | | --- | --- | | GitHub Actions | Secreto del repositorio o de la organización | | Azure Pipelines | Variable del pipeline (secreto) | | Bitrise | Secreto (con el toggle Protegido activado) | | Jenkins | Credencial de Jenkins (texto secreto) | * * * ### Gestionar las Cuentas de servicio existentes Todas las Cuentas de servicio de tu Workspace aparecen en la sección **Cuentas de servicio** de los **Ajustes del Workspace**. Desde esta vista puedes: - **Ver** el identificador de la cuenta y el rol de cada Cuenta de servicio. - **Eliminar** una Cuenta de servicio para revocar su acceso de inmediato. Cualquier sistema que use el token de la cuenta eliminada recibirá errores `401 Unauthorized` en las solicitudes posteriores. No hay forma de recuperar o regenerar un token de una Cuenta de servicio existente. Si un token necesita reemplazarse, elimina la cuenta y crea una nueva. * * * ### Dónde se requieren las Cuentas de servicio Las siguientes funciones e integraciones de Applivery se autentican mediante el token Bearer de una Cuenta de servicio: | Función | Motivo | | --- | --- | | Workspace API (API de Organizaciones) | Todos los endpoints de la Workspace API requieren autenticación con Cuenta de servicio. | | Integración BrowserStack App Live | App Live se conecta a tu Workspace de Applivery usando el token Bearer de una Cuenta de servicio. | | Scripts de automatización transversal de apps | Cualquier script que lee o escribe datos en múltiples apps necesita acceso a nivel de Workspace. | --- ## Autenticación Source: https://docs.applivery.com/es/platform/authentication/ Description: Control de acceso seguro en Applivery con SSO (SAML, Okta, Azure AD, Ping Identity), LDAP y 2FA — centraliza la gestión de identidades de usuario. TL;DR: Applivery soporta SSO (SAML, LDAP) y 2FA para un control de acceso seguro y centralizado de las identidades de usuario. Answers: ¿Qué métodos de autenticación admite Applivery? · ¿Cómo configuro el SSO en Applivery? · ¿Admite Applivery la autenticación de doble factor (2FA)? · ¿Es compatible Applivery con LDAP? · ¿Qué proveedores de identidad son compatibles con el SSO de Applivery? Key topics: Single Sign-On (SSO), Autenticación de doble factor (2FA), Gestión de identidades, Okta, Azure AD, Ping Identity, SAML, LDAP La autenticación controla cómo acceden los Colaboradores y los usuarios de la Store de Applivery. La plataforma admite múltiples métodos de autenticación: SSO via SAML con proveedores como Okta, Azure AD y Ping Identity; autenticación basada en LDAP; y autenticación de doble factor (2FA) para mayor seguridad. Configura cada método de autenticación para tu organización y descubre cómo interactúan con el aprovisionamiento de usuarios y el control de acceso. --- ## Autenticación de doble factor (2FA) Source: https://docs.applivery.com/es/platform/authentication/2fa/ Description: Protege tu cuenta de Applivery con la autenticación de doble factor (2FA) — activa, configura y gestiona el 2FA para mejorar la seguridad del acceso. TL;DR: Activa la autenticación de doble factor en Applivery para añadir una capa extra de seguridad a tu cuenta usando una app de autenticación. Answers: ¿Qué es la autenticación de doble factor de Applivery? · ¿Qué apps de autenticación funcionan con Applivery? · ¿Cómo activo el 2FA en mi cuenta de Applivery? · ¿Qué hago si no puedo escanear el código QR para activar el 2FA? · ¿Cómo desactivo el 2FA en Applivery? Key topics: Activar el 2FA, Iniciar sesión con el 2FA, Desactivar el 2FA, Apps de autenticación, Applivery, Google Authenticator, Microsoft Authenticator, TOTP, WebAuthn, YubiKey La autenticación de doble factor añade una segunda capa de seguridad a tu cuenta de Applivery. Aunque alguien consiga tu contraseña, no podrá acceder a tu cuenta sin tener también el código de un solo uso generado en tu móvil. Una vez activado, todos los inicios de sesión en el panel de Applivery o el Enterprise Store requerirán tanto tu contraseña como un código de tu app de autenticación. Applivery usa **TOTP (Time-Based One-Time Password)** — el mismo estándar que usan Google, GitHub y la mayoría de plataformas modernas. Cualquier app de autenticación compatible funcionará, incluyendo Google Authenticator y Microsoft Authenticator. **Google Authenticator** Disponible para iOS y Android. **Microsoft Authenticator** Disponible para iOS y Android. :::tip Una vez configurado el TOTP, también puedes añadir una llave de seguridad física (lector de huellas dactilares, Windows Hello o una llave física como YubiKey) como autenticador adicional. Esto usa [WebAuthn](https://webauthn.io/), el estándar moderno compatible con todos los navegadores principales. ::: * * * ### Activar el 2FA En el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a la **configuración de tu cuenta** desde el menú desplegable superior y selecciona **Seguridad** en el menú de la izquierda. Haz clic en **Activar 2FA** para iniciar la configuración. Abre tu app de autenticación y escanea el código QR que aparece en pantalla. Si no puedes escanear el código QR, pulsa la opción para introducirlo manualmente — Applivery mostrará la clave alfanumérica que puedes escribir directamente. Tu app de autenticación creará una nueva entrada llamada _Applivery:_ [_tu@correo.com_] y empezará a generar códigos de 6 dígitos que se renuevan cada 30 segundos. Introduce el código actual de tu app en el campo de confirmación en pantalla y haz clic en **Activar** antes de que el código caduque. Aparecerá un mensaje de confirmación cuando el 2FA esté activo en tu cuenta. ![enable 2fa](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/451971e7-6b2b-4faf-8c3b-51e744ec240b.png) :::info Applivery envía una notificación por correo cada vez que se realiza un cambio de seguridad en tu cuenta — incluyendo la activación o desactivación del 2FA. Si recibes uno de estos correos de forma inesperada, cambia tu contraseña de inmediato y contacta con soporte en [support@applivery.com](mailto:support@applivery.com). ::: * * * ### Iniciar sesión con el 2FA Tras activar el 2FA, cada inicio de sesión tendrá un segundo paso. Una vez que introduces tu correo y contraseña, Applivery te pedirá un código de un solo uso. Abre tu app de autenticación, copia el código actual de 6 dígitos para la entrada de Applivery e introdúcelo antes de que caduque. ![request 2fa](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/cccf0347-02bc-4a1d-a851-09f50896f919.png) * * * ### Desactivar el 2FA :::warning Recomendamos encarecidamente mantener el 2FA activo en todo momento. Desactivarlo reduce la seguridad de tu cuenta. ::: Si necesitas desactivar el 2FA, dirígete a la **configuración de tu cuenta** desde el menú desplegable superior, selecciona **Seguridad** en el menú de la izquierda y haz clic en **Desactivar** junto a Autenticación de doble factor. Por razones de seguridad, Applivery te pedirá que confirmes tu contraseña actual antes de aplicar el cambio. ![disable 2fa](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/03b7d218-d840-4e70-9f90-1b79b18d2e06.png) --- ## SSO Source: https://docs.applivery.com/es/platform/authentication/sso/ Description: SSO en Applivery — SAML, LDAP y SCIM para una gestión de identidades segura y simplificada, con variables de datos de usuario. TL;DR: El SSO de Applivery simplifica la autenticación a través del proveedor de identidad de tu organización. Soporta SAML, LDAP y SCIM, más variables de datos de usuario para automatización. Answers: ¿Qué es el SSO (Single Sign-On)? · ¿Qué métodos de autenticación admite Applivery para el SSO? · ¿Qué es SCIM y cómo se relaciona con el SSO? · ¿Cómo mejora la seguridad el SSO? · ¿Qué son las variables de datos de usuario SSO? · ¿Puedo combinar variables SSO para crear valores dinámicos? · ¿Admite Applivery LDAP para SSO? · ¿El SSO requiere un plan premium? Key topics: SSO, SAML, LDAP, Proveedores de identidad, SCIM, Variables SSO, Autenticación, Okta, Azure AD, Ping Identity El Single Sign-On (SSO) permite a tu equipo autenticarse en Applivery usando el proveedor de identidad existente de tu organización, eliminando la necesidad de credenciales separadas. Applivery soporta varios métodos de SSO para adaptarse a diferentes configuraciones organizativas e infraestructuras de identidad. ### Métodos de SSO disponibles Google Authentication está habilitado por defecto en todas las cuentas de Applivery y no requiere configuración adicional. **SAML 2.0** Se integra con proveedores de identidad empresariales como Azure AD, Okta, Ping Identity y cualquier otra plataforma compatible con SAML 2.0, para autenticación centralizada y aprovisionamiento automatizado de usuarios mediante SCIM. **LDAP** Conecta tu servidor de directorio LDAP existente a Applivery, permitiendo la autenticación y la gestión de usuarios directamente desde tu directorio corporativo. ### Variables de datos de usuario SSO Cuando el SSO está configurado, el proveedor de identidad comparte datos de usuario que puedes referenciar mediante variables de plantilla. Son útiles para automatizar campos de formularios y rellenar valores durante la inscripción de dispositivos o flujos de creación de cuentas. | Variable | Descripción | |---|---| | `{{sso.firstname}}` | Nombre del usuario | | `{{sso.lastname}}` | Apellido del usuario | | `{{sso.username}}` | Nombre de usuario | | `{{sso.email}}` | Dirección de correo electrónico completa | | `{{sso.email.username}}` | Parte del nombre de usuario del correo electrónico | Las variables pueden combinarse para crear valores dinámicos. Por ejemplo, `{{sso.firstname}}.{{sso.lastname}}` genera un valor como `daniel.garcia` — útil para la creación automatizada de cuentas en escenarios de gestión de dispositivos macOS. Configura el SSO y el SCIM para tu proveedor de identidad, con guías de configuración paso a paso e instrucciones para el mapeo de roles. --- ## SCIM para Azure AD Source: https://docs.applivery.com/es/platform/authentication/sso/azure-ad-scim/ Description: Configura el SCIM con Applivery y Microsoft Entra ID para el aprovisionamiento automatizado de usuarios y grupos y la gestión centralizada de identidades. TL;DR: Automatiza el aprovisionamiento de usuarios y grupos en Applivery con SCIM y Microsoft Entra ID para una gestión de identidades eficiente. Answers: ¿Qué es el SCIM y cómo funciona con Applivery? · ¿Cómo se relaciona el SCIM con el SSO SAML en Applivery? · ¿Qué recursos puede gestionar el SCIM en Applivery? · ¿Cómo activo el SCIM en Applivery? · ¿Cómo funciona el mapeo de roles para los Colaboradores del Dashboard aprovisionados mediante SCIM? Key topics: Configuración SCIM, Integración con Microsoft Entra ID, Automatización del aprovisionamiento de usuarios, Mapeo de roles, Portales de Applivery, SCIM, Applivery, Microsoft Entra ID, SAML :::warning Esta es una función premium que puede no estar disponible en tu plan actual. Comprueba la disponibilidad en la [página de precios de Applivery](https://www.applivery.com/pricing/). ::: **SCIM (System for Cross-domain Identity Management)** es un estándar abierto que automatiza el aprovisionamiento de usuarios y grupos en los servicios en la nube. En lugar de gestionar usuarios manualmente en Applivery, el SCIM permite a Microsoft Entra ID enviar información de usuarios y grupos automáticamente — creando, actualizando y desactivando usuarios y manteniendo las membresías de grupos sincronizadas sin ninguna intervención manual. Cuando se combina con el SSO SAML, el SCIM gestiona el lado del _aprovisionamiento_ de la gestión de identidades. SAML autentica a los usuarios cuando inician sesión, mientras que el SCIM mantiene continuamente el directorio de usuarios y la estructura de grupos en Applivery actualizada. Un aspecto clave: **la gestión de grupos mediante SCIM es completamente independiente de SAML** — los grupos enviados mediante SCIM existen en Applivery como objetos de primer nivel antes de que ningún usuario inicie sesión, y no requieren ninguna configuración adicional de grupos en el lado de SAML. :::tip El SCIM funciona sobre una integración SSO SAML existente. Si aún no la has configurado, empieza primero con la guía de [Single Sign-On con Azure AD](https://docs.applivery.com/es/platform/authentication/sso/azure-ad/). ::: * * * ### Qué gestiona el SCIM en Applivery El SCIM puede gestionar tres tipos de recursos en Applivery, cada uno con un comportamiento de aprovisionamiento diferente según el portal que configures. **Store Enterprise** Cuando el SCIM está configurado para el **Store Enterprise**, Applivery puede crear o eliminar cuentas de empleados automáticamente en respuesta a cambios en Entra ID. Cuando se crea un usuario en Entra ID, puedes elegir no hacer nada o crearlo automáticamente como empleado. Cuando se desactiva, puedes elegir no hacer nada o eliminarlo de Applivery. **Dashboard** Cuando el SCIM está configurado para el **Dashboard**, Applivery gestiona las cuentas de Colaboradores. Cuando se crea un usuario en Entra ID, puedes elegir no hacer nada o crearlo como Colaborador con un rol predeterminado (Admin, Developer/Editor o Viewer). Cuando se desactiva, puedes no hacer nada o eliminarlo como Colaborador. El rol inicial asignado en la creación puede sobreescribirse mediante el mapeo de roles basado en grupos — consulta [Mapeo de roles](#mapeo-de-roles) más abajo. **MDM Portal** Cuando el SCIM está configurado para el **MDM Portal**, Applivery ofrece las opciones de desactivación más granulares. Cuando se crea un usuario en Entra ID, puedes no hacer nada o crearlo como empleado MDM. Cuando se desactiva, tienes cinco opciones: no hacer nada, desasignar al usuario de sus dispositivos, cambiar la política de sus dispositivos asignados, eliminar al usuario, o eliminar al usuario y todos sus dispositivos asociados. * * * ### Configuración del SCIM **Activar el SCIM en Applivery** En el panel de Applivery dirígete a los **Ajustes del Workspace** desde el menú desplegable superior y abre **Proveedores de acceso** en el menú de la izquierda. Encuentra la fila **SAML** y haz clic en **Configurar** para el portal que quieras proteger — **Dashboard**, **Store Enterprise** o **MDM Portal**. Desplázate hasta el final de la pantalla de configuración SAML y haz clic en **Activar SCIM**. Applivery generará una **URL base** y un **token Bearer**. Copia ambos — los necesitarás al configurar Entra ID. Las opciones de comportamiento del aprovisionamiento (qué ocurre cuando se crea o desactiva un usuario) también están disponibles aquí, específicas para el portal seleccionado. **Registrar una aplicación empresarial en Entra ID** En el [centro de administración de Microsoft Entra](https://entra.microsoft.com), sigue los pasos descritos [aquí](https://docs.applivery.com/es/platform/authentication/sso/azure-ad/) para crear tu nueva aplicación. **Configurar la conexión SCIM** Dentro de la aplicación recién creada, abre la sección **Aprovisionamiento** y haz clic en **Comenzar**. Establece el **Modo de aprovisionamiento** en **Automático** y rellena las credenciales de administrador: | Campo | Valor | | --- | --- | | **URL del tenant** | La URL base generada por Applivery. | | **Token secreto** | El token Bearer generado por Applivery. | ![provisioning scim](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/80f3196d-8aef-445d-b7ab-7c67bb9a7409.png) Haz clic en **Probar conexión** para verificar que las credenciales son correctas y luego en **Guardar**. Si la prueba falla, comprueba que el endpoint SCIM está activado en Applivery y que el token no se ha regenerado desde que lo copiaste. **Configurar el ámbito de aprovisionamiento y activar** Después de guardar las credenciales, vuelve a los ajustes de aprovisionamiento y establece el **Ámbito** en **Sincronizar solo usuarios y grupos asignados** — esto garantiza que Entra ID solo envíe los usuarios y grupos que están explícitamente asignados a esta aplicación, en lugar de todo tu directorio. Luego activa el **Estado del aprovisionamiento** en **Activado**. ![scope and settings](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/8cf9c064-eb8f-4e1a-820a-ff6ecee15edf.png) **Crear usuarios y grupos en Entra ID** Si los usuarios y grupos que quieres aprovisionar aún no existen en Entra ID, créalos ahora. Para crear un usuario, dirígete a **Usuarios → Nuevo usuario → Crear nuevo usuario**, completa los campos requeridos y haz clic en **Revisar + crear**. Para crear un grupo dirígete a **Grupos → Nuevo grupo**, dale un nombre y descripción y haz clic en **Crear**. Una vez creado el grupo, ábrelo, dirígete a **Miembros → Agregar miembros**, busca los usuarios que quieres incluir y confirma. Si tus usuarios y grupos ya existen en Entra ID, puedes omitir este paso. **Asignar usuarios y grupos a la aplicación SCIM** Entra ID solo aprovisiona los usuarios y grupos que están asignados explícitamente a la aplicación. Ve a **Aplicaciones empresariales → tu aplicación SCIM → Usuarios y grupos** y haz clic en **Agregar usuario/grupo**. Busca y selecciona los grupos (o usuarios individuales) que quieres aprovisionar en Applivery y haz clic en **Asignar**. Una vez asignados, el siguiente ciclo de aprovisionamiento automático — que normalmente se ejecuta cada 40 minutos — sincronizará los usuarios y grupos seleccionados con Applivery. :::tip En general, es preferible asignar grupos en lugar de usuarios individuales. Cuando se asigna un grupo, todos sus miembros se aprovisionan automáticamente, y cualquier cambio futuro en las membresías de Entra ID se reflejará en Applivery en el siguiente ciclo de sincronización. ::: * * * ### Aprovisionamiento a petición En lugar de esperar al ciclo de sincronización programado, puedes enviar cambios a Applivery inmediatamente usando el **Aprovisionamiento a petición**. Esto es especialmente útil al incorporar nuevos usuarios o probar tu configuración de aprovisionamiento sin esperar hasta 40 minutos para la siguiente ventana automática. Ve a **Aplicaciones empresariales → tu aplicación SCIM → Aprovisionamiento → Aprovisionamiento a petición**. Busca el usuario o grupo que quieres sincronizar inmediatamente y selecciónalo, luego haz clic en **Aprovisionar**. :::warning Al aprovisionar un grupo a petición, Entra ID requiere que también selecciones explícitamente los miembros individuales del grupo — aparecen listados bajo **Ver solo miembros** en la interfaz de selección. Seleccionar solo el grupo no es suficiente para el flujo a petición; el ciclo de aprovisionamiento programado sí lo gestiona automáticamente. ::: * * * ### Mapeo de roles Cuando el SCIM está configurado para el **Dashboard**, puedes mapear grupos de Entra ID a roles de Colaborador de Applivery. Si se está aprovisionando un usuario por primera vez — es decir, aún no existe en Applivery — su rol se determina por los grupos a los que pertenece en Entra ID: | Nombre del grupo en Entra ID | Rol en Applivery | | --- | --- | | `applivery-admin` | Admin | | `applivery-editor` | Developer / Editor | | `applivery-viewer` | Viewer | | `applivery-unassigned` | Sin asignar | Si un usuario pertenece a más de uno de estos grupos, el rol de mayor privilegio tiene prioridad. Si el usuario no pertenece a ninguno de estos grupos, se crea sin rol y un administrador tendrá que asignárselo manualmente. :::info El mapeo de roles mediante SAML y SCIM solo aplica a **App Distribution**. Los permisos de Device Management se rigen exclusivamente por los [permisos de segmentos](https://docs.applivery.com/es/device-management/general-settings/segments/). ::: --- ## Azure AD Source: https://docs.applivery.com/es/platform/authentication/sso/azure-ad/ Description: Integra Applivery con Azure AD mediante SAML para el Single Sign-On — configura Microsoft Entra ID como tu proveedor de identidad. TL;DR: Integra Applivery con Azure AD para el Single Sign-On (SSO) mediante SAML intercambiando metadatos y configurando los mapeos de grupos de usuarios. Answers: ¿Qué se necesita para configurar el SSO de Microsoft Entra ID con Applivery? · ¿Cómo obtengo los metadatos SAML de Applivery? · ¿Cómo creo la aplicación empresarial en Entra ID? · ¿Cómo asigno usuarios a la aplicación de Applivery en Entra ID? · ¿Por qué los grupos de seguridad de Azure aparecen como Object IDs en Applivery? · ¿Cómo mapeo los Object IDs de grupos de Azure a nombres de grupo en Applivery? · ¿Cómo activo el mapeo de roles desde grupos de Azure a Applivery? Key topics: Azure AD, SAML, Single Sign-On, Integración con Applivery, Grupos de seguridad de Azure, Applivery, Microsoft Entra ID, Microsoft 365 :::warning Esta es una función premium que puede no estar disponible en tu plan actual. Comprueba la disponibilidad en la [página de precios de Applivery](https://www.applivery.com/pricing/). ::: Una vez configurado, los miembros de tu organización pueden acceder al panel de Applivery, al Store Enterprise o al MDM Portal usando sus credenciales de Microsoft 365 — sin necesidad de una contraseña separada de Applivery. El flujo funciona en dos direcciones: primero exportas los metadatos del proveedor de servicios de Applivery e importas en Entra ID; luego exportas los metadatos del proveedor de identidad de Entra ID y los importas de vuelta en Applivery. El mapeo de grupos de seguridad de Azure — que tiene una particularidad única frente a otros IdPs — se explica al final. :::info Si planeas usar un dominio personalizado para tu Store Enterprise o MDM Portal, configúralo en Applivery **antes** de configurar el SSO. Los dominios personalizados cambian las URLs de callback incluidas en los metadatos SAML, por lo que el orden importa. ::: * * * ### Requisitos previos Necesitas acceso de administrador a tu Workspace de Applivery, y acceso de Administrador Global o Administrador de Aplicaciones al [centro de administración de Microsoft Entra](https://entra.microsoft.com/). Si usas un dominio personalizado, asegúrate de configurarlo primero en Applivery en la sección Ajustes, navegando a Personalización de la tienda en el menú de la izquierda. * * * ### Configuración **Obtener los metadatos del proveedor de servicios de Applivery** En el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a la **Ajustes del Workspace** desde el menú desplegable superior y abre **Proveedores de acceso** en el menú de la izquierda. Encuentra la fila **SAML** y haz clic en **Configurar** para el portal que quieras proteger — **Dashboard**, **Store Enterprise** o **MDM Portal**. Cada portal se configura de forma independiente. En la pantalla de configuración SAML, tienes dos opciones según la configuración de tu Entra ID: **Cargar archivo de metadatos (recomendado)** Haz clic en **Descargar metadatos** para obtener el archivo **XML de metadatos SAML**. Esta es la opción más rápida — cargarlo a Entra ID rellenará todos los campos requeridos automáticamente. **Configuración manual** Si tu tenant de Entra ID no admite la subida de metadatos, usa los valores individuales mostrados en pantalla: | Campo | Descripción | | --- | --- | | **Identificador (Entity ID)** | Identificador único de Applivery como proveedor de servicios. | | **URL de respuesta (ACS URL)** | Donde Entra ID enviará la respuesta SAML tras la autenticación. | | **URL de callback** | La URL a la que llegan los usuarios tras un inicio de sesión exitoso. | **Crear una aplicación empresarial en Entra ID** En el [Portal de Azure](https://portal.azure.com/), dirígete a **Microsoft Entra ID → Aplicaciones empresariales** y haz clic en **\+ Nueva aplicación**. ![microsoft entra id](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/5f8e775e-a1c1-4d91-a9f9-341dbc9fd2fe.png) Selecciona **Crear tu propia aplicación**, dale un nombre (p. ej. `Applivery`), elige **Integrar cualquier otra aplicación que no encuentres en la galería (Non-gallery)** y haz clic en **Crear**. ![create your own app](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/5d29afbf-0d9c-4b94-86d4-732460a05f72.png) **Configurar el SSO con SAML en Entra ID** Dentro de la aplicación, dirígete a **Configurar inicio de sesión único** en el menú de la izquierda y selecciona **SAML**. En la parte superior de la página de configuración, haz clic en **Cargar archivo de metadatos** y selecciona el archivo XML que descargaste de Applivery — los campos requeridos se rellenarán automáticamente. ![upload metadata file](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/60f0eafe-5aed-460d-b12c-310cd09120ae.png) Si configuras manualmente, completa la **Sección 1 – Configuración básica de SAML** con los valores de Identificador, URL de respuesta y URL de inicio de sesión de Applivery y haz clic en **Guardar**. **Asignar usuarios o grupos** Antes de que alguien pueda acceder mediante SSO, debe estar asignado a la aplicación en Entra ID. Ve a **Usuarios y grupos** en el menú de la izquierda, haz clic en **\+ Agregar usuario/grupo**, selecciona los usuarios o grupos que deben tener acceso a Applivery y haz clic en **Asignar**. **Descargar los metadatos del proveedor de identidad de Entra ID** Vuelve a **Inicio de sesión único** en tu aplicación. En la **Sección 3 – Certificados SAML**, haz clic en el enlace **Descargar** junto a **XML de metadatos de federación** y guarda el archivo — lo cargarás a Applivery en el siguiente paso. ![saml certificates](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/1ebb5e6a-59a4-4793-b904-9bf575eedc49.png) **Completar la configuración en Applivery** Vuelve a la pantalla de configuración SAML de Applivery del mismo portal que empezaste en el Paso 1. Sube el archivo **XML de metadatos de federación** de Entra ID, haz clic en **Guardar cambios** y luego usa el interruptor para **activar** la integración. **Probar la integración** Con todo guardado y activado, prueba con un usuario asignado. Para el Dashboard, dirígete a [https://dashboard.applivery.io/welcome/sso](https://dashboard.applivery.io/welcome/sso), introduce el correo del usuario y serás redirigido a Microsoft para autenticarte. Para el Store Enterprise o el MDM Portal, accede directamente a la URL del portal — la redirección SSO se producirá automáticamente. * * * ### Mapeo de grupos de seguridad de Azure A diferencia de la mayoría de proveedores de identidad, **Azure Entra ID no envía nombres de visualización de grupos en las aserciones SAML — envía Object IDs (GUIDs)**. Esto significa que, sin configuración adicional, los grupos que recibe Applivery parecen `89f3b2c1-4a7e-4d91-...` en lugar de `engineering` o `qa-team`. Para que los grupos sean útiles para los filtros de Publicaciones y el mapeo de roles, necesitas hacer dos cosas: activar las notificaciones de grupo en Entra ID para que la aserción las incluya, y luego mapear los Object IDs a nombres legibles en Applivery. #### Activar las notificaciones de grupo en Entra ID En tu aplicación empresarial, dirígete a **Inicio de sesión único** y edita la configuración de **Atributos y notificaciones**. Haz clic en el botón **\+ Agregar notificación de grupo** y selecciona **Grupos de seguridad** (o **Todos los grupos** si es necesario), establece el **Atributo de origen** en `ID de grupo` y asegúrate de que el esquema de la notificación es: ``` http://schemas.microsoft.com/ws/2008/06/identity/claims/groups ``` ![user attributes and claims](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/82fccbeb-c237-4493-88db-55b763810b52.png) Guarda los cambios. Entra ID incluirá ahora los Object IDs de los grupos de seguridad en cada aserción SAML. #### Mapear Object IDs a nombres de grupo en Applivery En el panel de Applivery dirígete a tu configuración **SAML**. Para cada grupo de seguridad de Azure, añade una entrada de mapeo con el **Object ID** del grupo como clave y el nombre de grupo de Applivery deseado como valor. ![group translation](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/62681408-4af1-47c4-99b8-9a22055247eb.png) Puedes encontrar los Object IDs en **Microsoft Entra ID → Grupos** — abre cada grupo y copia el campo **Object ID**. ![](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/73db51a7-2a6f-4c92-a027-36fde2146ea6.png) :::tip No necesitas preconfigurar todos los grupos antes de activar la integración. Applivery detecta automáticamente los nuevos Object IDs a medida que los usuarios se autentican y los añade a la lista de mapeo como marcadores de posición. Puedes asignarles nombres legibles en cualquier momento después de que la integración esté activa. ::: * * * ### Mapeo de roles desde grupos de Azure Si configuras el portal del Dashboard y quieres que los grupos de seguridad de Azure asignen automáticamente roles de Colaborador de Applivery a los nuevos usuarios, necesitas enviar los **nombres de visualización** de los grupos en lugar de los Object IDs — para que Applivery pueda compararlos directamente con los nombres de grupos de roles reservados (`applivery-admin`, `applivery-editor`, etc.). En la sección **Atributos de usuario y notificaciones** de tu aplicación Entra ID, edita la notificación del grupo y establece el **Atributo de origen** en **Nombres de visualización de grupos solo en la nube** en lugar de `ID de grupo`. Con esto, Applivery puede asignar roles en el primer inicio de sesión sin necesitar ningún mapeo de Object ID → nombre. ![group claims](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/cdda8163-d252-4bea-b8da-23a25d19ba3d.webp) :::note El mapeo de roles solo aplica al módulo de **Distribución de Apps**. Los permisos de Gestión de Dispositivos se rigen exclusivamente por los [permisos de segmentos](https://docs.applivery.com/es/device-management/general-settings/segments/). ::: --- ## LDAP Source: https://docs.applivery.com/es/platform/authentication/sso/ldap/ Description: Integra Applivery con tu servidor LDAP para la autenticación segura de usuarios en la Distribución de Apps y Gestión de Dispositivos. TL;DR: Integra Applivery con tu servidor LDAP para habilitar la autenticación segura de usuarios en Distribución de Apps y Gestión de Dispositivos usando credenciales corporativas existentes. Answers: ¿Qué es el LDAP y cómo funciona con Applivery? · ¿Qué módulos de Applivery admiten la autenticación LDAP? · ¿Qué información necesito de mi administrador LDAP para configurar Applivery? · ¿Cuál es la dirección IP de Applivery que debe añadirse a la lista de permitidos? · ¿Qué es el Bind DN y qué permisos necesita? · ¿Cómo usa Applivery los grupos LDAP? · ¿Con qué frecuencia se sincronizan los grupos LDAP con Applivery? Key topics: Autenticación LDAP, Integración con Distribución de Apps, Integración con Gestión de Dispositivos, Sincronización de grupos de usuarios, Pasos de configuración, Applivery, LDAP, Active Directory, OpenLDAP :::warning Esta es una función premium que puede no estar disponible en tu plan actual. Comprueba la disponibilidad en la [página de precios de Applivery](https://www.applivery.com/pricing/). ::: El Lightweight Directory Access Protocol (LDAP) es un protocolo de aplicación abierto y neutro para acceder y gestionar información de directorios distribuidos — más comúnmente directorios de usuarios corporativos como Active Directory u OpenLDAP. Integrar Applivery con tu servidor LDAP permite a los empleados autenticarse contra tu directorio existente usando sus credenciales corporativas, sin necesitar una cuenta separada de Applivery. La autenticación LDAP aplica a **ambos** módulos de Applivery: - **Distribución de Apps** — los empleados se autentican contra tu directorio LDAP al acceder a las Store Enterprises privadas. El acceso puede restringirse por grupos LDAP para controlar qué usuarios ven qué apps. - **Gestión de Dispositivos** — los usuarios finales de los dispositivos gestionados se autentican contra tu directorio LDAP cuando el portal MDM requiere verificación de identidad, por ejemplo, durante los flujos de enrollment de dispositivos que requieren autenticación de usuario. Applivery admite LDAP con y sin SSL (`ldap://` y `ldaps://`). * * * ### Cómo funciona la autenticación LDAP El flujo de autenticación es el mismo independientemente del módulo al que acceda el usuario: 1. El usuario llega a una pantalla de inicio de sesión de Applivery — ya sea en un dominio/subdominio de la Store Enterprise (Distribución de Apps) o en el portal MDM (Gestión de Dispositivos). 2. Introduce su nombre de usuario y contraseña corporativos. 3. Applivery envía las credenciales a tu servidor LDAP para su validación. 4. Si la autenticación es correcta y el usuario tiene los permisos requeridos, obtiene acceso y solo ve los recursos que está autorizado a ver. No se requiere la creación de una cuenta de Applivery para los usuarios finales — sus credenciales de directorio existentes son el único inicio de sesión necesario. #### Distribución de Apps Los usuarios que acceden a una Store Enterprise privada solo ven las Publicaciones para las que están autorizados, según su membresía de grupos LDAP. Este es el caso de uso principal para controlar qué empleados pueden descargar qué Builds de apps. #### Gestión de Dispositivos Los usuarios que se autentican a través del portal MDM — por ejemplo, durante flujos de enrollment o al acceder al portal para empleados — son validados contra tu directorio LDAP. Esto permite a los equipos de IT aplicar la verificación de identidad corporativa como parte del proceso de incorporación de dispositivos, sin necesitar una identidad de Applivery separada para cada usuario. * * * ### Requisitos previos Antes de configurar la integración en Applivery, asegúrate de tener la siguiente información de tu administrador LDAP: - La dirección del servidor LDAP, el protocolo (`ldap://` o `ldaps://`) y el puerto (normalmente `389` para LDAP, `636` para LDAPS). - Un **Bind DN** — el nombre distinguido de una cuenta de servicio con acceso de lectura a tu directorio. - La **contraseña del Bind DN** para esa cuenta de servicio. - La **base de búsqueda** — el nombre distinguido del nodo del directorio desde el que Applivery debe buscar usuarios (p. ej., `ou=people,dc=example,dc=com`). - El **filtro de búsqueda** — el atributo LDAP que contiene el nombre de inicio de sesión del usuario (p. ej., `uid`, `sAMAccountName`). - El **campo de correo** — el atributo LDAP que contiene la dirección de correo del usuario (p. ej., `mail`). #### Autorizar la IP de Applivery Si tu servidor LDAP usa listas de IPs permitidas, debes añadir la siguiente IP de Applivery a tu firewall o reglas de acceso del servidor LDAP antes de que los usuarios puedan autenticarse: ``` 34.175.89.200 ``` * * * ### Configuración **Añadir el proveedor de acceso LDAP** En el [**panel de Applivery**](https://dashboard.applivery.io), dirígete a los **Ajustes del Workspace** desde el menú desplegable superior. Luego, en el menú de la izquierda, abre **Proveedores de acceso** y selecciona la opción **LDAP** en la sección de la Store Enterprise o en la sección del MDM Portal . ![ldap](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/5056c374-965a-49aa-b61a-dd0870a4ad38.png) **Configurar la conexión** Estos campos controlan cómo Applivery se conecta y autentica contra tu servidor LDAP: | Campo | Descripción | Ejemplo | | --- | --- | --- | | **Servidor** | URL del servidor LDAP, incluyendo protocolo y puerto. | `ldaps://ldap.example.com:636` | | **Bind DN** | Nombre distinguido de la cuenta de servicio usada para conectarse al directorio. | `cn=applivery-svc,ou=services,dc=example,dc=com` | | **Contraseña del Bind** | Contraseña para la cuenta de servicio del Bind DN. | — | :::warning La cuenta del Bind DN solo necesita acceso de **lectura** al directorio. No uses una cuenta con permisos de escritura. ::: **Configurar el directorio** Estos campos controlan cómo Applivery busca usuarios dentro de tu directorio LDAP: | Campo | Descripción | Ejemplo | | --- | --- | --- | | **Base de búsqueda** | Nombre distinguido del nodo del directorio desde donde comienzan las búsquedas de usuarios. | `ou=people,dc=example,dc=com` | | **Filtro de búsqueda** | Atributo LDAP usado como identificador de inicio de sesión. | `uid` (OpenLDAP) o `sAMAccountName` (Active Directory) | | **Campo de correo** | Atributo LDAP que contiene la dirección de correo del usuario. | `mail` | Haz clic en **Guardar** para activar la integración LDAP. ### Sincronización de grupos de usuarios Applivery importa automáticamente las Unidades Organizativas (OUs) de LDAP como grupos de usuarios. Estos grupos están disponibles en Distribución de Apps y Gestión de Dispositivos para el control de acceso. #### Cómo funciona - Los grupos se sincronizan cada vez que un usuario inicia sesión — no hay sincronización en segundo plano entre inicios de sesión. - Los grupos LDAP importados llevan el prefijo `ldap:` para distinguirlos de los grupos creados manualmente en Applivery (p. ej. `ldap:engineering`, `ldap:qa-team`). - Todos los grupos LDAP de un usuario se **reemplazan completamente** en cada inicio de sesión. Si añades o eliminas a un usuario de un grupo en tu directorio LDAP, el cambio se reflejará en Applivery la próxima vez que ese usuario inicie sesión. #### Usar grupos LDAP en Distribución de Apps Los grupos LDAP pueden usarse como filtros de grupos de distribución en publicaciones privadas, restringiendo el acceso a Builds específicas de apps a equipos o departamentos concretos — sin necesidad de gestión manual de usuarios en Applivery. Para saber más sobre publicaciones privadas y filtros de grupos de distribución, consulta [Cómo distribuir tus apps](https://docs.applivery.com/es/app-distribution/distribute/distribute-apps/). #### Usar grupos LDAP en Gestión de Dispositivos Los grupos LDAP también pueden referenciarse en Gestión de Dispositivos para segmentar audiencias de dispositivos y aplicar distintas políticas o configuraciones a diferentes grupos de usuarios. Por ejemplo, puedes aplicar políticas más estrictas a una unidad organizativa y una configuración más permisiva a otra, todo ello impulsado por los grupos importados de tu directorio existente. --- ## SCIM para Okta Source: https://docs.applivery.com/es/platform/authentication/sso/okta-scim/ Description: Automatiza el aprovisionamiento de usuarios con SCIM en Applivery — configura el SCIM de Okta para una gestión fluida de usuarios y grupos en tu organización. TL;DR: Automatiza el aprovisionamiento de usuarios y grupos en Applivery con SCIM y Okta para una gestión de identidades eficiente. Answers: ¿Qué es el SCIM y cómo funciona con Applivery? · ¿La gestión de grupos con SCIM depende de SAML en Applivery? · ¿Cómo activo el SCIM en Applivery? · ¿Qué valores debo usar al configurar la conexión SCIM en Okta? · ¿Cómo envío grupos desde Okta a Applivery usando SCIM? · ¿Cómo funciona el mapeo de roles con SCIM para el panel de Applivery? Key topics: Configuración SCIM, Integración con Okta, Aprovisionamiento de usuarios, Mapeo de roles, Mapeo de atributos, SCIM, Applivery, Okta, SAML :::warning Esta es una función premium que puede no estar disponible en tu plan actual. Comprueba la disponibilidad en la [página de precios de Applivery](https://www.applivery.com/pricing/). ::: **SCIM (System for Cross-domain Identity Management)** es un estándar abierto que automatiza el aprovisionamiento de usuarios y grupos en los servicios en la nube. En lugar de gestionar usuarios manualmente en Applivery, el SCIM permite a tu proveedor de identidad enviar información de usuarios y grupos automáticamente — creando, actualizando y desactivando usuarios y manteniendo las membresías de grupos sincronizadas sin ninguna intervención manual. Cuando se combina con el SSO SAML, el SCIM gestiona el lado del _aprovisionamiento_ de la gestión de identidades. SAML autentica a los usuarios cuando inician sesión, mientras que el SCIM mantiene continuamente el directorio de usuarios y la estructura de grupos en Applivery actualizada. Un aspecto clave: **la gestión de grupos mediante SCIM es completamente independiente de SAML** — los grupos enviados mediante SCIM existen en Applivery como objetos de primer nivel antes de que ningún usuario inicie sesión, y no requieren ninguna configuración adicional de grupos en el lado de SAML. :::tip El SCIM funciona sobre una integración SSO SAML existente. Si aún no la has configurado, empieza primero con la guía de [Single Sign-On con Okta](https://docs.applivery.com/es/platform/authentication/sso/okta/). ::: * * * ### Qué gestiona el SCIM en Applivery El SCIM puede gestionar tres tipos de recursos en Applivery, cada uno con un comportamiento de aprovisionamiento diferente según el portal que configures. **Store Enterprise** Cuando el SCIM está configurado para el **Store Enterprise**, Applivery puede crear o eliminar cuentas de empleados automáticamente en respuesta a cambios en Okta. Cuando se crea un usuario en Okta, puedes elegir no hacer nada o crearlo automáticamente como empleado. Cuando se desactiva, puedes elegir no hacer nada o eliminarlo de Applivery. **Dashboard** Cuando el SCIM está configurado para el **Dashboard**, Applivery gestiona las cuentas de Colaboradores. Cuando se crea un usuario en Okta, puedes elegir no hacer nada o crearlo como Colaborador con un rol predeterminado (Admin, Developer/Editor o Viewer). Cuando se desactiva, puedes no hacer nada o eliminarlo como Colaborador. El rol inicial asignado en la creación puede sobreescribirse mediante el mapeo de roles basado en grupos — consulta [Mapeo de roles](#mapeo-de-roles) más abajo. **MDM Portal** Cuando el SCIM está configurado para el **MDM Portal**, Applivery ofrece las opciones de desactivación más granulares. Cuando se crea un usuario en Okta puedes no hacer nada o crearlo como empleado MDM. Cuando se desactiva, tienes cinco opciones: no hacer nada, desasignar al usuario de sus dispositivos, cambiar la política de sus dispositivos asignados, eliminar al usuario, o eliminar al usuario y todos sus dispositivos asociados. * * * ### Configuración del SCIM Hay dos formas de configurar el SCIM con Okta. El **enfoque nativo** — recomendado — añade el SCIM directamente a tu aplicación SAML de Applivery existente en Okta, manteniendo el SSO y el aprovisionamiento juntos en una sola aplicación. También está disponible un **enfoque con aplicación separada** usando una aplicación SCIM independiente del catálogo de Okta como opción alternativa. **Activar el SCIM en Applivery** En el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a la **Ajustes del Workspace** desde el menú desplegable superior y abre ** Proveedores de acceso** en el menú de la izquierda. Encuentra la fila **SAML** y haz clic en **Configurar** para el portal que quieras proteger — **Dashboard**, **Store Enterprise** o **MDM Portal**. Desplázate hasta el final de la pantalla de configuración SAML y haz clic en **Activar SCIM**. Applivery generará una **URL base** y un **token Bearer**. Copia ambos — los necesitarás en Okta. Las opciones de comportamiento del aprovisionamiento (qué ocurre cuando se crea o desactiva un usuario) también están disponibles aquí, específicas para el portal seleccionado. **Activar el SCIM en tu aplicación SAML de Okta existente** En el [Portal de Administración de Okta](https://www.okta.com/), abre la **aplicación SAML de Applivery** que ya tienes configurada. Ve a la pestaña **General**, encuentra la sección **App Settings** y haz clic en **Edit**. En **Provisioning**, selecciona **SCIM** y haz clic en **Save**. Aparecerá una nueva pestaña **Provisioning** en la aplicación. ![provisioning scim](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/d7936ff3-e525-4814-94bc-a4014787257d.png) :::info La opción SCIM en App Settings puede no estar disponible en todos los planes de Okta. Si no aparece, contacta con el soporte de Okta para que la activen en tu organización, o usa una [aplicación SCIM separada en Okta](#alternativa-aplicación-scim-separada-en-okta). ::: **Configurar la conexión SCIM** Ve a la pestaña **Provisioning** y selecciona **Integration** en la barra lateral izquierda. Haz clic en **Edit** y completa los datos de conexión: | Campo | Valor | | --- | --- | | **SCIM connector base URL** | La URL base generada por Applivery en el Paso 1 | | **Unique identifier field for users** | `email` | | **Supported provisioning actions** | **Push New Users**, **Push Profile Updates**, **Push Groups** | | **Authentication Mode** | HTTP Header | | **Authorization** (token Bearer) | El token Bearer generado por Applivery en el Paso 1 | Haz clic en **Test Connector Configuration** para verificar. Si la prueba es correcta, haz clic en **Save**. **Activar las acciones de aprovisionamiento** Aún en la pestaña **Provisioning**, selecciona **To App** en la barra lateral izquierda y haz clic en **Edit**. Activa **Create Users**, **Update User Attributes** y **Deactivate Users**, luego guarda. **Enviar grupos a Applivery** Ve a la pestaña **Push Groups** en la parte superior de la sección Provisioning. Haz clic en **Push Groups → Find groups by name**, busca los grupos de Okta que quieres sincronizar con Applivery, selecciona cada uno y haz clic en **Save**. Añade más grupos haciendo clic en **Save & Add Another**. Cuando se envía un grupo, Okta manda tanto el objeto del grupo como sus miembros a Applivery. Estos grupos están disponibles de inmediato en Applivery para filtros de Publicaciones, mapeo de roles y control de acceso — sin necesidad de configuración SAML adicional. :::tip Okta no admite usar el mismo grupo tanto para **Assignments** como para **Push Groups**. Si tienes problemas de sincronización, usa grupos separados para asignar usuarios a la app y para enviar grupos a Applivery. ::: * * * ### Mapeo de roles Cuando el SCIM está configurado para el **Dashboard**, puedes mapear grupos de Okta a roles de Colaborador de Applivery. Si se está aprovisionando un usuario por primera vez — es decir, aún no existe en Applivery — su rol se determina por los grupos a los que pertenece en Okta: | Grupo de Okta | Rol en Applivery | | --- | --- | | `applivery-admin` | Admin | | `applivery-editor` | Developer / Editor | | `applivery-viewer` | Viewer | | `applivery-unassigned` | Sin asignar | Si un usuario pertenece a más de uno de estos grupos, el rol de mayor privilegio tiene prioridad. :::info El mapeo de roles solo aplica a **App Distribution**. Los permisos de Device Management se rigen exclusivamente por los [permisos de segmentos](https://docs.applivery.com/es/device-management/general-settings/segments/). ::: * * * ### Mapeo de atributos Además de la creación de usuarios y la sincronización de grupos, el SCIM también puede enviar atributos de usuario personalizados desde Okta al campo `metadata` del objeto de usuario correspondiente en Applivery. Esto es útil para almacenar el departamento, centro de coste, ID de empleado u cualquier otro campo personalizado de tu directorio. Consulta la guía completa en [Mapeo de atributos SCIM](https://docs.applivery.com/es/device-management/integrations/sso/scim-attributes-mapping/). * * * ### Alternativa: aplicación SCIM separada en Okta Si activar el SCIM directamente en tu aplicación SAML no está disponible en tu plan de Okta, puedes configurar el aprovisionamiento usando una aplicación SCIM independiente del catálogo de Okta. Este enfoque usa dos aplicaciones de Okta separadas — una para el SSO SAML y otra para el aprovisionamiento SCIM. #### Configurar el aprovisionamiento con una aplicación SCIM separada En el Portal de Administración de Okta, dirígete a **Applications** (dentro de Applications) y haz clic en **Browse App Catalog**. ![browse app catalog](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/bf96f00e-00d4-4a67-a7b2-ab06ecb8708d.png) Busca **SCIM 2.0 Test App (OAuth Bearer Token)**, selecciona el primer resultado y haz clic en **\+ Add integration**. Dale una etiqueta (p. ej., `Applivery SCIM`) y completa los ajustes generales, luego haz clic en **Done**. ![add scim integration](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/ab357246-9b63-4620-9881-d20cd2b1fef9.png) Dentro de la nueva app, dirígete a la pestaña **Provisioning** y haz clic en **Configure API Integration**. Introduce la **URL base** y el **token Bearer** de Applivery (Paso 1 de la guía principal). Haz clic en **Test API Credentials** — Okta enviará una solicitud GET a Applivery para verificar la conexión. Si pasa, haz clic en **Save**. ![enable scim integration](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/35924cea-4213-4e30-9632-405e45f9968d.png) Aún en Provisioning, haz clic en **Edit** en **Provisioning to App** y activa **Create Users**, **Update User Attributes** y **Deactivate Users**. Para sincronizar grupos, dirígete a la pestaña **Assignments**, selecciona **Groups** en la barra lateral, haz clic en **Assign → Assign to Groups** y selecciona los grupos de Okta que quieres aprovisionar en Applivery. --- ## Okta Source: https://docs.applivery.com/es/platform/authentication/sso/okta/ Description: Activa el SSO SAML de Okta para Applivery — conecta tu Dashboard, Store Enterprise y MDM Portal usando credenciales de Okta. TL;DR: Configura el SSO de Applivery con Okta SAML creando una aplicación SAML en Okta y subiendo los metadatos a Applivery, lo que permite a los usuarios acceder con sus credenciales de Okta. Answers: ¿Por qué no puedo cargar un archivo de metadatos para configurar Okta con Applivery? · ¿Cuál es el primer paso para configurar Applivery con Okta? · ¿Dónde encuentro la URL de inicio de sesión único y la URI de audiencia en Applivery? · ¿Cómo activo el envío de grupos de Okta a Applivery? · ¿Dónde encuentro los metadatos del proveedor de identidad en Okta? Key topics: Configuración SAML, Configuración de la aplicación Okta, Integración SSO con Applivery, Metadatos del proveedor de identidad, Applivery, Okta, SAML, Proveedor de servicios, Proveedor de identidad :::warning Esta es una función premium que puede no estar disponible en tu plan actual. Comprueba la disponibilidad en la [página de precios de Applivery](https://www.applivery.com/pricing/). ::: Una vez configurado, los miembros de tu organización podrán acceder al panel de Applivery, a la Store Enterprise o al MDM Portal usando sus credenciales de Okta — sin necesidad de una contraseña separada de Applivery. :::warning Okta no admite la subida de archivos de metadatos. A diferencia de otros proveedores de identidad, Okta no permite importar el archivo XML de metadatos SAML preconfigurado de Applivery. Debes configurar la aplicación SAML en Okta manualmente usando los valores proporcionados en el panel de Applivery. ::: :::info Si planeas usar un dominio personalizado para tu Store Enterprise o MDM Portal, configúralo en Applivery **antes** de configurar el SSO. Los dominios personalizados cambian las URLs de callback, por lo que el orden importa. ::: * * * ### Requisitos previos - Acceso de administrador a tu Workspace de Applivery. - Acceso de administrador a tu [Portal de Administración de Okta](https://www.okta.com/). - Tu **slug de organización** de Applivery — visible en la URL cuando estás conectado al panel de Applivery (p. ej., `demo` en `https://dashboard.applivery.io/demo/...`). - Si usas un dominio personalizado, asegúrate de configurarlo primero en Applivery en la sección Ajustes, navegando a Personalización de la tienda en el menú de la izquierda. * * * **Obtener los valores del proveedor de servicios de Applivery** Applivery actúa como el **Proveedor de Servicios (SP)** SAML. Como Okta requiere la entrada manual, necesitas recopilar dos valores específicos de la pantalla de configuración SAML de Applivery. En el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a la **Ajustes del Workspace** desde el menú desplegable superior y abre **Proveedores de acceso** en el menú de la izquierda. Encuentra la fila **SAML** y haz clic en **Configurar** para el portal que quieras proteger — **Dashboard**, **Store Enterprise** o **MDM Portal**. ![login providers](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/7756cdbd-a769-4464-a458-6d957e34ff73.png) Copia los siguientes valores: ##### Valores por tipo de portal **Dashboard** | Campo | Valor | | --- | --- | | **URL de inicio de sesión único (URL de Callback)** | `https://dashboard.applivery.io/welcome/sso/{organization_slug}` | | **URI de Audiencia (SP Entity ID)** | `https://dashboard.applivery.com/sso/{organization_slug}/metadata.xml` | **Store Enterprise (App Store)** | Campo | Valor | | --- | --- | | **URL de inicio de sesión único (URL de Callback)** | La URL de tu Store Enterprise: `{organization_slug}.applivery.io` o tu dominio personalizado `apps.tuempresa.com` | | **URI de Audiencia (SP Entity ID)** | `https://dashboard.applivery.com/sso/{organization_slug}/metadata.xml` | **MDM Portal** | Campo | Valor | | --- | --- | | **URL de inicio de sesión único (URL de Callback)** | `https://mdm-portal.applivery.io/login/{organization_id}` | | **URI de Audiencia (SP Entity ID)** | `https://dashboard.applivery.com/sso/{organization_slug}/metadata.xml` | Reemplaza `{organization_slug}` y `{organization_id}` con tus valores reales, visibles en la pantalla de configuración SAML de Applivery. **Crear una aplicación SAML en Okta** ##### Crear una nueva integración de App Accede a tu [Portal de Administración de Okta](https://www.okta.com/), dirígete a **Applications** (dentro de Applications) y haz clic en el botón **Create App Integration**. ![create app integration](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/6c523c0f-2dc0-433f-be3c-6129455f9e6f.png) Selecciona **SAML 2.0** como método de inicio de sesión y haz clic en **Next**. ##### Ajustes generales Introduce un nombre para la aplicación (p. ej., `Applivery`) y, opcionalmente, sube un logo para identificarla fácilmente. Luego haz clic en **Next**. ![general settings](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/8f131921-9567-4603-ac2d-fc35b86c9b5f.png) ##### Configurar los ajustes SAML Completa los siguientes campos en la pantalla de configuración SAML: | Campo | Valor | | --- | --- | | **Single sign-on URL** | La URL de Callback para tu portal del Paso 1 | | **Audience URI (SP Entity ID)** | El Entity ID para tu portal del Paso 1 | | **Name ID format** | `EmailAddress` | | **Application username** | `Email` | ![saml settings](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/43e3bad4-a697-4fc7-8674-85b93d0a3f50.png) Deja todos los demás campos con sus valores predeterminados. :::warning El campo **Single sign-on URL** debe contener la **URL de Callback** (no la URL de inicio de sesión general). Por ejemplo, para el portal del Dashboard: `https://dashboard.applivery.io/welcome/sso/demo`. ::: Haz clic en **Next** cuando hayas terminado. ##### Configurar los Group Attribute Statements Para habilitar el envío de grupos de Okta a Applivery (necesario para el filtrado de grupos de distribución y el mapeo de roles), debes configurar un **Group Attribute Statement**. Desplázate hasta la sección **Group Attribute Statements**. Si está contraída, haz clic en **Show Legacy Configuration → Edit**. Añade una notificación de grupo con los siguientes ajustes: | Campo | Valor | | --- | --- | | **Name** | `http://schemas.microsoft.com/ws/2008/06/identity/claims/groups` | | **Name format** | `URI Reference` | | **Filter** | Consulta las opciones de filtro más abajo | **Opciones de filtro** — elige según tus necesidades: | Opción | Cuándo usarla | | --- | --- | | **Starts with** + un prefijo | Enviar solo los grupos cuyos nombres empiezan con un prefijo específico. Útil para limitar qué grupos de Okta se sincronizan con Applivery. | | **Matches regex** `.*` | Enviar todos los grupos de Okta a los que pertenece el usuario. | | **Regex** con un patrón específico | Enviar solo los grupos que coincidan con una expresión regular personalizada. | ![group attribute statement](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/be3b5ea8-bae5-4823-982e-338b64f1ad6f.png) Haz clic en **Save** para aplicar el attribute statement. ##### Completar la configuración de la aplicación Termina el asistente de Okta (haz clic en **Next** en los pasos restantes). Okta confirmará que la aplicación ha sido creada. **Obtener los metadatos del proveedor de identidad de Okta** Applivery necesita los metadatos del proveedor de identidad de Okta para validar las aserciones SAML entrantes. Dentro de la aplicación recién creada en Okta, dirígete a la pestaña **Sign On**, haz clic en **View SAML Setup Instructions**. A continuación, desplázate hasta la parte inferior de la página y localiza la sección **Identity Provider metadata**. Copia el contenido XML completo y guárdalo como un archivo `.xml` (p. ej., `okta-metadata.xml`). ![view saml setup instructions](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/a5b18fc1-7639-4405-b5c4-45b6651c484e.png) **Completar la configuración en Applivery** Vuelve a la pantalla de configuración SAML de Applivery para el mismo portal que empezaste en el Paso 1. En el **Paso 2** del formulario SAML de Applivery, sube el archivo **XML de metadatos de federación** que guardaste de Okta y haz clic en **Guardar**. Usa el **interruptor** para **activar** la integración SAML para tu organización. **Asignar usuarios en Okta** Antes de que los usuarios puedan autenticarse mediante SSO, deben estar asignados a la aplicación de Applivery en Okta. En tu aplicación de Okta, dirígete a la pestaña **Assignments**. Haz clic en **Assign** y selecciona **Assign to People** o **Assign to Groups**, según tu enfoque preferido de gestión de acceso. Asigna los usuarios o grupos que deben tener acceso a Applivery y haz clic en **Done**. ![assignments](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/269956c4-cd2f-469f-bafe-cea22810564a.png) :::warning Los usuarios que no estén asignados a la aplicación en Okta no podrán acceder mediante SSO, aunque la integración esté correctamente configurada. ::: **Probar la integración** Una vez que ambos lados están configurados y activados, prueba con un usuario asignado: - **Dashboard:** Ve a [https://dashboard.applivery.io/welcome/sso](https://dashboard.applivery.io/welcome/sso) e introduce el correo del usuario. Serás redirigido a Okta para autenticarte. - **Store Enterprise / MDM Portal:** Navega a la URL de tu Store Enterprise o MDM Portal. Los usuarios con SAML configurado serán redirigidos a Okta para autenticarse antes de acceder al portal. Si la autenticación falla, comprueba que la **URL de inicio de sesión único** en Okta coincide exactamente con la URL de Callback de Applivery (incluyendo el slug de la organización), y que el usuario está asignado a la aplicación en Okta. --- ## Ping Identity Source: https://docs.applivery.com/es/platform/authentication/sso/ping-identity/ Description: Configura el SSO de Applivery con Ping Identity — cubre la configuración, el mapeo de atributos y la prueba de la integración de extremo a extremo. TL;DR: Configura el SSO de Applivery con Ping Identity intercambiando metadatos SAML, mapeando atributos y activando la integración para una autenticación segura de usuarios. Answers: ¿Cuáles son los requisitos previos para configurar Applivery con Ping Identity? · ¿Cómo obtengo los metadatos del proveedor de servicios de Applivery? · ¿Qué tipo de aplicación SAML debo seleccionar en Ping Identity? · ¿Qué mapeos de atributos se requieren en Ping Identity para Applivery? · ¿Qué opción de firma debo seleccionar en Ping Identity? · ¿Por qué falla mi integración de Applivery con Ping Identity? Key topics: Configuración SAML, Configuración de Ping Identity, Configuración de Applivery, Mapeo de atributos, Prueba del SSO, Applivery, Ping Identity, SAML :::warning Esta es una función premium que puede no estar disponible en tu plan actual. Comprueba la disponibilidad en la [página de precios de Applivery](https://www.applivery.com/pricing/). ::: La configuración implica dos partes: primero recopilas los metadatos del proveedor de servicios de Applivery, luego configuras una aplicación SAML en Ping Identity y, por último, completas la configuración de vuelta en Applivery con los metadatos del proveedor de identidad. :::info Si planeas usar un dominio personalizado para tu Store Enterprise o MDM Portal, configúralo en Applivery **antes** de configurar el SSO. Los dominios personalizados cambian las URLs de callback en los metadatos SAML, por lo que el orden importa. ::: * * * ### Requisitos previos - Acceso de administrador a tu Workspace de Applivery. - Acceso de administrador a tu [consola de Ping Identity](https://www.pingidentity.com/). - Si usas un dominio personalizado, asegúrate de configurarlo primero en Applivery en la sección Ajustes, navegando a Personalización de la tienda en el menú de la izquierda. * * * **Obtener los metadatos del proveedor de servicios de Applivery** Applivery actúa como el **Proveedor de Servicios (SP)** SAML. El primer paso es recopilar sus metadatos para importarlos en Ping Identity. En el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a los **Ajustes del Workspace** desde el menú desplegable superior y abre **Proveedores de acceso** en el menú de la izquierda. Encuentra la fila **SAML** y haz clic en **Configurar** para el portal que quieras proteger — **Dashboard**, **Store Enterprise** o **MDM Portal**. :::tip En general, se recomienda configurar cada portal por separado, usando una aplicación de Ping Identity dedicada por portal, ya que los grupos de usuarios y los requisitos de acceso suelen diferir entre ellos. ::: ![login providers](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/487bb3c8-9552-4eff-9a0c-a0208d3bc46e.png) Una vez seleccionado, descarga el **XML de metadatos SAML** del paso 1 y tenlo a mano — lo cargarás a Ping Identity en el siguiente paso. **Configurar una aplicación SAML en Ping Identity** **Crear la aplicación** Accede a tu [consola de Ping Identity](https://www.pingidentity.com/), dirígete a Applications y haz clic en el botón **+** 1 en la parte superior de la página para crear una nueva aplicación. Proporciona un nombre descriptivo (por ejemplo, Applivery) y selecciona **SAML Application** 2 como tipo de aplicación. ![ping create application](https://www.applivery.com/wp-content/uploads/2024/10/Screenshot-2024-10-24-at-091737-1024x651.png "Screenshot 2024-10-24 at 091737 | Applivery") Haz clic en Configure, luego en el diálogo de configuración SAML elige **Import Metadata** y sube el archivo XML de metadatos SAML descargado de Applivery en el paso 1. Por último, haz clic en **Save** para completar la configuración. ![upload metadata to ping](https://www.applivery.com/wp-content/uploads/2024/10/Screenshot-2024-10-24-at-092742-1024x651.png "upload-metadata-to-ping | Applivery") **Activar la aplicación** Una vez creada la aplicación, encuéntrala en la lista de Applications y **activa el interruptor** para activarla. La aplicación debe estar activada para que funcione el SSO. ![enable ping application](https://www.applivery.com/wp-content/uploads/2024/10/Screenshot-2024-10-24-at-095406-1024x651.png "enable-ping-application | Applivery") **Configurar el mapeo de atributos** Applivery requiere atributos SAML específicos para identificar a los usuarios y asignar membresías de grupos. Ve a la pestaña **Attribute Mapping** de tu nueva aplicación y haz clic en el icono de lápiz para editar. Añade los siguientes cuatro mapeos: | Atributo de Applivery | Mapeo en PingOne | Notas | | --- | --- | --- | | `saml_subject` | Email Address | El identificador principal del usuario. Requerido. | | `firstName` | Given Name | Nombre del usuario. | | `lastName` | Family Name | Apellido del usuario. | | `groups` | Group Names | Usado para sincronizar los grupos de Ping Identity en Applivery para el control de acceso. | **Para cada mapeo**: escribe el nombre del atributo en el campo de la izquierda, selecciona el mapeo de PingOne correspondiente del desplegable y haz clic en **\+ Add**. Una vez añadidos los cuatro, haz clic en **Save**. ![ping attribute mappings](https://www.applivery.com/wp-content/uploads/2024/10/Screenshot-2024-10-24-at-100847-1024x651.png "ping-attribute-mappings | Applivery") **Establecer la opción de firma** Ve a la pestaña **Configuration** y haz clic en el icono de lápiz para editar. En las opciones de firma, selecciona **Sign Assertion & Response**. Esto garantiza que tanto la aserción SAML como el sobre de respuesta estén firmados, lo que Applivery requiere. Haz clic en **Save** para aplicar. **Descargar los metadatos del proveedor de identidad** Aún en la pestaña **Configuration**, haz clic en **Download Metadata** para descargar el archivo **XML de metadatos de federación** de Ping Identity. Este archivo contiene la información del proveedor de identidad (URL del emisor, certificado de firma, endpoint SSO) que Applivery necesita para validar las aserciones SAML entrantes. ![download ping metadata](https://www.applivery.com/wp-content/uploads/2024/10/Screenshot-2024-10-24-at-102857-1024x651.png "download-ping-metadata | Applivery") **Completar la configuración en Applivery** Vuelve al panel de Applivery. En el **Paso 2** del formulario SAML, sube el archivo **XML de metadatos de federación** que descargaste de Ping Identity. Configura los mapeos de atributos para que coincidan con lo que estableciste en Ping Identity en el paso anterior: - **Atributo de nombre:** `firstName`. - **Atributo de apellido:** `lastName`. - **Atributo de grupos:** `groups`. Haz clic en **Guardar** y usa el **interruptor** para **activar** la integración SAML para tu organización. ![ping mapping](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/808b4d6e-947a-4177-b2a1-b11c7225aecd.png) **Asignar usuarios en Ping Identity** Antes de que los usuarios puedan acceder mediante SSO, deben ser asignados a la aplicación de Applivery en Ping Identity. Ve a **Directory → Users** en tu consola de Ping Identity y asigna los usuarios o grupos que deben tener acceso a Applivery. **Probar la integración** Una vez que ambos lados están configurados y la integración está activada, pruébala con un usuario asignado: - **Dashboard:** Ve a [https://dashboard.applivery.io/welcome/sso](https://dashboard.applivery.io/welcome/sso) e introduce el correo del usuario. Serás redirigido a Ping Identity para autenticarte. - **Store Enterprise / MDM Portal:** Navega a la URL de tu Store Enterprise o MDM Portal. Los usuarios con SAML configurado serán redirigidos a Ping Identity para autenticarse antes de acceder al portal. Si la autenticación falla, verifica que los nombres de atributos en Applivery coincidan exactamente con los configurados en el mapeo de atributos de Ping Identity (distingue mayúsculas de minúsculas), y que la opción **Sign Assertion & Response** esté configurada correctamente en Ping Identity. --- ## SAML Source: https://docs.applivery.com/es/platform/authentication/sso/saml/ Description: Activa el SSO para Applivery usando SAML 2.0 — integra con Okta, Azure AD, Ping Identity y más, con mapeo de atributos y grupos. TL;DR: Configura el SAML SSO para Applivery para habilitar la autenticación segura a través de tu proveedor de identidad existente, simplificando el acceso y la gestión de usuarios. Answers: ¿Qué es el SAML SSO y cómo funciona con Applivery? · ¿Qué proveedores de identidad admite Applivery para el SAML SSO? · ¿Qué portales de Applivery pueden usar el SAML SSO? · ¿Cómo funciona el mapeo de atributos en Applivery? · ¿Cómo funciona el mapeo de grupos y roles en el SAML SSO de Applivery? Key topics: Configuración del SAML SSO, Integración con el proveedor de identidad, Mapeo de atributos, Mapeo de grupos, Mapeo de roles, Applivery, SAML 2.0, Okta, Azure AD, Ping Identity, Microsoft Entra ID, Auth0 :::warning Esta es una función premium que puede no estar disponible en tu plan actual. Comprueba la disponibilidad en la [página de precios de Applivery](https://www.applivery.com/pricing/). ::: SAML 2.0 (Security Assertion Markup Language) es el estándar de la industria para el Single Sign-On basado en web. Permite que tu proveedor de identidad (IdP) — como Okta, Azure AD o Ping Identity — gestione la autenticación, mientras que Applivery confía en el resultado y concede el acceso sin gestionar nunca las contraseñas de tus usuarios. Una vez configurado, los usuarios que visitan un portal protegido de Applivery son redirigidos a la página de inicio de sesión de su IdP. Tras autenticarse allí, el IdP envía una aserción SAML firmada a Applivery confirmando la identidad y las membresías de grupos del usuario. Applivery valida la aserción y da acceso al usuario — sin necesidad de contraseña separada de Applivery. El SAML SSO puede configurarse de forma independiente para cada uno de los tres portales de Applivery: - **Dashboard** — acceso para los Colaboradores (desarrolladores, administradores, viewers) que gestionan apps y políticas. - **Store Enterprise** — acceso para los empleados de la tienda que descargan Builds de apps internas. - **MDM Portal** — acceso para los usuarios de dispositivos que se autentican durante el enrollment o el acceso al portal. * * * ### Proveedores de identidad compatibles Applivery admite cualquier proveedor de identidad compatible con SAML 2.0. Hay guías de configuración paso a paso para los más comunes: **Azure AD (Microsoft Entra ID)** Incluye mapeo de grupos de seguridad y asignación de roles. **Okta** Incluye configuración de atributos de grupo y aprovisionamiento SCIM. **Ping Identity** Incluye mapeo de atributos e intercambio de metadatos de federación. :::tip Si tu IdP no está en la lista anterior, puedes configurar el SAML SSO siempre que sea compatible con SAML 2.0. El flujo general — intercambiar los metadatos del SP de Applivery, configurar el IdP, subir el XML de metadatos de federación del IdP a Applivery — es el mismo para todos los proveedores. ::: * * * ### Flujo de autenticación Cuando un usuario accede a un portal de Applivery protegido por SAML, el flujo funciona así: El usuario visita tu dominio del Store Enterprise, el panel o el MDM Portal y hace clic en **Iniciar sesión**. Applivery lo redirige a la página de inicio de sesión de tu proveedor de identidad, donde se autentica con sus credenciales corporativas. Una vez autenticado, el IdP envía una respuesta SAML firmada al endpoint de callback de Applivery. Applivery valida la firma, extrae la identidad del usuario y la información de grupos de la aserción, y concede el acceso — mostrando solo las apps y recursos que el usuario está autorizado a ver. * * * ### Mapeo de atributos Applivery lee la identidad del usuario de atributos específicos de la aserción SAML. El nombre exacto del atributo varía según el proveedor de identidad. Puedes sobreescribir los valores predeterminados en la pantalla de configuración SAML bajo **Mapeo de atributos** — deja un campo en blanco para usar el valor predeterminado del IdP detectado. #### Correo electrónico La dirección de correo es el identificador principal del usuario. Applivery lo busca en los siguientes lugares, en orden: | IdP | Atributo | | --- | --- | | Estándar (predeterminado) | `nameID` | | Azure AD | `EmailAddress` (`http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress`) | | Auth0 | `http://schemas.auth0.com/email` | #### Nombre | IdP | Atributo | | --- | --- | | Estándar (predeterminado) | `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname` | | Azure AD | `http://schemas.microsoft.com/identity/claims/displayname` | | Auth0 | `http://schemas.auth0.com/given_name` | #### Apellido | IdP | Atributo | | --- | --- | | Estándar (predeterminado) | `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname` | | Azure AD | `http://schemas.microsoft.com/identity/claims/displayname` | | Auth0 | `http://schemas.auth0.com/family_name` | #### Grupos de usuarios Los grupos de tu IdP se usan para el control de acceso en Applivery — controlando qué usuarios ven qué Publicaciones y asignando roles en el panel. Applivery lee los grupos de: | IdP | Atributo | | --- | --- | | Estándar (predeterminado) | `http://schemas.xmlsoap.org/claims/Group` | | Azure AD | `http://schemas.microsoft.com/ws/2008/06/identity/claims/groups` | | Okta | `http://schemas.microsoft.com/ws/2008/06/identity/claims/groups` (configurado mediante Group Attribute Statement) | * * * ### Mapeo de grupos Algunos proveedores de identidad — especialmente Azure AD — no envían nombres de grupo en las aserciones SAML. En su lugar, envían identificadores opacos (Object IDs en el caso de Azure). La función de mapeo de grupos de Applivery permite traducir estos IDs a nombres de grupo legibles. Puedes configurar mapeos clave/valor en tu configuración SAML en el [**panel de Applivery**](https://dashboard.applivery.io/), en Mapeo de grupos. Applivery también descubrirá automáticamente nuevos valores de grupo a medida que los usuarios se autentiquen y los añadirá a la lista — puedes asignarles nombres en cualquier momento sin necesidad de configurarlos todos por adelantado. ![group translation](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/77dbb6fe-4d7d-443c-a18d-260855c5f24f.png) Para una guía detallada específica de Azure AD, consulta [Single Sign-On con Azure AD — Mapeo de grupos de seguridad](https://docs.applivery.com/es/platform/authentication/sso/azure-ad/). * * * ### Mapeo de roles desde SSO Cuando SAML está configurado para el **panel**, Applivery puede asignar automáticamente un rol de Colaborador a los nuevos usuarios según los grupos enviados en su aserción SAML. :::info Esto aplica solo en el primer inicio de sesión — si el usuario ya existe en Applivery, su rol existente no cambia. ::: El rol se determina según a cuál de los siguientes nombres de grupo reservados pertenece el usuario en su IdP: | Nombre del grupo | Rol de Applivery asignado | | --- | --- | | `applivery-admin` | Admin | | `applivery-editor` | Developer / Editor | | `applivery-viewer` | Viewer | | `applivery-unassigned` | Sin asignar | Si un usuario pertenece a más de uno de estos grupos, el rol de mayor privilegio tiene prioridad. Si el usuario no pertenece a ninguno de estos grupos, se crea sin asignación de rol y un administrador tendrá que asignárselo manualmente. :::tip El mapeo de roles también funciona en combinación con el Mapeo de grupos. Si tu IdP envía Object IDs en lugar de nombres de visualización, puedes mapear los Object IDs a los nombres de grupo reservados (`applivery-admin`, etc.) en los ajustes de Mapeo de grupos, y la asignación de roles funcionará correctamente. ::: :::info El mapeo de roles solo aplica al modulo de **Distribución de Apps**. Los permisos de la Gestión de Dispositivos se rigen exclusivamente por los [permisos de segmentos](https://docs.applivery.com/es/device-management/general-settings/segments/). ::: --- ## Organización Source: https://docs.applivery.com/es/platform/organization/ Description: Configura los aspectos estructurales y de marca de tu Workspace de Applivery: dominio personalizado, configuración del Workspace y gestión multi-Workspace. TL;DR: La sección Organización cubre la configuración del Workspace, el dominio personalizado y la gestión de múltiples Workspaces en Applivery. Answers: ¿Qué cubre la sección Organización de Applivery? · ¿Cómo configuro un dominio personalizado en Applivery? · ¿Puedo gestionar múltiples Workspaces en Applivery? · ¿Dónde configuro los ajustes de marca del Workspace? Key topics: Ajustes del Workspace, Dominio personalizado, Gestión multi-Workspace, Applivery, Workspace, Enterprise Store Los ajustes de organización te permiten configurar los aspectos estructurales y de marca de tu Workspace de Applivery — incluyendo dominios personalizados, la configuración del Workspace y la gestión de múltiples Workspaces para organizaciones con varios entornos. Configura tu organización y controla cómo se presenta dentro de la plataforma Applivery. --- ## Dominio personalizado Source: https://docs.applivery.com/es/platform/organization/custom-domain/ Description: Personaliza tu Enterprise Store de Applivery con un dominio propio — configura un registro CNAME y actívalo desde el panel de Applivery. TL;DR: Configura un dominio personalizado para tu Enterprise Store de Applivery creando un registro CNAME y activándolo en el panel de Applivery. Answers: ¿Cómo configuro un dominio personalizado en Applivery? · ¿Qué registro DNS necesito para un dominio personalizado en Applivery? · ¿Sigue funcionando la URL de Applivery original después de activar el dominio personalizado? · ¿Necesito configurar un certificado SSL para mi dominio personalizado? · ¿Qué ocurre con el SSO al activar un dominio personalizado? Key topics: Configuración del dominio personalizado, Configuración del CNAME, Consideraciones del SSO, Certificados SSL, Applivery, DNS, CNAME, SAML, Azure AD, Okta, Ping Identity, DigiCert, Google Trust Services, Let's Encrypt, SSL.com Por defecto, tu Enterprise Store de Applivery es accesible en `{tu-organización}.applivery.io`. Los dominios personalizados te permiten reemplazarlo con un subdominio propio — por ejemplo, `apps.tuempresa.com` — dándole a tus empleados una URL de marca reconocible al acceder a las Builds de apps internas. :::info Los dominios personalizados aplican únicamente al **Enterprise Store**. El panel de Applivery y el Portal MDM no se ven afectados. ::: * * * ### Configuración **Crear un registro CNAME en tu proveedor DNS** Antes de configurar nada en Applivery, debes apuntar tu subdominio a los servidores de Applivery. En tu proveedor DNS, crea un nuevo registro `CNAME` para el subdominio que quieras usar: | Tipo | Nombre | Valor | | --- | --- | --- | | `CNAME` | `apps` _(tu subdominio elegido)_ | `domains.applivery.io` | La propagación DNS puede tardar desde unos minutos hasta varias horas, según tu proveedor y la configuración de TTL. Puedes verificar que se ha propagado con una herramienta como [dnschecker.org](https://dnschecker.org/) antes de continuar. :::tip Los dominios personalizados solo funcionan con **subdominios** (ej: `apps.tuempresa.com`). Los dominios raíz (ej: `tuempresa.com` sin prefijo de subdominio) no están soportados, ya que requieren un registro A en lugar de un CNAME. ::: **Activar el dominio personalizado en Applivery** En el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a la sección **Configuración** 1 y selecciona **Personalización del Store** 2 en el menú de la izquierda. Localiza el campo **Dominio personalizado** 3, escribe tu subdominio (ej: `apps.tuempresa.com`) y haz clic en **Guardar**. ![store customization](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/feaade91-affe-47a7-ae39-ebee9b203418.png) Applivery verificará que el registro CNAME está correctamente configurado y activará el dominio personalizado para tu Enterprise Store. Una vez activo, tus empleados podrán acceder al Enterprise Store en la nueva URL. * * * ### Qué cambia al activar un dominio personalizado **Tu URL original sigue funcionando.** La URL por defecto `{tu-organización}.applivery.io` permanece activa después de activar un dominio personalizado — ambas URLs funcionan simultáneamente. No necesitas comunicar una fecha límite de migración a tus usuarios. **La configuración del SSO puede necesitar actualizarse.** Si tienes Single Sign-On configurado mediante SAML (Azure AD, Okta, Ping Identity u otro proveedor basado en SAML), las URLs de callback incluidas en los metadatos SAML cambiarán cuando haya un dominio personalizado activo. Es posible que necesites reconfigurar la integración SAML desde cero con los metadatos actualizados para restaurar el SSO. :::warning Configura siempre tu dominio personalizado **antes** de configurar el SAML SSO. Los metadatos SAML que genera Applivery incluyen la URL del Enterprise Store como endpoint de callback — si añades un dominio personalizado después de configurar el SSO, tendrás que regenerar los metadatos y actualizar tu proveedor de identidad. ::: * * * ### Certificado SSL y registros CAA Applivery aprovisiona y gestiona automáticamente un certificado SSL para tu dominio personalizado. No necesitas hacer ninguna configuración de certificado por tu parte. Si tu dominio usa registros DNS **CAA (Certification Authority Authorization)** para restringir qué Autoridades de Certificación pueden emitir certificados, debes autorizar las CAs que utiliza Applivery. Añade un registro CAA para cada una de las siguientes: | Tipo | Nombre | Valor | | --- | --- | --- | | `CAA` | `@` _(o tu subdominio)_ | `0 issue "digicert.com"` | | `CAA` | `@` _(o tu subdominio)_ | `0 issue "pki.goog"` | | `CAA` | `@` _(o tu subdominio)_ | `0 issue "letsencrypt.org"` | | `CAA` | `@` _(o tu subdominio)_ | `0 issue "ssl.com"` | Si no tienes registros CAA configurados, todas las CAs están permitidas por defecto y no necesitas hacer nada. Puedes usar el [Generador de registros CAA de SSLMate](https://sslmate.com/caa/) para generar el registro correcto para tu configuración. --- ## Workspaces Source: https://docs.applivery.com/es/platform/organization/workspaces/ Description: Gestiona los Workspaces de Applivery — crea, cambia, configura la facturación y transfiere la propiedad para organizar tus apps y dispositivos de forma eficiente. TL;DR: Gestiona tu entorno de Applivery creando, cambiando y configurando Workspaces para una organización óptima de apps y dispositivos. Answers: ¿Qué es un Workspace en Applivery? · ¿Cómo cambio entre Workspaces en Applivery? · ¿Cómo creo un nuevo Workspace en Applivery? · ¿Cómo se gestiona la facturación en los Workspaces de Applivery? · ¿Cómo transfiero la propiedad de un Workspace? Key topics: Creación de Workspaces, Cambio de Workspaces, Gestión de la facturación, Transferencia de propiedad, Applivery, Workspace, Admin Un Workspace es la unidad organizativa principal de Applivery. Agrupa todas tus apps, dispositivos, miembros del equipo, facturación y ajustes bajo un mismo paraguas. Puedes tener múltiples Workspaces — por ejemplo, uno por unidad de negocio, cliente o entorno — y cambiar entre ellos en cualquier momento desde la barra de navegación superior. * * * ### Cambiar entre Workspaces El menú desplegable del Workspace en la barra de navegación superior muestra siempre tu Workspace activo. Haz clic en él para ver todos los Workspaces a los que tienes acceso y selecciona cualquiera para cambiar. Desde el mismo menú también puedes acceder a **Auditoría**, **Facturación** y **Ajustes** del Workspace activo. ![Workspace dropdown](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/38435af9-3a19-4539-a1e0-2b85df6c3c32.png) * * * ### Crear un Workspace Para crear un nuevo Workspace, abre el menú desplegable del Workspace en la barra de navegación superior y haz clic en **\+ Nuevo Workspace**. Escribe un nombre y confirma. El nuevo Workspace empieza vacío — sin apps, dispositivos ni miembros del equipo — y tiene su propia facturación independiente. ![create Workspace](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/e1c9f566-8fa1-433b-97f2-66ba10baba67.png) * * * ### Facturación y suscripción La facturación se gestiona por Workspace. Cada Workspace tiene su propio plan, método de pago e historial de facturas, accesibles desde **Workspace → Facturación**. La sección de Facturación está organizada en tres áreas: - **Plan y uso** — consulta tu plan actual, sube, baja o cancela tu suscripción, y supervisa el uso respecto a los límites de tu plan. - **Pago** — gestiona tus datos de facturación y métodos de pago. - **Facturas** — accede al historial completo de facturas asociadas al Workspace. ![billing section](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/0f4cc557-3df0-47ea-9d4a-ca33b364e9be.png) #### Actualizar los datos de pago Ve a **Workspace → Facturación → Pago** para actualizar los datos de facturación o añadir un nuevo método de pago. #### Actualizar o cambiar tu plan En el [**panel de Applivery**](https://dashboard.applivery.io/), dirígete a tu **Workspace**, selecciona **Facturación** y haz clic en el botón **Plan y uso**. A continuación, haz clic en Gestionar junto a tu plan actual. Aparecerá un modal con tu plan actual y las alternativas disponibles. Selecciona un nuevo plan en las pestañas superiores y haz clic en **Continuar** para aplicar el cambio. :::tip Puedes actualizar o cancelar tu plan en cualquier momento sin contactar con soporte — los cambios se aplican de inmediato. ::: * * * ### Transferir la propiedad del Workspace La propiedad de un Workspace puede transferirse a cualquier miembro existente de la organización. Para hacerlo, dirígete a **Ajustes del Workspace** y, desde el menú de la izquierda, navega hasta la **Zona de peligro**. Haz clic en el botón **Transferir** junto a la opción **Transferir propiedad**. A continuación, selecciona el nuevo propietario de la lista de miembros de la organización y confirma la acción. La transferencia se realiza de inmediato. El propietario anterior recibe automáticamente el rol de **Admin** y mantiene el acceso al Workspace. ![transfer ownership](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/078e6b67-6529-4555-b4b0-16a335e2fa35.png) :::warning La transferencia de propiedad es inmediata y no se puede deshacer desde el panel. Si necesitas revertirla, el nuevo propietario debe iniciar otra transferencia. ::: --- ## Roles y permisos Source: https://docs.applivery.com/es/platform/roles-permissions/ Description: Controla el acceso de los Colaboradores en Applivery con roles predefinidos y permisos granulares — desde administradores completos hasta usuarios de solo lectura. TL;DR: Los roles y permisos de Applivery controlan lo que cada Colaborador puede ver y hacer: Admin, Developer/Editor o Viewer, con permisos granulares para Device Management. Answers: ¿Qué roles existen en Applivery? · ¿Cómo asigno un rol a un Colaborador? · ¿Cuál es la diferencia entre Admin, Developer y Viewer? · ¿Cómo funcionan los permisos en la Gestión de Dispositivos? · ¿Puedo configurar permisos granulares en Applivery? Key topics: Roles predefinidos, Asignación de permisos, Acceso a la Distribución de Apps, Permisos en Device Management, Applivery, Colaborador, Admin, Developer, Viewer Los roles y permisos controlan lo que cada Colaborador puede ver y hacer dentro de Applivery. Puedes asignar roles predefinidos o configurar permisos granulares para adaptarlos a la estructura de tu organización — desde administradores completos hasta usuarios de solo lectura u operadores específicos de cada módulo. Consulta los roles disponibles, cómo están estructurados los permisos en la Distribución de Apps y la Gestión de Dispositivos, y asigna y gestiona el acceso de los Colaboradores. --- ## Roles de Colaborador personalizados Source: https://docs.applivery.com/es/platform/roles-permissions/custom-collaborator-roles/ Description: Crea roles de Colaborador personalizados para la Gestión de Dispositivos en Applivery y asígnalos en los permisos de segmento para dar a cada equipo justo el acceso que necesita. TL;DR: Crea un rol con las acciones exactas que necesita un puesto y asígnalo en un permiso de segmento. Las acciones de Workspace solo se aplican en el segmento Global. Answers: ¿Cómo creo un rol personalizado para Colaboradores en Applivery? · ¿Puedo dar a un Colaborador solo algunas acciones de Admin? · ¿Por qué las acciones de Workspace no se aplican en mi segmento hijo? · ¿Puedo editar los roles predefinidos Admin, Editor o Viewer? · ¿Cómo se combinan los permisos entre segmentos? · ¿Los roles personalizados afectan a los permisos de Distribución de Apps? Key topics: Qué es un rol de Colaborador, Roles y permisos de segmento, Grupos de acciones de Workspace y Device Management, Cómo se suman los permisos entre segmentos, Crear y asignar roles personalizados, Applivery, Colaborador, Segmento, Device Management Los roles de Colaborador personalizados te permiten decidir exactamente qué puede hacer cada [Colaborador](https://docs.applivery.com/es/device-management/getting-started/manage-users/#colaboradores) de tu equipo en la parte de Gestión de Dispositivos del panel de Applivery. En lugar de elegir entre **Admin**, **Editor** o **Visualizador** en cada permiso de segmento, puedes crear un rol para un puesto concreto, como soporte, administrador de tienda o auditor, y reutilizarlo donde lo necesites. Así, nadie recibe acceso completo de Admin solo porque necesita una acción más en un sitio concreto. :::info Esto se aplica a los roles de Colaborador de **Gestión de Dispositivos**. Los [roles de Colaborador de Distribución de Apps](https://docs.applivery.com/es/app-distribution/distribute/manage-users/#roles-y-permisos) funcionan igual que antes. ::: ### Qué es un rol de Colaborador Un rol de Colaborador es un conjunto de acciones del panel con nombre propio. Responde a **qué** puede hacer un Colaborador, pero no a **dónde**: eso lo decide el permiso de segmento al que lo asignas. Los roles se definen a nivel de organización. Los creas una vez y los reutilizas en todos los permisos de segmento que quieras. Un rol no pertenece a ningún segmento. #### Roles predefinidos **Admin**, **Editor** y **Visualizador** siguen disponibles. Aparecen marcados como predefinidos, y no se pueden editar ni eliminar. Si quieres algo parecido a uno de ellos, usa **Duplicar** y edita la copia, que se convierte en un nuevo rol personalizado. Si abres un rol predefinido sin duplicarlo, se abre en modo solo lectura. #### Roles personalizados Puedes crear roles personalizados desde cero con **Crear rol**, o duplicando un rol que ya exista. Puedes editar su nombre, su descripción y sus acciones en cualquier momento. Al elegir un rol en un permiso, el selector de roles muestra el nombre del rol personalizado. En las tablas **Permisos** y **Por colaboradores**, en cambio, los roles personalizados aparecen con una etiqueta genérica **Personalizado**, para que los nombres largos no descuadren la tabla. ### Roles y permisos de segmento Hay dos capas que trabajan juntas para dar acceso a alguien:

Capa

Qué decide

Dónde se gestiona

Rol

Qué acciones del panel están permitidas

Configuración → Directorio → Roles

Permiso de segmento

Quién recibe ese rol, y en qué segmento

Configuración → Segmentos & Permisos

En un permiso de segmento seleccionas un rol. No puedes crear ni editar el rol desde el propio permiso; en su lugar, el permiso muestra una vista previa de solo lectura con las acciones que incluye el rol seleccionado. ### Grupos de acciones: Workspace y **Gestión de Dispositivos** Cada acción pertenece a uno de estos dos grupos: - **Workspace** (**W**): ajustes a nivel de organización y gestión de personas, como Colaboradores, segmentos, proveedores de inicio de sesión y las pocas acciones de facturación que no son exclusivas del Propietario. - **Gestión de Dispositivos** (**M**): acciones sobre dispositivos, políticas, inscripción y otros elementos de **Gestión de Dispositivos** dentro de un segmento. Un rol puede incluir acciones de Workspace, de Gestión de Dispositivos o de ambos. La lista de **Roles** y el selector de roles muestran una insignia **W** y otra **M** para cada rol: la insignia aparece resaltada cuando el rol tiene acciones de ese grupo, y en gris cuando no tiene ninguna. Las **acciones exclusivas del Propietario**, como transferir la propiedad, eliminar el workspace y la mayoría de acciones de gestión de la facturación, aparecen en el grupo Workspace pero bloqueadas. No se pueden conceder a ningún rol. ![built in roles](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/863777de-c3b5-4403-af49-4af91fed2572.png) #### Las acciones de Workspace solo se aplican en Global Las acciones de Workspace solo se aplican cuando el permiso de segmento está en **Global**, el segmento raíz de tu árbol. Si asignas un rol que incluye acciones de Workspace en un segmento hijo: - Las acciones de **Gestión de Dispositivos** del rol se siguen aplicando en ese segmento. - Sus acciones de Workspace no se aplican ahí. - El panel muestra un aviso bajo el campo **Rol**, pero puedes guardar igualmente. - La vista previa de solo lectura oculta la sección Workspace, ya que esas acciones no se van a aplicar. ![segment perms](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/c62410a2-674f-427c-a4d6-5c53a7f2c996.png) ### Cómo se suman los permisos entre segmentos Los permisos **se suman** a medida que bajas por el árbol de [segmentos](https://docs.applivery.com/es/device-management/general-settings/segments/). Por ejemplo: - Un Colaborador tiene **Visualizador** en **Global**. - El mismo Colaborador tiene un rol personalizado con acciones extra de **Gestión de Dispositivos** en **Madrid**, un segmento hijo. En Madrid, ese Colaborador puede hacer todo lo que conceden Global y Madrid juntos. Esto también significa que un permiso en un segmento hijo **no puede quitar** acciones concedidas más arriba en el árbol. Si alguien necesita menos acciones en una tienda que en toda la región, asígnale el rol más limitado a nivel de tienda (o más abajo), en lugar de un rol amplio a nivel de región. :::info La vista previa del permiso solo muestra las acciones del rol seleccionado. No incluye lo que el Colaborador ya tiene por permisos en segmentos superiores. ::: ### Cómo crear un rol de Colaborador **Ir a Roles** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), navega a la sección de **Configuración** 1 y, en el menú lateral izquierdo, dentro de **Directorio**, selecciona **Roles** 2. **Crear el rol** Haz clic en **Crear rol** 3 e introduce un nombre y una descripción. ![create role](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/60e212f9-e127-4a35-9cd5-1fee51090065.png) **Seleccionar las acciones** Si quieres partir de las acciones de un rol que ya existe, elígelo como plantilla 4. Después, marca o desmarca las acciones que necesites en los grupos **Workspace** y **Gestión de Dispositivos** 5. Las acciones exclusivas del Propietario siguen bloqueadas. ![role modal](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/c6d97939-11b8-4cfe-9ab2-4d3f66cc1b9c.png) **Guardar** Guarda el rol. A partir de ahora puedes asignarlo en cualquier permiso de segmento. Para crear un rol personalizado a partir de uno predefinido, abre **Admin**, **Editor** o **Visualizador**, haz clic en **Duplicar** y edita el nuevo rol. ### Cómo asignar un rol en un permiso de segmento Sigue el mismo flujo que usas para [crear segmentos y permisos](https://docs.applivery.com/es/device-management/general-settings/segments/#cómo-crear-segmentos-y-permisos), ahora con las nuevas opciones de rol. **Abrir el segmento** Una vez en el [**panel de Applivery**](https://dashboard.applivery.io/), navega a la sección de **Configuración** 1, selecciona **Segmentos & Permisos** 2 en el menú lateral izquierdo, elige el segmento 3 y crea o edita un permiso 4. ![role and segment](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/eb1dbbd7-30d0-4cc0-b52e-b3a9f06e9814.png) **Poner nombre al permiso y elegir el rol** Dale al permiso un nombre claro y elige el rol, ya sea predefinido o personalizado. Fíjate en sus insignias **W** y **M** para ver qué grupos de acciones incluye. Si el segmento no es Global y el rol incluye acciones de Workspace, verás un aviso. Recuerda que esas acciones de Workspace no se aplicarán en este segmento. **Añadir a quién se aplica** Añade los grupos y/o direcciones de correo electrónico a los que se aplica este permiso. **Revisar y guardar** Revisa la vista previa de solo lectura con las acciones del rol y guarda. No puedes cambiar acciones concretas en un solo permiso. Para ajustarlas, edita el rol, o crea uno nuevo y asígnalo. ### A tener en cuenta - Los roles de Colaborador de **Distribución de Apps** no se ven afectados por los roles personalizados. Consulta [Gestionar usuarios en Distribución de Apps](https://docs.applivery.com/es/app-distribution/distribute/manage-users/#roles-y-permisos). - Las acciones de **Inventario** no forman parte de los roles personalizados. - Un permiso en un segmento hijo no puede denegar ni quitar acciones concedidas en un segmento padre. - Cada permiso usa un rol tal cual. No hay forma de personalizar acciones por permiso sin crear o editar un rol. - Los roles personalizados son para personas. Las cuentas de servicio que se usan para el acceso a la API y la automatización tienen sus propios roles. Consulta [Cuentas de servicio](https://docs.applivery.com/es/platform/api/service-accounts/). --- ## Permisos por rol Source: https://docs.applivery.com/es/platform/roles-permissions/permissions-by-role/ Description: Consulta qué endpoints de la API de Applivery y qué acciones puede usar cada rol predefinido en Gestión de dispositivos, Distribución de apps y el Workspace. TL;DR: Cada endpoint de la API exige un permiso y cada rol predefinido incluye un conjunto de permisos. Usa el resumen para comparar roles y las tablas por área para comprobar un endpoint concreto. Answers: ¿Dónde veo qué permiso exige un endpoint? · ¿Qué significa el nombre de un permiso? · ¿Qué rol puede llamar a todos los endpoints? · ¿Puede un rol de Gestión de dispositivos usar endpoints de Distribución de apps? · ¿Qué diferencia hay entre Admin de Distribución de apps y App Admin? · ¿Qué pasa si un Colaborador tiene varios roles? · ¿Aparecen los roles personalizados en esta página? · ¿Por qué algunos permisos no tienen endpoint? Key topics: Cómo funcionan los roles y los permisos, Endpoints y acciones por rol, Permisos por área, Applivery, Colaborador, Gestión de dispositivos, Distribución de apps Cada endpoint de la [API de Applivery](https://docs.applivery.com/en/api/) que depende de un rol exige un permiso, que encontrarás como **Required Permission** en su página de referencia. Cada rol predefinido incluye un conjunto fijo de estos permisos, así que el rol de un Colaborador o de una Service Account decide qué endpoints puede llamar y qué acciones puede hacer en el panel. Usa el resumen para comparar lo que cubre cada rol, y las tablas por área para comprobar un permiso o un endpoint concreto. ### Cómo funcionan los roles y los permisos Un permiso, también llamado acción, tiene cuatro partes: `área.contexto.recurso.operación`. Por ejemplo, `mdm.apple.depDevice.get` permite obtener un dispositivo de Apple Business en Gestión de dispositivos. Es el mismo nombre que verás como **Required Permission** en la referencia de la API. Estos son los roles predefinidos: | Rol | Dónde se aplica | | --- | --- | | **Owner** | El propietario del Workspace. Tiene todas las acciones, incluidas la facturación y la propiedad. Solo hay un Owner por Workspace. | | **Admin, Editor y Viewer de Gestión de dispositivos** | Los roles de Colaborador predefinidos de Gestión de dispositivos, que se asignan en los permisos de segmento. Consulta [Roles de Colaborador personalizados](https://docs.applivery.com/es/platform/roles-permissions/custom-collaborator-roles/). | | **Admin, Editor y Viewer de Distribución de apps** | Los roles de Colaborador de Distribución de apps a nivel de Workspace. Consulta [Roles y permisos en Distribución de apps](https://docs.applivery.com/es/app-distribution/distribute/manage-users/#roles-y-permisos). | | **App Admin, App Editor y App Viewer** | Roles sobre una sola app en Distribución de apps. El App Owner recibe las mismas acciones que el App Admin. | | **Unassigned** | Sin acceso a nivel de Workspace. El Colaborador puede tener igualmente un rol en una app concreta. | | **No Role** | Las acciones que se aplican cuando el usuario no tiene ningún rol en el Workspace ni en la app. | Ten en cuenta que: - **Las acciones se suman.** Un Colaborador con un rol de Workspace y un rol de app recibe las acciones de los dos, y en Gestión de dispositivos [los permisos se suman a lo largo del árbol de segmentos](https://docs.applivery.com/es/platform/roles-permissions/custom-collaborator-roles/#cómo-se-suman-los-permisos-entre-segmentos). - **Los roles personalizados** incluyen las acciones que tú eliges, así que no aparecen en esta página. Las acciones del propietario (`owner.*`) y las de personas de Distribución de apps (`people.mad.*`) no pueden formar parte de un rol personalizado. ### Endpoints por rol **Endpoints** cuenta las operaciones de la API que puede llamar un rol. **Acciones** cuenta todos los permisos que incluye el rol, también las acciones que no usa ningún endpoint público. Una acción puede cubrir varios endpoints. Las tres últimas columnas reparten los endpoints por área. | Rol | Endpoints | Acciones | Gestión de dispositivos | Distribución de apps | Workspace | | --- | :-: | :-: | :-: | :-: | :-: | | **Owner** | 584 | 552 | 386 | 108 | 90 | | **Admin de Gestión de dispositivos** | 472 | 424 | 386 | 0 | 86 | | **Editor de Gestión de dispositivos** | 297 | 245 | 257 | 0 | 40 | | **Viewer de Gestión de dispositivos** | 192 | 142 | 164 | 1 | 27 | | **Admin de Distribución de apps** | 172 | 164 | 0 | 108 | 64 | | **Editor de Distribución de apps** | 101 | 85 | 0 | 65 | 36 | | **Viewer de Distribución de apps** | 74 | 57 | 0 | 51 | 23 | | **App Admin** | 117 | 108 | 0 | 94 | 23 | | **App Editor** | 79 | 66 | 0 | 60 | 19 | | **App Viewer** | 62 | 48 | 0 | 43 | 19 | | **Unassigned** | 8 | 5 | 0 | 0 | 8 | | **No Role** | 9 | 8 | 0 | 1 | 8 | :::info La API tiene 663 endpoints, y 584 de ellos exigen un permiso. El resto, como los de autenticación, no dependen de un rol de Colaborador. ::: ### Permisos por área Cada tabla lista los permisos de un área, los endpoints que los exigen y los roles que los incluyen: **✓** significa que el rol incluye el permiso y **–** que no lo incluye. La ruta de cada endpoint es relativa a `/organizations/:organizationId`, y **—** en **Endpoints** significa que ningún endpoint público usa ese permiso. Las columnas de roles usan estas abreviaturas: | Abreviatura | Rol | | --- | --- | | **O** | Owner | | **A**, **E**, **V** | Admin, Editor y Viewer de Gestión de dispositivos o de Distribución de apps, según la pestaña o la tabla | | **App A**, **App E**, **App V** | App Admin, App Editor y App Viewer | En la pestaña **Workspace**, cada área tiene dos tablas: una para los roles de Gestión de dispositivos y otra para los de Distribución de apps. Un **¹** marca un permiso que también incluyen otros roles, como Unassigned o No Role; los encontrarás debajo de la tabla. **Gestión de dispositivos** **Global (mdm.global) · 67 acciones, 67 endpoints** | Permiso | Endpoints | O | A | E | V | | --- | --- | :-: | :-: | :-: | :-: | | `mdm.global.agentLog.get` | [`GET /mdm/agent-logs/:mdmAgentLogsId`](https://docs.applivery.com/en/api/uem/agent-logs/get-agent-log/) | ✓ | ✓ | ✓ | ✓ | | `mdm.global.agentLog.list` | [`GET /mdm/agent-logs`](https://docs.applivery.com/en/api/uem/agent-logs/get-agent-logs/) | ✓ | ✓ | ✓ | ✓ | | `mdm.global.agentLog.remove` | [`DELETE /mdm/agent-logs/:mdmAgentLogsId`](https://docs.applivery.com/en/api/uem/agent-logs/delete-agent-log/) | ✓ | ✓ | ✓ | ✓ | | `mdm.global.agentLog.view` | — | ✓ | ✓ | ✓ | ✓ | | `mdm.global.asset.create` | [`POST /mdm/assets`](https://docs.applivery.com/en/api/uem/managed-assets/post-asset/)
[`POST /mdm/assets/edge/asset`](https://docs.applivery.com/en/api/uem/managed-assets/edge/post-asset/)
[`GET /mdm/assets/edge/prepare`](https://docs.applivery.com/en/api/uem/managed-assets/edge/get-prepare/) | ✓ | ✓ | ✓ | – | | `mdm.global.asset.download` | [`GET /mdm/assets/:mdmAssetId/download`](https://docs.applivery.com/en/api/uem/managed-assets/get-download/) | ✓ | ✓ | ✓ | – | | `mdm.global.asset.get` | [`GET /mdm/assets/:mdmAssetId`](https://docs.applivery.com/en/api/uem/managed-assets/get-asset/)
[`GET /mdm/assets/:mdmAssetId/assignations`](https://docs.applivery.com/en/api/uem/managed-assets/get-assignations/) | ✓ | ✓ | ✓ | ✓ | | `mdm.global.asset.list` | [`GET /mdm/assets`](https://docs.applivery.com/en/api/uem/managed-assets/get-assets/) | ✓ | ✓ | ✓ | ✓ | | `mdm.global.asset.remove` | [`DELETE /mdm/assets/:mdmAssetId`](https://docs.applivery.com/en/api/uem/managed-assets/delete-asset/) | ✓ | ✓ | ✓ | – | | `mdm.global.asset.update` | [`PUT /mdm/assets/:mdmAssetId`](https://docs.applivery.com/en/api/uem/managed-assets/put-asset/) | ✓ | ✓ | ✓ | – | | `mdm.global.asset.view` | [`GET /mdm/assets/:mdmAssetId/view`](https://docs.applivery.com/en/api/uem/managed-assets/get-view/) | ✓ | ✓ | ✓ | ✓ | | `mdm.global.automationRule.create` | [`POST /mdm/automation-rules`](https://docs.applivery.com/en/api/uem/automation-rules/post-automation-rule/) | ✓ | ✓ | ✓ | – | | `mdm.global.automationRule.get` | [`GET /mdm/automation-rules/:mdmAutomationRuleId`](https://docs.applivery.com/en/api/uem/automation-rules/get-automation-rule/) | ✓ | ✓ | ✓ | ✓ | | `mdm.global.automationRule.list` | [`GET /mdm/automation-rules`](https://docs.applivery.com/en/api/uem/automation-rules/get-automation-rules/) | ✓ | ✓ | ✓ | ✓ | | `mdm.global.automationRule.remove` | [`DELETE /mdm/automation-rules/:mdmAutomationRuleId`](https://docs.applivery.com/en/api/uem/automation-rules/delete-automation-rule/) | ✓ | ✓ | ✓ | – | | `mdm.global.automationRule.update` | [`PUT /mdm/automation-rules/:mdmAutomationRuleId`](https://docs.applivery.com/en/api/uem/automation-rules/put-automation-rule/) | ✓ | ✓ | ✓ | – | | `mdm.global.automationRuleLog.list` | [`GET /mdm/automation-rules-logs`](https://docs.applivery.com/en/api/uem/automation-rules-logs/get-automation-rules-logs/) | ✓ | ✓ | ✓ | ✓ | | `mdm.global.configurations.get` | [`GET /mdm/configurations`](https://docs.applivery.com/en/api/uem/configurations/get-organizations-organizationid-mdm-configurations/) | ✓ | ✓ | – | – | | `mdm.global.configurations.update` | [`PUT /mdm/configurations`](https://docs.applivery.com/en/api/uem/configurations/put-organizations-organizationid-mdm-configurations/) | ✓ | ✓ | – | – | | `mdm.global.device.list` | [`GET /mdm/devices`](https://docs.applivery.com/en/api/uem/devices/get-devices/)
[`GET /mdm/devices/available-updates`](https://docs.applivery.com/en/api/uem/devices/get-available-updates/)
[`GET /mdm/devices/csv`](https://docs.applivery.com/en/api/uem/devices/get-csv/)
[`GET /mdm/devices/os-versions`](https://docs.applivery.com/en/api/uem/devices/get-os-versions/)
[`GET /mdm/devices/sync-errors`](https://docs.applivery.com/en/api/uem/devices/get-sync-errors/)
[`GET /mdm/devices/tags`](https://docs.applivery.com/en/api/uem/devices/get-tags/) | ✓ | ✓ | ✓ | ✓ | | `mdm.global.deviceAudience.create` | [`POST /mdm/device-audiences`](https://docs.applivery.com/en/api/platform/device-audiences/post-device-audience/) | ✓ | ✓ | ✓ | – | | `mdm.global.deviceAudience.download` | — | ✓ | ✓ | ✓ | – | | `mdm.global.deviceAudience.get` | [`GET /mdm/device-audiences/:deviceAudienceId`](https://docs.applivery.com/en/api/platform/device-audiences/get-device-audience/) | ✓ | ✓ | ✓ | ✓ | | `mdm.global.deviceAudience.list` | [`GET /mdm/device-audiences`](https://docs.applivery.com/en/api/platform/device-audiences/get-device-audiences/) | ✓ | ✓ | ✓ | ✓ | | `mdm.global.deviceAudience.preview` | [`POST /mdm/device-audiences/preview`](https://docs.applivery.com/en/api/platform/device-audiences/preview/post/)
[`POST /mdm/device-audiences/preview-multiple`](https://docs.applivery.com/en/api/platform/device-audiences/post-preview-multiple/) | ✓ | ✓ | ✓ | ✓ | | `mdm.global.deviceAudience.remove` | [`DELETE /mdm/device-audiences/:deviceAudienceId`](https://docs.applivery.com/en/api/platform/device-audiences/delete-device-audience/) | ✓ | ✓ | ✓ | – | | `mdm.global.deviceAudience.update` | [`PUT /mdm/device-audiences/:deviceAudienceId`](https://docs.applivery.com/en/api/platform/device-audiences/put-device-audience/) | ✓ | ✓ | ✓ | – | | `mdm.global.deviceAudience.view` | [`GET /mdm/device-audiences/:deviceAudienceId/preview`](https://docs.applivery.com/en/api/platform/device-audiences/preview/get/) | ✓ | ✓ | ✓ | ✓ | | `mdm.global.deviceMessage.get` | [`GET /mdm/device-messages/:deviceMessageId`](https://docs.applivery.com/en/api/uem/device-message/get-organizations-organizationid-mdm-device-messages-devicemessageid/) | ✓ | ✓ | ✓ | ✓ | | `mdm.global.deviceMessage.list` | [`GET /mdm/device-messages`](https://docs.applivery.com/en/api/uem/device-message/get-organizations-organizationid-mdm-device-messages/) | ✓ | ✓ | ✓ | ✓ | | `mdm.global.deviceMessage.upsert` | — | ✓ | ✓ | ✓ | – | | `mdm.global.deviceTmv.requestControl` | `POST /mdm/tmv/request-control` | ✓ | ✓ | – | – | | `mdm.global.location.get` | [`GET /mdm/locations/:type/:identifier/:mdmLocationId`](https://docs.applivery.com/en/api/uem/locations/get-location/) | ✓ | ✓ | ✓ | ✓ | | `mdm.global.location.list` | [`GET /mdm/locations/:type/:identifier`](https://docs.applivery.com/en/api/uem/locations/get-locations/) | ✓ | ✓ | ✓ | ✓ | | `mdm.global.location.remove` | [`DELETE /mdm/locations/:type/:identifier/:mdmLocationId`](https://docs.applivery.com/en/api/uem/locations/delete-location/) | ✓ | ✓ | – | – | | `mdm.global.mdmSmartAttribute.update` | — | ✓ | ✓ | ✓ | – | | `mdm.global.mdmUser.create` | [`POST /mdm/users`](https://docs.applivery.com/en/api/uem/users/post-user/) | ✓ | ✓ | ✓ | – | | `mdm.global.mdmUser.get` | [`GET /mdm/users/:mdmUserId`](https://docs.applivery.com/en/api/uem/users/get-user/) | ✓ | ✓ | ✓ | ✓ | | `mdm.global.mdmUser.list` | [`GET /mdm/users`](https://docs.applivery.com/en/api/uem/users/get-users/)
[`GET /mdm/users/csv/sample`](https://docs.applivery.com/en/api/uem/users/get-csv-sample/)
[`GET /mdm/users/tags`](https://docs.applivery.com/en/api/uem/users/get-tags/) | ✓ | ✓ | ✓ | ✓ | | `mdm.global.mdmUser.remove` | [`DELETE /mdm/users/:mdmUserId`](https://docs.applivery.com/en/api/uem/users/delete-user/) | ✓ | ✓ | – | – | | `mdm.global.mdmUser.update` | [`PUT /mdm/users/:mdmUserId`](https://docs.applivery.com/en/api/uem/users/put-user/) | ✓ | ✓ | ✓ | – | | `mdm.global.networkStatus.get` | [`GET /mdm/network-status/:type/:identifier/:mdmNetworkStatusId`](https://docs.applivery.com/en/api/uem/network-status/get-network-status/) | ✓ | ✓ | ✓ | ✓ | | `mdm.global.networkStatus.list` | [`GET /mdm/network-status/:type/:identifier`](https://docs.applivery.com/en/api/uem/network-status/get-network-statuses/) | ✓ | ✓ | ✓ | ✓ | | `mdm.global.networkStatus.remove` | [`DELETE /mdm/network-status/:type/:identifier/:mdmNetworkStatusId`](https://docs.applivery.com/en/api/uem/network-status/delete-network-status/) | ✓ | ✓ | – | – | | `mdm.global.packageTime.get` | [`GET /mdm/package-times/:type/:identifier/:mdmPackageTimeId`](https://docs.applivery.com/en/api/uem/package-times/get-package-time/) | ✓ | ✓ | ✓ | ✓ | | `mdm.global.packageTime.list` | [`GET /mdm/package-times/:type/:identifier`](https://docs.applivery.com/en/api/uem/package-times/get-package-times/) | ✓ | ✓ | ✓ | ✓ | | `mdm.global.packageTime.remove` | [`DELETE /mdm/package-times/:type/:identifier/:mdmPackageTimeId`](https://docs.applivery.com/en/api/uem/package-times/delete-package-time/) | ✓ | ✓ | – | – | | `mdm.global.packageTransfer.get` | [`GET /mdm/package-transfers/:type/:identifier/:mdmPackageTransferId`](https://docs.applivery.com/en/api/uem/package-transfers/get-package-transfer/) | ✓ | ✓ | ✓ | ✓ | | `mdm.global.packageTransfer.list` | [`GET /mdm/package-transfers/:type/:identifier`](https://docs.applivery.com/en/api/uem/package-transfers/get-package-transfers/) | ✓ | ✓ | ✓ | ✓ | | `mdm.global.packageTransfer.remove` | [`DELETE /mdm/package-transfers/:type/:identifier/:mdmPackageTransferId`](https://docs.applivery.com/en/api/uem/package-transfers/delete-package-transfer/) | ✓ | ✓ | – | – | | `mdm.global.policy.list` | [`GET /mdm/policies`](https://docs.applivery.com/en/api/uem/policies/get-policies/) | ✓ | ✓ | ✓ | ✓ | | `mdm.global.policySync.list` | [`GET /mdm/policy-sync`](https://docs.applivery.com/en/api/uem/policy-sync/get-policy-sync/) | ✓ | ✓ | ✓ | ✓ | | `mdm.global.policySync.remove` | — | ✓ | ✓ | ✓ | ✓ | | `mdm.global.policyTemplate.create` | — | ✓ | ✓ | ✓ | – | | `mdm.global.policyTemplate.get` | — | ✓ | ✓ | ✓ | ✓ | | `mdm.global.policyTemplate.list` | — | ✓ | ✓ | ✓ | ✓ | | `mdm.global.policyTemplate.remove` | — | ✓ | ✓ | ✓ | – | | `mdm.global.policyTemplate.update` | — | ✓ | ✓ | ✓ | – | | `mdm.global.pushNotification.send` | [`POST /mdm/push-notifications/send`](https://docs.applivery.com/en/api/uem/push-notifications/post-send/) | ✓ | ✓ | – | – | | `mdm.global.smartAttribute.create` | [`POST /smart-attributes`](https://docs.applivery.com/en/api/platform/smart-attributes/post-smart-attribute/) | ✓ | ✓ | ✓ | – | | `mdm.global.smartAttribute.get` | [`GET /smart-attributes/:smartAttributeId`](https://docs.applivery.com/en/api/platform/smart-attributes/get-smart-attribute/)
[`GET /smart-attributes/:smartAttributeId/assignments`](https://docs.applivery.com/en/api/platform/smart-attributes/get-assignments/) | ✓ | ✓ | ✓ | ✓ | | `mdm.global.smartAttribute.list` | [`GET /smart-attributes`](https://docs.applivery.com/en/api/platform/smart-attributes/get-smart-attributes/) | ✓ | ✓ | ✓ | ✓ | | `mdm.global.smartAttribute.remove` | [`DELETE /smart-attributes/:smartAttributeId`](https://docs.applivery.com/en/api/platform/smart-attributes/delete-smart-attribute/) | ✓ | ✓ | ✓ | – | | `mdm.global.smartAttribute.update` | [`PUT /smart-attributes/:smartAttributeId`](https://docs.applivery.com/en/api/platform/smart-attributes/put-smart-attribute/) | ✓ | ✓ | ✓ | – | | `mdm.global.status.get` | [`GET /mdm`](https://docs.applivery.com/en/api/uem/status/get-mdm/) | ✓ | ✓ | ✓ | ✓ | | `mdm.global.tenantTmv.read` | — | ✓ | ✓ | – | – | | `mdm.global.tenantTmv.update` | — | ✓ | ✓ | – | – | **Apple (mdm.apple) · 101 acciones, 121 endpoints** | Permiso | Endpoints | O | A | E | V | | --- | --- | :-: | :-: | :-: | :-: | | `mdm.apple.application.create` | [`POST /mdm/apple/enterprise/applications`](https://docs.applivery.com/en/api/apple/applications/post-application/) | ✓ | ✓ | ✓ | – | | `mdm.apple.application.get` | [`GET /mdm/apple/enterprise/applications/:admApplicationId`](https://docs.applivery.com/en/api/apple/applications/get-application/) | ✓ | ✓ | ✓ | ✓ | | `mdm.apple.application.list` | [`GET /mdm/apple/enterprise/applications`](https://docs.applivery.com/en/api/apple/applications/get-applications/) | ✓ | ✓ | ✓ | ✓ | | `mdm.apple.application.remove` | [`DELETE /mdm/apple/enterprise/applications/:admApplicationId`](https://docs.applivery.com/en/api/apple/applications/delete-application/) | ✓ | ✓ | – | – | | `mdm.apple.application.search` | [`GET /mdm/apple/enterprise/applications/search`](https://docs.applivery.com/en/api/apple/applications/get-search/) | ✓ | ✓ | ✓ | ✓ | | `mdm.apple.application.update` | [`PUT /mdm/apple/enterprise/applications/:admApplicationId`](https://docs.applivery.com/en/api/apple/applications/put-application/) | ✓ | ✓ | ✓ | – | | `mdm.apple.command.cancel` | [`POST /mdm/apple/enterprise/commands/:targetType/:targetId/:admCommandId/cancel`](https://docs.applivery.com/en/api/apple/commands/post-cancel/) | ✓ | ✓ | – | – | | `mdm.apple.command.create` | [`POST /mdm/apple/enterprise/commands/:targetType`](https://docs.applivery.com/en/api/apple/commands/post-bulk/)
[`POST /mdm/apple/enterprise/commands/:targetType/:targetId`](https://docs.applivery.com/en/api/apple/commands/post-command/) | ✓ | ✓ | – | – | | `mdm.apple.command.get` | [`GET /mdm/apple/enterprise/commands/:targetType/:targetId/:admCommandId`](https://docs.applivery.com/en/api/apple/commands/get-command/) | ✓ | ✓ | ✓ | – | | `mdm.apple.command.list` | [`GET /mdm/apple/enterprise/commands/:targetType/:targetId`](https://docs.applivery.com/en/api/apple/commands/get-commands/)
[`GET /mdm/apple/enterprise/commands/:targetType/:targetId/grouped`](https://docs.applivery.com/en/api/apple/commands/get-grouped/) | ✓ | ✓ | ✓ | – | | `mdm.apple.defaultDeviceConfig.create` | [`POST /mdm/apple/enterprise/default-config`](https://docs.applivery.com/en/api/apple/default-config/post-default-config/) | ✓ | ✓ | – | – | | `mdm.apple.defaultDeviceConfig.get` | [`GET /mdm/apple/enterprise/default-config/:admDefaultDeviceConfigId`](https://docs.applivery.com/en/api/apple/default-config/get-default-config-by-id/) | ✓ | ✓ | – | – | | `mdm.apple.defaultDeviceConfig.list` | [`GET /mdm/apple/enterprise/default-config`](https://docs.applivery.com/en/api/apple/default-config/get-default-config/) | ✓ | ✓ | – | – | | `mdm.apple.defaultDeviceConfig.remove` | [`DELETE /mdm/apple/enterprise/default-config/:admDefaultDeviceConfigId`](https://docs.applivery.com/en/api/apple/default-config/delete-default-config/) | ✓ | ✓ | – | – | | `mdm.apple.defaultDeviceConfig.update` | [`PUT /mdm/apple/enterprise/default-config/:admDefaultDeviceConfigId`](https://docs.applivery.com/en/api/apple/default-config/put-default-config/) | ✓ | ✓ | – | – | | `mdm.apple.depDevice.assignProfile` | [`POST /mdm/apple/enterprise/dep/devices/:admDepDeviceId/assign-profile`](https://docs.applivery.com/en/api/apple/dep-devices/post-assign-profile/) | ✓ | ✓ | – | – | | `mdm.apple.depDevice.disown` | [`POST /mdm/apple/enterprise/dep/devices/:admDepDeviceId/disown`](https://docs.applivery.com/en/api/apple/dep-devices/post-disown/) | ✓ | ✓ | – | – | | `mdm.apple.depDevice.get` | [`GET /mdm/apple/enterprise/dep/devices/:admDepDeviceId`](https://docs.applivery.com/en/api/apple/dep-devices/get-device/) | ✓ | ✓ | – | – | | `mdm.apple.depDevice.list` | [`GET /mdm/apple/enterprise/dep/devices`](https://docs.applivery.com/en/api/apple/dep-devices/get-devices/) | ✓ | ✓ | – | – | | `mdm.apple.depDevice.lock` | [`POST /mdm/apple/enterprise/dep/devices/:admDepDeviceId/lock`](https://docs.applivery.com/en/api/apple/dep-devices/post-lock/) | ✓ | ✓ | – | – | | `mdm.apple.depDevice.removeProfile` | [`DELETE /mdm/apple/enterprise/dep/devices/:admDepDeviceId/remove-profile`](https://docs.applivery.com/en/api/apple/dep-devices/delete-remove-profile/) | ✓ | ✓ | – | – | | `mdm.apple.depDevice.sync` | [`GET /mdm/apple/enterprise/dep/devices/sync`](https://docs.applivery.com/en/api/apple/dep-devices/get-sync/)
[`GET /mdm/apple/enterprise/dep/devices/sync-all`](https://docs.applivery.com/en/api/apple/dep-devices/get-sync-all/)
[`GET /mdm/apple/enterprise/dep/devices/sync-transaction`](https://docs.applivery.com/en/api/apple/dep-devices/sync-transaction/get/)
[`GET /mdm/apple/enterprise/dep/devices/sync-transaction/:admDepSyncTransactionId`](https://docs.applivery.com/en/api/apple/dep-devices/sync-transaction/get-by-id/) | ✓ | ✓ | – | – | | `mdm.apple.depDevice.update` | [`PUT /mdm/apple/enterprise/dep/devices/:admDepDeviceId`](https://docs.applivery.com/en/api/apple/dep-devices/put-device/) | ✓ | ✓ | – | – | | `mdm.apple.depProfile.create` | [`POST /mdm/apple/enterprise/dep/profiles`](https://docs.applivery.com/en/api/apple/dep-profiles/post-profile/) | ✓ | ✓ | – | – | | `mdm.apple.depProfile.get` | [`GET /mdm/apple/enterprise/dep/profiles/:admDepProfileId`](https://docs.applivery.com/en/api/apple/dep-profiles/get-profile/) | ✓ | ✓ | – | – | | `mdm.apple.depProfile.list` | [`GET /mdm/apple/enterprise/dep/profiles`](https://docs.applivery.com/en/api/apple/dep-profiles/get-profiles/) | ✓ | ✓ | – | – | | `mdm.apple.depProfile.remove` | [`DELETE /mdm/apple/enterprise/dep/profiles/:admDepProfileId`](https://docs.applivery.com/en/api/apple/dep-profiles/delete-profile/) | ✓ | ✓ | – | – | | `mdm.apple.device.action` | [`POST /mdm/apple/enterprise/devices/:admDeviceId/action`](https://docs.applivery.com/en/api/apple/devices/post-action/)
[`GET /mdm/apple/enterprise/devices/:admDeviceId/agent-cleanup`](https://docs.applivery.com/en/api/apple/devices/get-agent-cleanup/)
[`GET /mdm/apple/enterprise/devices/:admDeviceId/agent-recovery`](https://docs.applivery.com/en/api/apple/devices/get-agent-recovery/)
[`GET /mdm/apple/enterprise/devices/:admDeviceId/agent-recovery-managed-configuration`](https://docs.applivery.com/en/api/apple/devices/get-agent-recovery-managed-configuration/)
[`GET /mdm/apple/enterprise/devices/:admDeviceId/setup-assistant-recovery-managed-configuration`](https://docs.applivery.com/en/api/apple/devices/get-setup-assistant-recovery-managed-configuration/) | ✓ | ✓ | – | – | | `mdm.apple.device.create` | — | ✓ | ✓ | – | – | | `mdm.apple.device.get` | [`GET /mdm/apple/enterprise/devices/:admDeviceId`](https://docs.applivery.com/en/api/apple/devices/get-device/)
[`GET /mdm/apple/enterprise/devices/:admDeviceId/agent-config`](https://docs.applivery.com/en/api/apple/devices/get-agent-config/)
[`GET /mdm/apple/enterprise/devices/:admDeviceId/agent-config-assets`](https://docs.applivery.com/en/api/apple/devices/get-agent-config-assets/)
[`GET /mdm/apple/enterprise/devices/:admDeviceId/agent-config-assets-setup`](https://docs.applivery.com/en/api/apple/devices/get-agent-config-assets-setup/)
[`GET /mdm/apple/enterprise/devices/:admDeviceId/agent-tokens`](https://docs.applivery.com/en/api/apple/devices/get-agent-tokens/)
[`GET /mdm/apple/enterprise/devices/:admDeviceId/applications`](https://docs.applivery.com/en/api/apple/devices/get-applications/)
[`GET /mdm/apple/enterprise/devices/:admDeviceId/scheduler-scripts`](https://docs.applivery.com/en/api/apple/devices/get-scheduler-scripts/) | ✓ | ✓ | ✓ | ✓ | | `mdm.apple.device.getActivationLockBypassCode` | [`GET /mdm/apple/enterprise/devices/:admDeviceId/activation-lock-bypass-code`](https://docs.applivery.com/en/api/apple/devices/get-activation-lock-bypass-code/) | ✓ | ✓ | – | – | | `mdm.apple.device.getFileVaultRecoveryKey` | [`GET /mdm/apple/enterprise/devices/:admDeviceId/file-vault-recovery-key`](https://docs.applivery.com/en/api/apple/devices/get-file-vault-recovery-key/) | ✓ | ✓ | – | – | | `mdm.apple.device.list` | [`GET /mdm/apple/enterprise/devices`](https://docs.applivery.com/en/api/apple/devices/get-devices/) | ✓ | ✓ | ✓ | ✓ | | `mdm.apple.device.move` | [`PUT /mdm/apple/enterprise/devices/:admDeviceId/move`](https://docs.applivery.com/en/api/apple/devices/put-move/) | ✓ | ✓ | – | – | | `mdm.apple.device.notify` | [`GET /mdm/apple/enterprise/devices/:admDeviceId/check-notify`](https://docs.applivery.com/en/api/apple/devices/get-check-notify/)
[`GET /mdm/apple/enterprise/devices/:admDeviceId/notify`](https://docs.applivery.com/en/api/apple/devices/get-notify/) | ✓ | ✓ | ✓ | – | | `mdm.apple.device.refresh` | [`GET /mdm/apple/enterprise/devices/:admDeviceId/refresh`](https://docs.applivery.com/en/api/apple/devices/get-refresh/) | ✓ | ✓ | ✓ | – | | `mdm.apple.device.reinstall` | [`GET /mdm/apple/enterprise/devices/:admDeviceId/reinstall`](https://docs.applivery.com/en/api/apple/devices/get-reinstall/) | ✓ | ✓ | – | – | | `mdm.apple.device.remove` | [`DELETE /mdm/apple/enterprise/devices/:admDeviceId`](https://docs.applivery.com/en/api/apple/devices/delete-device/) | ✓ | ✓ | – | – | | `mdm.apple.device.sync` | [`GET /mdm/apple/enterprise/devices/:admDeviceId/sync`](https://docs.applivery.com/en/api/apple/devices/get-sync/) | ✓ | ✓ | ✓ | – | | `mdm.apple.device.unlock` | [`GET /mdm/apple/enterprise/devices/:admDeviceId/unlock`](https://docs.applivery.com/en/api/apple/devices/get-unlock/) | ✓ | ✓ | – | – | | `mdm.apple.device.update` | [`PUT /mdm/apple/enterprise/devices/:admDeviceId`](https://docs.applivery.com/en/api/apple/devices/put-device/) | ✓ | ✓ | ✓ | – | | `mdm.apple.deviceNotification.action` | [`POST /mdm/apple/enterprise/devices/:admDeviceId/notifications`](https://docs.applivery.com/en/api/apple/devices/notifications/post-notification/) | ✓ | ✓ | – | – | | `mdm.apple.deviceScriptLog.get` | [`GET /mdm/apple/enterprise/devices/:admDeviceId/script-logs/:admDeviceScriptLogId`](https://docs.applivery.com/en/api/apple/devices/script-logs/get-script-log/) | ✓ | ✓ | ✓ | ✓ | | `mdm.apple.deviceScriptLog.invalidate` | [`POST /mdm/apple/enterprise/devices/:admDeviceId/script-logs/:admDeviceScriptLogId/invalidate`](https://docs.applivery.com/en/api/apple/devices/script-logs/post-invalidate/)
[`POST /mdm/apple/enterprise/devices/:admDeviceId/script-logs/invalidate-once`](https://docs.applivery.com/en/api/apple/devices/script-logs/post-invalidate-once/) | ✓ | ✓ | ✓ | ✓ | | `mdm.apple.deviceScriptLog.list` | [`GET /mdm/apple/enterprise/devices/:admDeviceId/script-logs`](https://docs.applivery.com/en/api/apple/devices/script-logs/get-script-logs/)
[`GET /mdm/apple/enterprise/devices/:admDeviceId/script-logs/summary`](https://docs.applivery.com/en/api/apple/devices/script-logs/get-summary/) | ✓ | ✓ | ✓ | ✓ | | `mdm.apple.deviceUser.get` | [`GET /mdm/apple/enterprise/devices/:admDeviceId/users/:admDeviceUserId`](https://docs.applivery.com/en/api/apple/devices/users/get-user/)
[`GET /mdm/apple/enterprise/devices/:admDeviceId/users/:admDeviceUserId/applications`](https://docs.applivery.com/en/api/apple/devices/users/get-applications/) | ✓ | ✓ | ✓ | ✓ | | `mdm.apple.deviceUser.list` | [`GET /mdm/apple/enterprise/devices/:admDeviceId/users`](https://docs.applivery.com/en/api/apple/devices/users/get-users/) | ✓ | ✓ | ✓ | ✓ | | `mdm.apple.deviceUser.notify` | [`GET /mdm/apple/enterprise/devices/:admDeviceId/users/:admDeviceUserId/notify`](https://docs.applivery.com/en/api/apple/devices/users/get-notify/) | ✓ | ✓ | ✓ | – | | `mdm.apple.deviceUser.refresh` | [`GET /mdm/apple/enterprise/devices/:admDeviceId/users/:admDeviceUserId/refresh`](https://docs.applivery.com/en/api/apple/devices/users/get-refresh/) | ✓ | ✓ | ✓ | – | | `mdm.apple.deviceUser.remove` | — | ✓ | ✓ | – | – | | `mdm.apple.deviceUser.sync` | [`GET /mdm/apple/enterprise/devices/:admDeviceId/users/:admDeviceUserId/sync`](https://docs.applivery.com/en/api/apple/devices/users/get-sync/) | ✓ | ✓ | ✓ | – | | `mdm.apple.deviceUser.update` | [`PUT /mdm/apple/enterprise/devices/:admDeviceId/users/:admDeviceUserId`](https://docs.applivery.com/en/api/apple/devices/users/put-user/) | ✓ | ✓ | – | – | | `mdm.apple.enrollmentTemplate.create` | [`POST /mdm/apple/enterprise/enrollment-templates`](https://docs.applivery.com/en/api/apple/enrollment-templates/post-enrollment-template/) | ✓ | ✓ | ✓ | – | | `mdm.apple.enrollmentTemplate.get` | [`GET /mdm/apple/enterprise/enrollment-templates/:admEnrollmentTemplateId`](https://docs.applivery.com/en/api/apple/enrollment-templates/get-enrollment-template/)
[`GET /mdm/apple/enterprise/enrollment-templates/:admEnrollmentTemplateId/assignations`](https://docs.applivery.com/en/api/apple/enrollment-templates/get-assignations/) | ✓ | ✓ | ✓ | ✓ | | `mdm.apple.enrollmentTemplate.list` | [`GET /mdm/apple/enterprise/enrollment-templates`](https://docs.applivery.com/en/api/apple/enrollment-templates/get-enrollment-templates/) | ✓ | ✓ | ✓ | ✓ | | `mdm.apple.enrollmentTemplate.remove` | [`DELETE /mdm/apple/enterprise/enrollment-templates/:admEnrollmentTemplateId`](https://docs.applivery.com/en/api/apple/enrollment-templates/delete-enrollment-template/) | ✓ | ✓ | – | – | | `mdm.apple.enrollmentTemplate.templates` | — | ✓ | ✓ | – | – | | `mdm.apple.enrollmentTemplate.update` | [`PUT /mdm/apple/enterprise/enrollment-templates/:admEnrollmentTemplateId`](https://docs.applivery.com/en/api/apple/enrollment-templates/put-enrollment-template/) | ✓ | ✓ | ✓ | – | | `mdm.apple.enrollmentToken.create` | [`POST /mdm/apple/enterprise/enrollment-tokens`](https://docs.applivery.com/en/api/apple/enrollment-tokens/post-enrollment-token/)
[`POST /mdm/apple/enterprise/enrollment-tokens/bulk`](https://docs.applivery.com/en/api/apple/enrollment-tokens/post-bulk/) | ✓ | ✓ | – | – | | `mdm.apple.enrollmentToken.get` | [`GET /mdm/apple/enterprise/enrollment-tokens/:admEnrollmentTokenId`](https://docs.applivery.com/en/api/apple/enrollment-tokens/get-enrollment-token/) | ✓ | ✓ | ✓ | ✓ | | `mdm.apple.enrollmentToken.list` | [`GET /mdm/apple/enterprise/enrollment-tokens`](https://docs.applivery.com/en/api/apple/enrollment-tokens/get-enrollment-tokens/) | ✓ | ✓ | ✓ | ✓ | | `mdm.apple.enrollmentToken.remove` | [`DELETE /mdm/apple/enterprise/enrollment-tokens/:admEnrollmentTokenId`](https://docs.applivery.com/en/api/apple/enrollment-tokens/delete-enrollment-token/) | ✓ | ✓ | – | – | | `mdm.apple.enrollmentToken.update` | [`PUT /mdm/apple/enterprise/enrollment-tokens/:admEnrollmentTokenId`](https://docs.applivery.com/en/api/apple/enrollment-tokens/put-enrollment-token/) | ✓ | ✓ | ✓ | – | | `mdm.apple.enterprise.applepush` | — | ✓ | ✓ | – | – | | `mdm.apple.enterprise.create` | [`POST /mdm/apple/enterprise`](https://docs.applivery.com/en/api/apple/enterprise/post-enterprise/) | ✓ | ✓ | – | – | | `mdm.apple.enterprise.get` | [`GET /mdm/apple/enterprise`](https://docs.applivery.com/en/api/apple/enterprise/get-enterprise/) | ✓ | ✓ | ✓ | ✓ | | `mdm.apple.enterprise.reinstallDevices` | [`GET /mdm/apple/enterprise/reinstall-devices`](https://docs.applivery.com/en/api/apple/enterprise/get-reinstall-devices/) | ✓ | ✓ | – | – | | `mdm.apple.enterprise.search` | [`GET /mdm/apple/enterprise/search`](https://docs.applivery.com/en/api/apple/enterprise/get-search/)
[`POST /mdm/apple/enterprise/search-bundle-ids`](https://docs.applivery.com/en/api/apple/enterprise/post-search-bundle-ids/) | ✓ | ✓ | ✓ | ✓ | | `mdm.apple.enterprise.update` | [`PUT /mdm/apple/enterprise`](https://docs.applivery.com/en/api/apple/enterprise/put-enterprise/)
[`PUT /mdm/apple/enterprise/dep`](https://docs.applivery.com/en/api/apple/enterprise/put-dep/) | ✓ | ✓ | – | – | | `mdm.apple.enterprise.uploadIdentity` | — | ✓ | ✓ | – | – | | `mdm.apple.policy.composition` | [`POST /mdm/apple/enterprise/policies/composition`](https://docs.applivery.com/en/api/apple/policies/post-composition/) | ✓ | ✓ | ✓ | ✓ | | `mdm.apple.policy.create` | [`POST /mdm/apple/enterprise/policies`](https://docs.applivery.com/en/api/apple/policies/post-policy/) | ✓ | ✓ | ✓ | – | | `mdm.apple.policy.get` | [`GET /mdm/apple/enterprise/policies/:admPolicyId`](https://docs.applivery.com/en/api/apple/policies/get-policy/)
[`GET /mdm/apple/enterprise/policies/:admPolicyId/agent-config`](https://docs.applivery.com/en/api/apple/policies/get-agent-config/)
[`GET /mdm/apple/enterprise/policies/:admPolicyId/assignations`](https://docs.applivery.com/en/api/apple/policies/get-assignations/)
`GET /mdm/apple/enterprise/policies/:admPolicyId/provisioning-profiles/:UUID` | ✓ | ✓ | ✓ | ✓ | | `mdm.apple.policy.list` | [`GET /mdm/apple/enterprise/policies`](https://docs.applivery.com/en/api/apple/policies/get-policies/) | ✓ | ✓ | ✓ | ✓ | | `mdm.apple.policy.remove` | [`DELETE /mdm/apple/enterprise/policies/:admPolicyId`](https://docs.applivery.com/en/api/apple/policies/delete-policy/) | ✓ | ✓ | – | – | | `mdm.apple.policy.templates` | [`GET /mdm/apple/enterprise/policies/templates`](https://docs.applivery.com/en/api/apple/policies/templates/get/)
[`GET /mdm/apple/enterprise/policies/templates/:templateId`](https://docs.applivery.com/en/api/apple/policies/templates/get-by-id/) | ✓ | ✓ | – | – | | `mdm.apple.policy.update` | [`PUT /mdm/apple/enterprise/policies/:admPolicyId`](https://docs.applivery.com/en/api/apple/policies/put-policy/) | ✓ | ✓ | ✓ | – | | `mdm.apple.profile.create` | [`POST /mdm/apple/enterprise/profiles`](https://docs.applivery.com/en/api/apple/profiles/post-profile/) | ✓ | ✓ | – | – | | `mdm.apple.profile.get` | [`GET /mdm/apple/enterprise/profiles/:admProfileId`](https://docs.applivery.com/en/api/apple/profiles/get-profile/) | ✓ | ✓ | ✓ | ✓ | | `mdm.apple.profile.list` | [`GET /mdm/apple/enterprise/profiles`](https://docs.applivery.com/en/api/apple/profiles/get-profiles/) | ✓ | ✓ | ✓ | ✓ | | `mdm.apple.profile.remove` | [`DELETE /mdm/apple/enterprise/profiles/:admProfileId`](https://docs.applivery.com/en/api/apple/profiles/delete-profile/) | ✓ | ✓ | – | – | | `mdm.apple.profile.update` | [`PUT /mdm/apple/enterprise/profiles/:admProfileId`](https://docs.applivery.com/en/api/apple/profiles/put-profile/) | ✓ | ✓ | – | – | | `mdm.apple.router.get` | [`GET /mdm/apple/enterprise/router/:admRouterId`](https://docs.applivery.com/en/api/apple/router/get-router-by-id/) | ✓ | ✓ | ✓ | ✓ | | `mdm.apple.router.list` | [`GET /mdm/apple/enterprise/router`](https://docs.applivery.com/en/api/apple/router/get-router/) | ✓ | ✓ | ✓ | ✓ | | `mdm.apple.syncHistory.list` | [`GET /mdm/apple/enterprise/sync-history/:targetType/:targetId`](https://docs.applivery.com/en/api/apple/sync-history/get-sync-history/) | ✓ | ✓ | ✓ | ✓ | | `mdm.apple.vppAsset.assignments` | [`GET /mdm/apple/enterprise/vpp/locations/:admVppLocationId/assets/assignments`](https://docs.applivery.com/en/api/apple/locations/assets/get-assignments/) | ✓ | ✓ | ✓ | – | | `mdm.apple.vppAsset.associate` | [`POST /mdm/apple/enterprise/vpp/locations/:admVppLocationId/assets/associate`](https://docs.applivery.com/en/api/apple/locations/assets/post-associate/) | ✓ | ✓ | ✓ | – | | `mdm.apple.vppAsset.disassociate` | [`POST /mdm/apple/enterprise/vpp/locations/:admVppLocationId/assets/disassociate`](https://docs.applivery.com/en/api/apple/locations/assets/post-disassociate/) | ✓ | ✓ | ✓ | – | | `mdm.apple.vppAsset.list` | [`GET /mdm/apple/enterprise/vpp/locations/:admVppLocationId/assets`](https://docs.applivery.com/en/api/apple/locations/assets/get/) | ✓ | ✓ | ✓ | – | | `mdm.apple.vppAsset.revoke` | [`POST /mdm/apple/enterprise/vpp/locations/:admVppLocationId/assets/revoke`](https://docs.applivery.com/en/api/apple/locations/assets/post-revoke/) | ✓ | ✓ | ✓ | – | | `mdm.apple.vppEvent.check` | [`GET /mdm/apple/enterprise/vpp/locations/:admVppLocationId/events/check/:eventId`](https://docs.applivery.com/en/api/apple/event-check/get-check/) | ✓ | ✓ | ✓ | – | | `mdm.apple.vppLocation.create` | [`POST /mdm/apple/enterprise/vpp/locations`](https://docs.applivery.com/en/api/apple/locations/post-location/) | ✓ | ✓ | – | – | | `mdm.apple.vppLocation.get` | [`GET /mdm/apple/enterprise/vpp/locations/:admVppLocationId`](https://docs.applivery.com/en/api/apple/locations/get-location/) | ✓ | ✓ | ✓ | – | | `mdm.apple.vppLocation.list` | [`GET /mdm/apple/enterprise/vpp/locations`](https://docs.applivery.com/en/api/apple/locations/get-locations/) | ✓ | ✓ | ✓ | – | | `mdm.apple.vppLocation.remove` | [`DELETE /mdm/apple/enterprise/vpp/locations/:admVppLocationId`](https://docs.applivery.com/en/api/apple/locations/delete-location/) | ✓ | ✓ | – | – | | `mdm.apple.vppLocation.update` | — | ✓ | ✓ | – | – | | `mdm.apple.vppUser.create` | [`POST /mdm/apple/enterprise/vpp/locations/:admVppLocationId/users`](https://docs.applivery.com/en/api/apple/locations/users/post/) | ✓ | ✓ | ✓ | – | | `mdm.apple.vppUser.get` | — | ✓ | ✓ | ✓ | – | | `mdm.apple.vppUser.list` | [`GET /mdm/apple/enterprise/vpp/locations/:admVppLocationId/users`](https://docs.applivery.com/en/api/apple/locations/users/get/)
[`GET /mdm/apple/enterprise/vpp/locations/:admVppLocationId/users/all`](https://docs.applivery.com/en/api/apple/locations/users/get-all/) | ✓ | ✓ | ✓ | – | | `mdm.apple.vppUser.retire` | [`DELETE /mdm/apple/enterprise/vpp/locations/:admVppLocationId/users/:mdmUserId`](https://docs.applivery.com/en/api/apple/locations/users/delete-by-id/) | ✓ | ✓ | ✓ | – | | `mdm.apple.vppUser.update` | — | ✓ | ✓ | ✓ | – | **Android Enterprise (mdm.android) · 60 acciones, 70 endpoints** | Permiso | Endpoints | O | A | E | V | | --- | --- | :-: | :-: | :-: | :-: | | `mdm.android.application.create` | [`POST /mdm/android/enterprise/applications/emm-application`](https://docs.applivery.com/en/api/android/applications/post-application/) | ✓ | ✓ | ✓ | – | | `mdm.android.application.get` | [`GET /mdm/android/enterprise/applications/emm-application/:emmApplicationId`](https://docs.applivery.com/en/api/android/applications/get-application/) | ✓ | ✓ | ✓ | ✓ | | `mdm.android.application.getApplication` | [`GET /mdm/android/enterprise/applications/:applicationName`](https://docs.applivery.com/en/api/android/applications/get-by-name/) | ✓ | ✓ | ✓ | ✓ | | `mdm.android.application.list` | [`GET /mdm/android/enterprise/applications/emm-application`](https://docs.applivery.com/en/api/android/applications/get-applications/) | ✓ | ✓ | ✓ | ✓ | | `mdm.android.application.remove` | [`DELETE /mdm/android/enterprise/applications/emm-application/:emmApplicationId`](https://docs.applivery.com/en/api/android/applications/delete-application/) | ✓ | ✓ | – | – | | `mdm.android.application.update` | [`PUT /mdm/android/enterprise/applications/emm-application/:emmApplicationId`](https://docs.applivery.com/en/api/android/applications/put-application/) | ✓ | ✓ | ✓ | – | | `mdm.android.certificateReport.get` | [`GET /mdm/android/enterprise/devices/:emmDeviceId/certificate-reports/history/:historyId`](https://docs.applivery.com/en/api/android/certificate-report/history/get-by-id/) | ✓ | ✓ | ✓ | ✓ | | `mdm.android.certificateReport.list` | [`GET /mdm/android/enterprise/devices/:emmDeviceId/certificate-reports/history`](https://docs.applivery.com/en/api/android/certificate-report/history/get/) | ✓ | ✓ | ✓ | ✓ | | `mdm.android.certificateReport.reset` | [`POST /mdm/android/enterprise/devices/:emmDeviceId/certificate-reports/reset`](https://docs.applivery.com/en/api/android/certificate-report/post-reset/) | ✓ | ✓ | – | – | | `mdm.android.command.cancel` | [`POST /mdm/android/enterprise/devices/:emmDeviceId/commands/:emmCommandId/cancel`](https://docs.applivery.com/en/api/android/commands/post-cancel/) | ✓ | ✓ | – | – | | `mdm.android.command.create` | [`POST /mdm/android/enterprise/devices/:emmDeviceId/commands`](https://docs.applivery.com/en/api/android/commands/post-command/) | ✓ | ✓ | – | – | | `mdm.android.command.get` | [`GET /mdm/android/enterprise/devices/:emmDeviceId/commands/:emmCommandId`](https://docs.applivery.com/en/api/android/commands/get-command/) | ✓ | ✓ | ✓ | – | | `mdm.android.command.list` | [`GET /mdm/android/enterprise/devices/:emmDeviceId/commands`](https://docs.applivery.com/en/api/android/commands/get-commands/) | ✓ | ✓ | ✓ | – | | `mdm.android.device.action` | [`POST /mdm/android/enterprise/devices/:emmDeviceId/action`](https://docs.applivery.com/en/api/android/devices/post-action/) | ✓ | ✓ | – | – | | `mdm.android.device.create` | — | ✓ | ✓ | – | – | | `mdm.android.device.emmCommandBulk` | [`POST /mdm/android/enterprise/devices/commands`](https://docs.applivery.com/en/api/android/devices/post-commands/) | ✓ | ✓ | – | – | | `mdm.android.device.get` | [`GET /mdm/android/enterprise/devices/:emmDeviceId`](https://docs.applivery.com/en/api/android/devices/get-device/)
[`GET /mdm/android/enterprise/devices/:emmDeviceId/agent-config`](https://docs.applivery.com/en/api/android/devices/agent/get-config/)
[`GET /mdm/android/enterprise/devices/:emmDeviceId/agent-config-assets`](https://docs.applivery.com/en/api/android/devices/agent/get-config-assets/)
[`GET /mdm/android/enterprise/devices/:emmDeviceId/agent-tokens`](https://docs.applivery.com/en/api/android/devices/agent/get-tokens/)
[`GET /mdm/android/enterprise/devices/:emmDeviceId/applications`](https://docs.applivery.com/en/api/android/devices/get-applications/)
[`GET /mdm/android/enterprise/devices/:emmDeviceId/events`](https://docs.applivery.com/en/api/android/devices/get-events/)
[`GET /mdm/android/enterprise/devices/:emmDeviceId/launcher-config`](https://docs.applivery.com/en/api/android/devices/get-launcher-config/) | ✓ | ✓ | ✓ | ✓ | | `mdm.android.device.list` | [`GET /mdm/android/enterprise/devices`](https://docs.applivery.com/en/api/android/devices/get-devices/) | ✓ | ✓ | ✓ | ✓ | | `mdm.android.device.move` | [`PUT /mdm/android/enterprise/devices/:emmDeviceId/move`](https://docs.applivery.com/en/api/android/devices/put-move/) | ✓ | ✓ | – | – | | `mdm.android.device.remove` | [`DELETE /mdm/android/enterprise/devices/:emmDeviceId`](https://docs.applivery.com/en/api/android/devices/delete-device/) | ✓ | ✓ | – | – | | `mdm.android.device.sync` | [`GET /mdm/android/enterprise/devices/:emmDeviceId/sync`](https://docs.applivery.com/en/api/android/devices/get-sync/) | ✓ | ✓ | ✓ | – | | `mdm.android.device.update` | [`PUT /mdm/android/enterprise/devices/:emmDeviceId`](https://docs.applivery.com/en/api/android/devices/put-device/) | ✓ | ✓ | ✓ | – | | `mdm.android.deviceNotification.action` | [`POST /mdm/android/enterprise/devices/:emmDeviceId/notifications`](https://docs.applivery.com/en/api/android/notifications/post-notification/) | ✓ | ✓ | – | – | | `mdm.android.directProvisioning.create` | [`POST /mdm/android/enterprise/enrollment-templates/:emmEnrollmentTemplateId/direct-provisioning`](https://docs.applivery.com/en/api/android/enrollment-templates/direct-provisioning/post/) | ✓ | ✓ | ✓ | – | | `mdm.android.directProvisioning.get` | [`GET /mdm/android/enterprise/enrollment-templates/:emmEnrollmentTemplateId/direct-provisioning/:emmDirectProvisioningId`](https://docs.applivery.com/en/api/android/enrollment-templates/direct-provisioning/get-by-id/) | ✓ | ✓ | ✓ | ✓ | | `mdm.android.directProvisioning.list` | [`GET /mdm/android/enterprise/enrollment-templates/:emmEnrollmentTemplateId/direct-provisioning`](https://docs.applivery.com/en/api/android/enrollment-templates/direct-provisioning/get/) | ✓ | ✓ | ✓ | ✓ | | `mdm.android.directProvisioning.remove` | [`DELETE /mdm/android/enterprise/enrollment-templates/:emmEnrollmentTemplateId/direct-provisioning/:emmDirectProvisioningId`](https://docs.applivery.com/en/api/android/enrollment-templates/direct-provisioning/delete-by-id/) | ✓ | ✓ | – | – | | `mdm.android.directProvisioning.update` | [`PUT /mdm/android/enterprise/enrollment-templates/:emmEnrollmentTemplateId/direct-provisioning/:emmDirectProvisioningId`](https://docs.applivery.com/en/api/android/enrollment-templates/direct-provisioning/put-by-id/) | ✓ | ✓ | ✓ | – | | `mdm.android.enrollmentTemplate.create` | [`POST /mdm/android/enterprise/enrollment-templates`](https://docs.applivery.com/en/api/android/enrollment-templates/post-enrollment-template/)
[`POST /mdm/android/enterprise/enrollment-templates/:emmEnrollmentTemplateId/notify`](https://docs.applivery.com/en/api/android/enrollment-templates/post-notify/) | ✓ | ✓ | ✓ | – | | `mdm.android.enrollmentTemplate.get` | [`GET /mdm/android/enterprise/enrollment-templates/:emmEnrollmentTemplateId`](https://docs.applivery.com/en/api/android/enrollment-templates/get-enrollment-template/) | ✓ | ✓ | ✓ | ✓ | | `mdm.android.enrollmentTemplate.list` | [`GET /mdm/android/enterprise/enrollment-templates`](https://docs.applivery.com/en/api/android/enrollment-templates/get-enrollment-templates/) | ✓ | ✓ | ✓ | ✓ | | `mdm.android.enrollmentTemplate.remove` | [`DELETE /mdm/android/enterprise/enrollment-templates/:emmEnrollmentTemplateId`](https://docs.applivery.com/en/api/android/enrollment-templates/delete-enrollment-template/) | ✓ | ✓ | – | – | | `mdm.android.enrollmentTemplate.templates` | — | ✓ | ✓ | – | – | | `mdm.android.enrollmentTemplate.update` | [`PUT /mdm/android/enterprise/enrollment-templates/:emmEnrollmentTemplateId`](https://docs.applivery.com/en/api/android/enrollment-templates/put-enrollment-template/)
[`POST /mdm/android/enterprise/enrollment-templates/:emmEnrollmentTemplateId/default-managed-domain`](https://docs.applivery.com/en/api/android/enrollment-templates/post-default-managed-domain/) | ✓ | ✓ | ✓ | – | | `mdm.android.enrollmentToken.create` | [`POST /mdm/android/enterprise/enrollment-tokens`](https://docs.applivery.com/en/api/android/enrollment-tokens/post-enrollment-token/)
[`POST /mdm/android/enterprise/enrollment-tokens/bulk`](https://docs.applivery.com/en/api/android/enrollment-tokens/post-bulk/) | ✓ | ✓ | – | – | | `mdm.android.enrollmentToken.get` | [`GET /mdm/android/enterprise/enrollment-tokens/:emmEnrollmentTokenId`](https://docs.applivery.com/en/api/android/enrollment-tokens/get-enrollment-token/) | ✓ | ✓ | ✓ | ✓ | | `mdm.android.enrollmentToken.list` | [`GET /mdm/android/enterprise/enrollment-tokens`](https://docs.applivery.com/en/api/android/enrollment-tokens/get-enrollment-tokens/) | ✓ | ✓ | ✓ | ✓ | | `mdm.android.enrollmentToken.remove` | [`DELETE /mdm/android/enterprise/enrollment-tokens/:emmEnrollmentTokenId`](https://docs.applivery.com/en/api/android/enrollment-tokens/delete-enrollment-token/) | ✓ | ✓ | – | – | | `mdm.android.enrollmentToken.update` | [`PUT /mdm/android/enterprise/enrollment-tokens/:emmEnrollmentTokenId`](https://docs.applivery.com/en/api/android/enrollment-tokens/put-enrollment-token/) | ✓ | ✓ | ✓ | – | | `mdm.android.enterprise.create` | [`POST /mdm/android/enterprise`](https://docs.applivery.com/en/api/android/enterprise/post-enterprise/) | ✓ | ✓ | – | – | | `mdm.android.enterprise.generateEnterpriseUpgradeUrl` | [`POST /mdm/android/enterprise/upgrade-url`](https://docs.applivery.com/en/api/android/enterprise/post-upgrade-url/) | ✓ | ✓ | – | – | | `mdm.android.enterprise.generateWebToken` | [`POST /mdm/android/enterprise/web-token`](https://docs.applivery.com/en/api/android/enterprise/post-web-token/) | ✓ | ✓ | – | – | | `mdm.android.enterprise.getByOrganization` | [`GET /mdm/android/enterprise`](https://docs.applivery.com/en/api/android/enterprise/get-enterprise/) | ✓ | ✓ | – | – | | `mdm.android.enterprise.remove` | [`DELETE /mdm/android/enterprise`](https://docs.applivery.com/en/api/android/enterprise/delete-enterprise/) | ✓ | ✓ | – | – | | `mdm.android.enterprise.signupUrlsCreate` | [`POST /mdm/android/enterprise/signup-url`](https://docs.applivery.com/en/api/android/enterprise/post-signup-url/) | ✓ | ✓ | – | – | | `mdm.android.enterprise.sync` | [`GET /mdm/android/enterprise/sync`](https://docs.applivery.com/en/api/android/enterprise/get-sync/) | ✓ | ✓ | – | – | | `mdm.android.enterprise.update` | [`PUT /mdm/android/enterprise`](https://docs.applivery.com/en/api/android/enterprise/put-enterprise/) | ✓ | ✓ | – | – | | `mdm.android.package.get` | [`GET /mdm/android/enterprise/packages/:packageName`](https://docs.applivery.com/en/api/platform/package-information/get-package/) | ✓ | ✓ | ✓ | ✓ | | `mdm.android.policy.composition` | [`POST /mdm/android/enterprise/policies/composition`](https://docs.applivery.com/en/api/android/policies/post-composition/) | ✓ | ✓ | ✓ | ✓ | | `mdm.android.policy.create` | [`POST /mdm/android/enterprise/policies`](https://docs.applivery.com/en/api/android/policies/post-policy/) | ✓ | ✓ | ✓ | – | | `mdm.android.policy.get` | [`GET /mdm/android/enterprise/policies/:emmPolicyId`](https://docs.applivery.com/en/api/android/policies/get-policy/)
[`GET /mdm/android/enterprise/policies/:emmPolicyId/agent-config`](https://docs.applivery.com/en/api/android/policies/get-agent-config/)
[`GET /mdm/android/enterprise/policies/:emmPolicyId/assignations`](https://docs.applivery.com/en/api/android/policies/get-assignations/) | ✓ | ✓ | ✓ | ✓ | | `mdm.android.policy.list` | [`GET /mdm/android/enterprise/policies`](https://docs.applivery.com/en/api/android/policies/get-policies/) | ✓ | ✓ | ✓ | ✓ | | `mdm.android.policy.remove` | [`DELETE /mdm/android/enterprise/policies/:emmPolicyId`](https://docs.applivery.com/en/api/android/policies/delete-policy/) | ✓ | ✓ | – | – | | `mdm.android.policy.templates` | [`GET /mdm/android/enterprise/policies/templates`](https://docs.applivery.com/en/api/android/policies/templates/get/)
[`GET /mdm/android/enterprise/policies/templates/:templateId`](https://docs.applivery.com/en/api/android/policies/templates/get-by-id/) | ✓ | ✓ | – | – | | `mdm.android.policy.update` | [`PUT /mdm/android/enterprise/policies/:emmPolicyId`](https://docs.applivery.com/en/api/android/policies/put-policy/) | ✓ | ✓ | ✓ | – | | `mdm.android.webApp.create` | [`POST /mdm/android/enterprise/web-apps`](https://docs.applivery.com/en/api/android/web-apps/post-web-app/) | ✓ | ✓ | ✓ | – | | `mdm.android.webApp.get` | [`GET /mdm/android/enterprise/web-apps/:emmWebAppId`](https://docs.applivery.com/en/api/android/web-apps/get-web-app/) | ✓ | ✓ | ✓ | ✓ | | `mdm.android.webApp.list` | [`GET /mdm/android/enterprise/web-apps`](https://docs.applivery.com/en/api/android/web-apps/get-web-apps/) | ✓ | ✓ | ✓ | ✓ | | `mdm.android.webApp.remove` | [`DELETE /mdm/android/enterprise/web-apps/:emmWebAppId`](https://docs.applivery.com/en/api/android/web-apps/delete-web-app/) | ✓ | ✓ | – | – | | `mdm.android.webApp.update` | [`PUT /mdm/android/enterprise/web-apps/:emmWebAppId`](https://docs.applivery.com/en/api/android/web-apps/put-web-app/) | ✓ | ✓ | ✓ | – | **AOSP (mdm.aosp) · 34 acciones, 46 endpoints** | Permiso | Endpoints | O | A | E | V | | --- | --- | :-: | :-: | :-: | :-: | | `mdm.aosp.application.create` | [`POST /mdm/aosp/enterprise/applications`](https://docs.applivery.com/en/api/aosp/applications/post-application/) | ✓ | ✓ | ✓ | – | | `mdm.aosp.application.get` | [`GET /mdm/aosp/enterprise/applications/:aosApplicationId`](https://docs.applivery.com/en/api/aosp/applications/get-application/) | ✓ | ✓ | ✓ | ✓ | | `mdm.aosp.application.list` | [`GET /mdm/aosp/enterprise/applications`](https://docs.applivery.com/en/api/aosp/applications/get-applications/) | ✓ | ✓ | ✓ | ✓ | | `mdm.aosp.application.remove` | [`DELETE /mdm/aosp/enterprise/applications/:aosApplicationId`](https://docs.applivery.com/en/api/aosp/applications/delete-application/) | ✓ | ✓ | – | – | | `mdm.aosp.application.update` | [`PUT /mdm/aosp/enterprise/applications/:aosApplicationId`](https://docs.applivery.com/en/api/aosp/applications/put-application/) | ✓ | ✓ | ✓ | – | | `mdm.aosp.command.cancel` | [`POST /mdm/aosp/enterprise/devices/:aosDeviceId/commands/:aosCommandId/cancel`](https://docs.applivery.com/en/api/aosp/commands/post-cancel/) | ✓ | ✓ | – | – | | `mdm.aosp.command.create` | [`POST /mdm/aosp/enterprise/devices/:aosDeviceId/commands`](https://docs.applivery.com/en/api/aosp/commands/post-command/) | ✓ | ✓ | – | – | | `mdm.aosp.command.get` | [`GET /mdm/aosp/enterprise/devices/:aosDeviceId/commands/:aosCommandId`](https://docs.applivery.com/en/api/aosp/commands/get-command/)
[`GET /mdm/aosp/enterprise/devices/:aosDeviceId/commands/:aosCommandId/push-status`](https://docs.applivery.com/en/api/aosp/commands/get-push-status/) | ✓ | ✓ | ✓ | – | | `mdm.aosp.command.list` | [`GET /mdm/aosp/enterprise/devices/:aosDeviceId/commands`](https://docs.applivery.com/en/api/aosp/commands/get-commands/) | ✓ | ✓ | ✓ | – | | `mdm.aosp.device.get` | [`GET /mdm/aosp/enterprise/devices/:aosDeviceId`](https://docs.applivery.com/en/api/aosp/devices/get-device/)
[`GET /mdm/aosp/enterprise/devices/:aosDeviceId/agent-config`](https://docs.applivery.com/en/api/aosp/devices/agent/get-config/)
[`GET /mdm/aosp/enterprise/devices/:aosDeviceId/agent-config-assets`](https://docs.applivery.com/en/api/aosp/devices/agent/get-config-assets/)
[`GET /mdm/aosp/enterprise/devices/:aosDeviceId/applications`](https://docs.applivery.com/en/api/aosp/devices/get-applications/) | ✓ | ✓ | ✓ | ✓ | | `mdm.aosp.device.list` | [`GET /mdm/aosp/enterprise/devices`](https://docs.applivery.com/en/api/aosp/devices/get-devices/) | ✓ | ✓ | ✓ | ✓ | | `mdm.aosp.device.move` | [`PUT /mdm/aosp/enterprise/devices/:aosDeviceId/move`](https://docs.applivery.com/en/api/aosp/devices/put-move/) | ✓ | ✓ | – | – | | `mdm.aosp.device.remove` | [`DELETE /mdm/aosp/enterprise/devices/:aosDeviceId`](https://docs.applivery.com/en/api/aosp/devices/delete-device/) | ✓ | ✓ | – | – | | `mdm.aosp.device.update` | [`PUT /mdm/aosp/enterprise/devices/:aosDeviceId`](https://docs.applivery.com/en/api/aosp/devices/put-device/)
[`POST /mdm/aosp/enterprise/devices/:aosDeviceId/check-update`](https://docs.applivery.com/en/api/aosp/devices/post-check-update/)
[`POST /mdm/aosp/enterprise/devices/:aosDeviceId/report-status`](https://docs.applivery.com/en/api/aosp/devices/post-report-status/)
[`POST /mdm/aosp/enterprise/devices/:aosDeviceId/send-logs`](https://docs.applivery.com/en/api/aosp/devices/post-send-logs/) | ✓ | ✓ | ✓ | – | | `mdm.aosp.enrollmentTemplate.create` | `POST /mdm/aosp/enterprise/enrollment-templates` | ✓ | ✓ | ✓ | – | | `mdm.aosp.enrollmentTemplate.get` | `GET /mdm/aosp/enterprise/enrollment-templates/:aosEnrollmentTemplateId` | ✓ | ✓ | ✓ | ✓ | | `mdm.aosp.enrollmentTemplate.list` | `GET /mdm/aosp/enterprise/enrollment-templates` | ✓ | ✓ | ✓ | ✓ | | `mdm.aosp.enrollmentTemplate.remove` | `DELETE /mdm/aosp/enterprise/enrollment-templates/:aosEnrollmentTemplateId` | ✓ | ✓ | – | – | | `mdm.aosp.enrollmentTemplate.update` | `PUT /mdm/aosp/enterprise/enrollment-templates/:aosEnrollmentTemplateId` | ✓ | ✓ | ✓ | – | | `mdm.aosp.enrollmentToken.create` | [`POST /mdm/aosp/enterprise/enrollment-tokens`](https://docs.applivery.com/en/api/aosp/enrollment-tokens/post-enrollment-token/)
[`POST /mdm/aosp/enterprise/enrollment-tokens/bulk`](https://docs.applivery.com/en/api/aosp/enrollment-tokens/post-bulk/) | ✓ | ✓ | – | – | | `mdm.aosp.enrollmentToken.get` | [`GET /mdm/aosp/enterprise/enrollment-tokens/:aosEnrollmentTokenId`](https://docs.applivery.com/en/api/aosp/enrollment-tokens/get-enrollment-token/) | ✓ | ✓ | ✓ | ✓ | | `mdm.aosp.enrollmentToken.list` | [`GET /mdm/aosp/enterprise/enrollment-tokens`](https://docs.applivery.com/en/api/aosp/enrollment-tokens/get-enrollment-tokens/)
[`GET /mdm/aosp/enterprise/enrollment-tokens/dpc-build-tags`](https://docs.applivery.com/en/api/aosp/enrollment-tokens/get-dpc-build-tags/) | ✓ | ✓ | ✓ | ✓ | | `mdm.aosp.enrollmentToken.remove` | [`DELETE /mdm/aosp/enterprise/enrollment-tokens/:aosEnrollmentTokenId`](https://docs.applivery.com/en/api/aosp/enrollment-tokens/delete-enrollment-token/) | ✓ | ✓ | – | – | | `mdm.aosp.enrollmentToken.update` | [`PUT /mdm/aosp/enterprise/enrollment-tokens/:aosEnrollmentTokenId`](https://docs.applivery.com/en/api/aosp/enrollment-tokens/put-enrollment-token/) | ✓ | ✓ | ✓ | – | | `mdm.aosp.enterprise.create` | [`POST /mdm/aosp/enterprise`](https://docs.applivery.com/en/api/aosp/enterprise/post-enterprise/) | ✓ | ✓ | – | – | | `mdm.aosp.enterprise.get` | [`GET /mdm/aosp/enterprise`](https://docs.applivery.com/en/api/aosp/enterprise/get-enterprise/) | ✓ | ✓ | – | – | | `mdm.aosp.enterprise.remove` | [`DELETE /mdm/aosp/enterprise`](https://docs.applivery.com/en/api/aosp/enterprise/delete-enterprise/) | ✓ | ✓ | – | – | | `mdm.aosp.enterprise.update` | [`PUT /mdm/aosp/enterprise`](https://docs.applivery.com/en/api/aosp/enterprise/put-enterprise/) | ✓ | ✓ | – | – | | `mdm.aosp.policy.composition` | [`POST /mdm/aosp/enterprise/policies/composition`](https://docs.applivery.com/en/api/aosp/policies/post-composition/) | ✓ | ✓ | ✓ | ✓ | | `mdm.aosp.policy.create` | [`POST /mdm/aosp/enterprise/policies`](https://docs.applivery.com/en/api/aosp/policies/post-policy/) | ✓ | ✓ | ✓ | – | | `mdm.aosp.policy.get` | [`GET /mdm/aosp/enterprise/policies/:aosPolicyId`](https://docs.applivery.com/en/api/aosp/policies/get-policy/)
[`GET /mdm/aosp/enterprise/policies/:aosPolicyId/agent-config`](https://docs.applivery.com/en/api/aosp/policies/get-agent-config/)
[`GET /mdm/aosp/enterprise/policies/templates/:templateId`](https://docs.applivery.com/en/api/aosp/policies/templates/get-by-id/) | ✓ | ✓ | ✓ | ✓ | | `mdm.aosp.policy.list` | [`GET /mdm/aosp/enterprise/policies`](https://docs.applivery.com/en/api/aosp/policies/get-policies/)
[`GET /mdm/aosp/enterprise/policies/templates`](https://docs.applivery.com/en/api/aosp/policies/templates/get/) | ✓ | ✓ | ✓ | ✓ | | `mdm.aosp.policy.remove` | [`DELETE /mdm/aosp/enterprise/policies/:aosPolicyId`](https://docs.applivery.com/en/api/aosp/policies/delete-policy/) | ✓ | ✓ | – | – | | `mdm.aosp.policy.update` | [`PUT /mdm/aosp/enterprise/policies/:aosPolicyId`](https://docs.applivery.com/en/api/aosp/policies/put-policy/) | ✓ | ✓ | ✓ | – | **Windows (mdm.windows) · 60 acciones, 70 endpoints** | Permiso | Endpoints | O | A | E | V | | --- | --- | :-: | :-: | :-: | :-: | | `mdm.windows.admxConfig.create` | [`POST /mdm/windows/enterprise/admx-configs`](https://docs.applivery.com/en/api/windows/admx-configs/post-admx-config/) | ✓ | ✓ | ✓ | – | | `mdm.windows.admxConfig.get` | [`GET /mdm/windows/enterprise/admx-configs/:winAdmxConfigId`](https://docs.applivery.com/en/api/windows/admx-configs/get-admx-config/)
[`GET /mdm/windows/enterprise/admx-configs/:winAdmxConfigId/assignations`](https://docs.applivery.com/en/api/windows/admx-configs/get-assignations/) | ✓ | ✓ | ✓ | ✓ | | `mdm.windows.admxConfig.list` | [`GET /mdm/windows/enterprise/admx-configs`](https://docs.applivery.com/en/api/windows/admx-configs/get-admx-configs/) | ✓ | ✓ | ✓ | ✓ | | `mdm.windows.admxConfig.regenerate` | [`GET /mdm/windows/enterprise/admx-configs/:winAdmxConfigId/regenerate`](https://docs.applivery.com/en/api/windows/admx-configs/get-regenerate/) | ✓ | ✓ | – | – | | `mdm.windows.admxConfig.remove` | [`DELETE /mdm/windows/enterprise/admx-configs/:winAdmxConfigId`](https://docs.applivery.com/en/api/windows/admx-configs/delete-admx-config/) | ✓ | ✓ | – | – | | `mdm.windows.admxConfig.update` | — | ✓ | ✓ | ✓ | – | | `mdm.windows.application.create` | [`POST /mdm/windows/enterprise/applications`](https://docs.applivery.com/en/api/windows/applications/post-application/) | ✓ | ✓ | ✓ | – | | `mdm.windows.application.get` | [`GET /mdm/windows/enterprise/applications/:winApplicationId`](https://docs.applivery.com/en/api/windows/applications/get-application/) | ✓ | ✓ | ✓ | ✓ | | `mdm.windows.application.list` | [`GET /mdm/windows/enterprise/applications`](https://docs.applivery.com/en/api/windows/applications/get-applications/) | ✓ | ✓ | ✓ | ✓ | | `mdm.windows.application.remove` | [`DELETE /mdm/windows/enterprise/applications/:winApplicationId`](https://docs.applivery.com/en/api/windows/applications/delete-application/) | ✓ | ✓ | – | – | | `mdm.windows.application.search` | [`GET /mdm/windows/enterprise/applications/search`](https://docs.applivery.com/en/api/windows/applications/get-search/) | ✓ | ✓ | ✓ | ✓ | | `mdm.windows.application.update` | [`PUT /mdm/windows/enterprise/applications/:winApplicationId`](https://docs.applivery.com/en/api/windows/applications/put-application/) | ✓ | ✓ | ✓ | – | | `mdm.windows.command.cancel` | [`POST /mdm/windows/enterprise/devices/:winDeviceId/commands/:winCommandId/:cmdId/cancel`](https://docs.applivery.com/en/api/windows/commands/post-cancel/) | ✓ | ✓ | – | – | | `mdm.windows.command.create` | [`POST /mdm/windows/enterprise/devices/:winDeviceId/commands`](https://docs.applivery.com/en/api/windows/commands/post-command/) | ✓ | ✓ | – | – | | `mdm.windows.command.get` | [`GET /mdm/windows/enterprise/devices/:winDeviceId/commands/:winCommandId`](https://docs.applivery.com/en/api/windows/commands/get-command/)
[`GET /mdm/windows/enterprise/devices/:winDeviceId/commands/:winCommandId/actions`](https://docs.applivery.com/en/api/windows/commands/get-actions/) | ✓ | ✓ | ✓ | – | | `mdm.windows.command.list` | [`GET /mdm/windows/enterprise/devices/:winDeviceId/commands`](https://docs.applivery.com/en/api/windows/commands/get-commands/) | ✓ | ✓ | ✓ | – | | `mdm.windows.defaultDeviceConfig.create` | [`POST /mdm/windows/enterprise/default-config`](https://docs.applivery.com/en/api/windows/default-config/post-default-config/) | ✓ | ✓ | – | – | | `mdm.windows.defaultDeviceConfig.get` | [`GET /mdm/windows/enterprise/default-config/:winDefaultDeviceConfigId`](https://docs.applivery.com/en/api/windows/default-config/get-default-config-by-id/) | ✓ | ✓ | – | – | | `mdm.windows.defaultDeviceConfig.list` | [`GET /mdm/windows/enterprise/default-config`](https://docs.applivery.com/en/api/windows/default-config/get-default-config/) | ✓ | ✓ | – | – | | `mdm.windows.defaultDeviceConfig.remove` | [`DELETE /mdm/windows/enterprise/default-config/:winDefaultDeviceConfigId`](https://docs.applivery.com/en/api/windows/default-config/delete-default-config-by-id/) | ✓ | ✓ | – | – | | `mdm.windows.defaultDeviceConfig.update` | [`PUT /mdm/windows/enterprise/default-config/:winDefaultDeviceConfigId`](https://docs.applivery.com/en/api/windows/default-config/put-default-config-by-id/) | ✓ | ✓ | – | – | | `mdm.windows.device.action` | [`POST /mdm/windows/enterprise/devices/:winDeviceId/action`](https://docs.applivery.com/en/api/windows/devices/post-action/) | ✓ | ✓ | – | – | | `mdm.windows.device.cleanCache` | [`POST /mdm/windows/enterprise/devices/:winDeviceId/clean-cache`](https://docs.applivery.com/en/api/windows/devices/post-clean-cache/) | ✓ | ✓ | – | – | | `mdm.windows.device.create` | — | ✓ | ✓ | – | – | | `mdm.windows.device.get` | [`GET /mdm/windows/enterprise/devices/:winDeviceId`](https://docs.applivery.com/en/api/windows/devices/get-device/)
[`GET /mdm/windows/enterprise/devices/:winDeviceId/agent-config`](https://docs.applivery.com/en/api/windows/devices/get-agent-config/)
[`GET /mdm/windows/enterprise/devices/:winDeviceId/agent-config-assets`](https://docs.applivery.com/en/api/windows/devices/get-agent-config-assets/)
[`GET /mdm/windows/enterprise/devices/:winDeviceId/agent-tokens`](https://docs.applivery.com/en/api/windows/devices/get-agent-tokens/)
[`GET /mdm/windows/enterprise/devices/:winDeviceId/applications`](https://docs.applivery.com/en/api/windows/devices/applications/get/)
[`GET /mdm/windows/enterprise/devices/:winDeviceId/applications/history`](https://docs.applivery.com/en/api/windows/devices/applications/get-history/)
[`GET /mdm/windows/enterprise/devices/:winDeviceId/scheduler-scripts`](https://docs.applivery.com/en/api/windows/devices/get-scheduler-scripts/) | ✓ | ✓ | ✓ | ✓ | | `mdm.windows.device.getBitlockerRecoveryKey` | `GET /mdm/windows/enterprise/devices/:winDeviceId/bitlocker-recovery-key` | ✓ | ✓ | – | – | | `mdm.windows.device.info` | [`POST /mdm/windows/enterprise/devices/:winDeviceId/info`](https://docs.applivery.com/en/api/windows/devices/post-info/) | ✓ | ✓ | ✓ | ✓ | | `mdm.windows.device.list` | [`GET /mdm/windows/enterprise/devices`](https://docs.applivery.com/en/api/windows/devices/get-devices/) | ✓ | ✓ | ✓ | ✓ | | `mdm.windows.device.move` | [`PUT /mdm/windows/enterprise/devices/:winDeviceId/move`](https://docs.applivery.com/en/api/windows/devices/put-move/) | ✓ | ✓ | – | – | | `mdm.windows.device.remove` | [`DELETE /mdm/windows/enterprise/devices/:winDeviceId`](https://docs.applivery.com/en/api/windows/devices/delete-device/) | ✓ | ✓ | – | – | | `mdm.windows.device.update` | [`PUT /mdm/windows/enterprise/devices/:winDeviceId`](https://docs.applivery.com/en/api/windows/devices/put-device/) | ✓ | ✓ | ✓ | – | | `mdm.windows.deviceNotification.action` | `POST /mdm/windows/enterprise/devices/:winDeviceId/notifications` | ✓ | ✓ | – | – | | `mdm.windows.deviceScriptLog.get` | [`GET /mdm/windows/enterprise/devices/:winDeviceId/script-logs/:winDeviceScriptLogId`](https://docs.applivery.com/en/api/windows/devices/script-logs/get-script-log/) | ✓ | ✓ | ✓ | ✓ | | `mdm.windows.deviceScriptLog.invalidate` | [`POST /mdm/windows/enterprise/devices/:winDeviceId/script-logs/:winDeviceScriptLogId/invalidate`](https://docs.applivery.com/en/api/windows/devices/script-logs/post-invalidate/)
[`POST /mdm/windows/enterprise/devices/:winDeviceId/script-logs/invalidate-once`](https://docs.applivery.com/en/api/windows/devices/script-logs/post-invalidate-once/) | ✓ | ✓ | ✓ | ✓ | | `mdm.windows.deviceScriptLog.list` | [`GET /mdm/windows/enterprise/devices/:winDeviceId/script-logs`](https://docs.applivery.com/en/api/windows/devices/script-logs/get-script-logs/)
[`GET /mdm/windows/enterprise/devices/:winDeviceId/script-logs/summary`](https://docs.applivery.com/en/api/windows/devices/script-logs/get-summary/) | ✓ | ✓ | ✓ | ✓ | | `mdm.windows.directProvisioning.create` | [`POST /mdm/windows/enterprise/enrollment-templates/:winEnrollmentTemplateId/direct-provisionings`](https://docs.applivery.com/en/api/windows/direct-provisionings/post-direct-provisioning/) | ✓ | ✓ | ✓ | – | | `mdm.windows.directProvisioning.get` | [`GET /mdm/windows/enterprise/enrollment-templates/:winEnrollmentTemplateId/direct-provisionings/:winDirectProvisioningId`](https://docs.applivery.com/en/api/windows/direct-provisionings/get-direct-provisioning/) | ✓ | ✓ | ✓ | ✓ | | `mdm.windows.directProvisioning.list` | [`GET /mdm/windows/enterprise/enrollment-templates/:winEnrollmentTemplateId/direct-provisionings`](https://docs.applivery.com/en/api/windows/direct-provisionings/get-direct-provisionings/) | ✓ | ✓ | ✓ | ✓ | | `mdm.windows.directProvisioning.remove` | [`DELETE /mdm/windows/enterprise/enrollment-templates/:winEnrollmentTemplateId/direct-provisionings/:winDirectProvisioningId`](https://docs.applivery.com/en/api/windows/direct-provisionings/delete-direct-provisioning/) | ✓ | ✓ | – | – | | `mdm.windows.directProvisioning.update` | [`PUT /mdm/windows/enterprise/enrollment-templates/:winEnrollmentTemplateId/direct-provisionings/:winDirectProvisioningId`](https://docs.applivery.com/en/api/windows/direct-provisionings/put-direct-provisioning/) | ✓ | ✓ | ✓ | – | | `mdm.windows.enrollmentTemplate.create` | [`POST /mdm/windows/enterprise/enrollment-templates`](https://docs.applivery.com/en/api/windows/enrollment-templates/post-enrollment-template/) | ✓ | ✓ | ✓ | – | | `mdm.windows.enrollmentTemplate.get` | [`GET /mdm/windows/enterprise/enrollment-templates/:winEnrollmentTemplateId`](https://docs.applivery.com/en/api/windows/enrollment-templates/get-enrollment-template/) | ✓ | ✓ | ✓ | ✓ | | `mdm.windows.enrollmentTemplate.list` | [`GET /mdm/windows/enterprise/enrollment-templates`](https://docs.applivery.com/en/api/windows/enrollment-templates/get-enrollment-templates/) | ✓ | ✓ | ✓ | ✓ | | `mdm.windows.enrollmentTemplate.remove` | [`DELETE /mdm/windows/enterprise/enrollment-templates/:winEnrollmentTemplateId`](https://docs.applivery.com/en/api/windows/enrollment-templates/delete-enrollment-template/) | ✓ | ✓ | – | – | | `mdm.windows.enrollmentTemplate.update` | [`PUT /mdm/windows/enterprise/enrollment-templates/:winEnrollmentTemplateId`](https://docs.applivery.com/en/api/windows/enrollment-templates/put-enrollment-template/) | ✓ | ✓ | ✓ | – | | `mdm.windows.enrollmentToken.create` | [`POST /mdm/windows/enterprise/enrollment-tokens`](https://docs.applivery.com/en/api/windows/enrollment-tokens/post-enrollment-token/)
[`POST /mdm/windows/enterprise/enrollment-tokens/bulk`](https://docs.applivery.com/en/api/windows/enrollment-tokens/post-bulk/) | ✓ | ✓ | – | – | | `mdm.windows.enrollmentToken.get` | [`GET /mdm/windows/enterprise/enrollment-tokens/:winEnrollmentTokenId`](https://docs.applivery.com/en/api/windows/enrollment-tokens/get-enrollment-token/) | ✓ | ✓ | ✓ | ✓ | | `mdm.windows.enrollmentToken.list` | [`GET /mdm/windows/enterprise/enrollment-tokens`](https://docs.applivery.com/en/api/windows/enrollment-tokens/get-enrollment-tokens/) | ✓ | ✓ | ✓ | ✓ | | `mdm.windows.enrollmentToken.remove` | [`DELETE /mdm/windows/enterprise/enrollment-tokens/:winEnrollmentTokenId`](https://docs.applivery.com/en/api/windows/enrollment-tokens/delete-enrollment-token/) | ✓ | ✓ | – | – | | `mdm.windows.enrollmentToken.update` | [`PUT /mdm/windows/enterprise/enrollment-tokens/:winEnrollmentTokenId`](https://docs.applivery.com/en/api/windows/enrollment-tokens/put-enrollment-token/) | ✓ | ✓ | ✓ | – | | `mdm.windows.enterprise.create` | [`POST /mdm/windows/enterprise`](https://docs.applivery.com/en/api/windows/enterprise/post-enterprise/) | ✓ | ✓ | – | – | | `mdm.windows.enterprise.get` | [`GET /mdm/windows/enterprise`](https://docs.applivery.com/en/api/windows/enterprise/get-enterprise/) | ✓ | ✓ | ✓ | ✓ | | `mdm.windows.enterprise.update` | [`PUT /mdm/windows/enterprise`](https://docs.applivery.com/en/api/windows/enterprise/put-enterprise/) | ✓ | ✓ | – | – | | `mdm.windows.policy.composition` | [`POST /mdm/windows/enterprise/policies/composition`](https://docs.applivery.com/en/api/windows/policies/post-composition/) | ✓ | ✓ | ✓ | ✓ | | `mdm.windows.policy.create` | [`POST /mdm/windows/enterprise/policies`](https://docs.applivery.com/en/api/windows/policies/post-policy/) | ✓ | ✓ | ✓ | – | | `mdm.windows.policy.default` | [`GET /mdm/windows/enterprise/policies/default`](https://docs.applivery.com/en/api/windows/policies/get-default/) | ✓ | ✓ | ✓ | ✓ | | `mdm.windows.policy.get` | [`GET /mdm/windows/enterprise/policies/:winPolicyId`](https://docs.applivery.com/en/api/windows/policies/get-policy/)
[`GET /mdm/windows/enterprise/policies/:winPolicyId/assignations`](https://docs.applivery.com/en/api/windows/policies/get-assignations/) | ✓ | ✓ | ✓ | ✓ | | `mdm.windows.policy.list` | [`GET /mdm/windows/enterprise/policies`](https://docs.applivery.com/en/api/windows/policies/get-policies/) | ✓ | ✓ | ✓ | ✓ | | `mdm.windows.policy.remove` | [`DELETE /mdm/windows/enterprise/policies/:winPolicyId`](https://docs.applivery.com/en/api/windows/policies/delete-policy/) | ✓ | ✓ | – | – | | `mdm.windows.policy.update` | [`PUT /mdm/windows/enterprise/policies/:winPolicyId`](https://docs.applivery.com/en/api/windows/policies/put-policy/) | ✓ | ✓ | ✓ | – | **Aplicaciones (mdm.application) · 2 acciones, 0 endpoints** | Permiso | Endpoints | O | A | E | V | | --- | --- | :-: | :-: | :-: | :-: | | `mdm.application.management.get` | — | ✓ | ✓ | ✓ | ✓ | | `mdm.application.management.list` | — | ✓ | ✓ | ✓ | ✓ | **Builds (mdm.build) · 2 acciones, 0 endpoints** | Permiso | Endpoints | O | A | E | V | | --- | --- | :-: | :-: | :-: | :-: | | `mdm.build.management.get` | — | ✓ | ✓ | ✓ | ✓ | | `mdm.build.management.list` | — | ✓ | ✓ | ✓ | ✓ | **Integraciones (mdm.integration) · 3 acciones, 3 endpoints** | Permiso | Endpoints | O | A | E | V | | --- | --- | :-: | :-: | :-: | :-: | | `mdm.integration.harmonyMobile.get` | [`GET /integrations/harmony-mobile`](https://docs.applivery.com/en/api/platform/organization-integrations-harmony-mobile/get-harmony-mobile/) | ✓ | ✓ | ✓ | – | | `mdm.integration.harmonyMobile.reset` | [`DELETE /integrations/harmony-mobile`](https://docs.applivery.com/en/api/platform/organization-integrations-harmony-mobile/delete-harmony-mobile/) | ✓ | ✓ | – | – | | `mdm.integration.harmonyMobile.update` | [`PUT /integrations/harmony-mobile`](https://docs.applivery.com/en/api/platform/organization-integrations-harmony-mobile/put-harmony-mobile/) | ✓ | ✓ | – | – | **Inventario (inventory.item) · 5 acciones, 9 endpoints** | Permiso | Endpoints | O | A | E | V | | --- | --- | :-: | :-: | :-: | :-: | | `inventory.item.management.create` | [`POST /inventory-items`](https://docs.applivery.com/en/api/platform/inventory-item/post-inventory-item/) | ✓ | ✓ | ✓ | ✓ | | `inventory.item.management.get` | [`GET /inventory-items/:inventoryItemId`](https://docs.applivery.com/en/api/platform/inventory-item/get-inventory-item/) | ✓ | ✓ | ✓ | ✓ | | `inventory.item.management.list` | [`GET /inventory-items`](https://docs.applivery.com/en/api/platform/inventory-item/get-inventory-items/)
[`GET /inventory-items/csv`](https://docs.applivery.com/en/api/platform/inventory-item/csv/get/)
[`GET /inventory-items/csv/sample`](https://docs.applivery.com/en/api/platform/inventory-item/csv/get-sample/) | ✓ | ✓ | ✓ | ✓ | | `inventory.item.management.remove` | [`DELETE /inventory-items/:inventoryItemId`](https://docs.applivery.com/en/api/platform/inventory-item/delete-inventory-item/) | ✓ | ✓ | – | – | | `inventory.item.management.update` | [`PUT /inventory-items/:inventoryItemId`](https://docs.applivery.com/en/api/platform/inventory-item/put-inventory-item/)
[`POST /inventory-items/:inventoryItemId/notes`](https://docs.applivery.com/en/api/platform/inventory-item/notes/post/)
[`DELETE /inventory-items/:inventoryItemId/notes/:noteId`](https://docs.applivery.com/en/api/platform/inventory-item/notes/delete-by-id/) | ✓ | ✓ | ✓ | ✓ | **Distribución de apps** **Aplicaciones (mad.application) · 26 acciones, 27 endpoints** | Permiso | Endpoints | O | A | E | V | App A | App E | App V | | --- | --- | :-: | :-: | :-: | :-: | :-: | :-: | :-: | | `mad.application.configuration.create` | — | ✓ | ✓ | – | – | ✓ | – | – | | `mad.application.configuration.deleteFile` | [`DELETE /apps/:applicationId/configuration/:applicationConfigurationType/file/:applicationConfigurationFile`](https://docs.applivery.com/en/api/app-distribution/application-configurations/file/delete-by-id/) | ✓ | ✓ | – | – | ✓ | – | – | | `mad.application.configuration.get` | [`GET /apps/:applicationId/configuration/:applicationConfigurationType`](https://docs.applivery.com/en/api/app-distribution/application-configurations/get-configuration/) | ✓ | ✓ | – | – | ✓ | – | – | | `mad.application.configuration.getStatus` | [`GET /apps/:applicationId/configuration/:applicationConfigurationType/status`](https://docs.applivery.com/en/api/app-distribution/application-configurations/get-status/) | ✓ | ✓ | ✓ | – | ✓ | ✓ | – | | `mad.application.configuration.remove` | [`DELETE /apps/:applicationId/configuration/:applicationConfigurationType`](https://docs.applivery.com/en/api/app-distribution/application-configurations/delete-configuration/) | ✓ | ✓ | – | – | ✓ | – | – | | `mad.application.configuration.update` | [`PUT /apps/:applicationId/configuration/:applicationConfigurationType`](https://docs.applivery.com/en/api/app-distribution/application-configurations/put-configuration/) | ✓ | ✓ | – | – | ✓ | – | – | | `mad.application.configuration.uploadFile` | [`POST /apps/:applicationId/configuration/:applicationConfigurationType/file`](https://docs.applivery.com/en/api/app-distribution/application-configurations/file/post/) | ✓ | ✓ | – | – | ✓ | – | – | | `mad.application.management.actions` ¹ | [`GET /apps/:applicationId/actions`](https://docs.applivery.com/en/api/app-distribution/application/get-actions/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `mad.application.management.checkSlug` ¹ | [`GET /apps/check-slug/:slug`](https://docs.applivery.com/en/api/app-distribution/application/get-check-slug-by-id/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `mad.application.management.create` | [`POST /apps`](https://docs.applivery.com/en/api/app-distribution/application/post-app/) | ✓ | ✓ | – | – | – | – | – | | `mad.application.management.get` | [`GET /apps/:applicationId`](https://docs.applivery.com/en/api/app-distribution/application/get-app/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `mad.application.management.list` | [`GET /apps`](https://docs.applivery.com/en/api/app-distribution/application/get-apps/)
[`GET /apps/downloads/csv`](https://docs.applivery.com/en/api/app-distribution/application/get-downloads-csv/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `mad.application.management.listGroups` | [`GET /apps/:applicationId/groups`](https://docs.applivery.com/en/api/app-distribution/application/get-groups/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `mad.application.management.listTypes` | [`GET /apps/:applicationId/list/:applicationType`](https://docs.applivery.com/en/api/app-distribution/application/get-list-by-id/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `mad.application.management.remove` | [`DELETE /apps/:applicationId`](https://docs.applivery.com/en/api/app-distribution/application/delete-app/) | ✓ | ✓ | – | – | ✓ | – | – | | `mad.application.management.update` | [`PUT /apps/:applicationId`](https://docs.applivery.com/en/api/app-distribution/application/put-app/)
[`PUT /apps/:applicationId/picture`](https://docs.applivery.com/en/api/app-distribution/application/put-picture/) | ✓ | ✓ | – | – | ✓ | – | – | | `mad.application.notification.create` | [`POST /apps/:applicationId/notifications`](https://docs.applivery.com/en/api/app-distribution/application-notifications/post-notification/) | ✓ | ✓ | – | – | ✓ | – | – | | `mad.application.notification.get` | [`GET /apps/:applicationId/notifications/:applicationNotificationId`](https://docs.applivery.com/en/api/app-distribution/application-notifications/get-notification/) | ✓ | ✓ | ✓ | – | ✓ | ✓ | – | | `mad.application.notification.list` | [`GET /apps/:applicationId/notifications`](https://docs.applivery.com/en/api/app-distribution/application-notifications/get-notifications/) | ✓ | ✓ | ✓ | – | ✓ | ✓ | – | | `mad.application.notification.remove` | [`DELETE /apps/:applicationId/notifications/:applicationNotificationId`](https://docs.applivery.com/en/api/app-distribution/application-notifications/delete-notification/) | ✓ | ✓ | – | – | ✓ | – | – | | `mad.application.notification.update` | [`PUT /apps/:applicationId/notifications/:applicationNotificationId`](https://docs.applivery.com/en/api/app-distribution/application-notifications/put-notification/) | ✓ | ✓ | – | – | ✓ | – | – | | `mad.application.token.create` | [`POST /apps/:applicationId/tokens`](https://docs.applivery.com/en/api/app-distribution/application-integration-tokens/post-token/) | ✓ | ✓ | – | – | ✓ | – | – | | `mad.application.token.get` | [`GET /apps/:applicationId/tokens/:tokenId`](https://docs.applivery.com/en/api/app-distribution/application-integration-tokens/get-token/) | ✓ | ✓ | ✓ | – | ✓ | ✓ | – | | `mad.application.token.list` | [`GET /apps/:applicationId/tokens`](https://docs.applivery.com/en/api/app-distribution/application-integration-tokens/get-tokens/) | ✓ | ✓ | ✓ | – | ✓ | ✓ | – | | `mad.application.token.remove` | [`DELETE /apps/:applicationId/tokens/:tokenId`](https://docs.applivery.com/en/api/app-distribution/application-integration-tokens/delete-token/) | ✓ | ✓ | – | – | ✓ | – | – | | `mad.application.token.update` | [`PUT /apps/:applicationId/tokens/:tokenId`](https://docs.applivery.com/en/api/app-distribution/application-integration-tokens/put-token/) | ✓ | ✓ | – | – | ✓ | – | – | ¹ También permitido para: `mad.application.management.actions`: Viewer de Gestión de dispositivos; `mad.application.management.checkSlug`: No Role. **Builds (mad.build) · 12 acciones, 15 endpoints** | Permiso | Endpoints | O | A | E | V | App A | App E | App V | | --- | --- | :-: | :-: | :-: | :-: | :-: | :-: | :-: | | `mad.build.management.addFile` | [`POST /apps/:applicationId/builds/:buildId/edge/file`](https://docs.applivery.com/en/api/app-distribution/builds/apps-edge-file-create/) | ✓ | ✓ | – | – | ✓ | ✓ | – | | `mad.build.management.create` | [`POST /apps/:applicationId/builds`](https://docs.applivery.com/en/api/app-distribution/build/post-organizations-organizationid-apps-applicationid-builds/)
[`POST /apps/:applicationId/builds/edge/build`](https://docs.applivery.com/en/api/app-distribution/builds/apps-edge-build-create/)
[`GET /apps/:applicationId/builds/edge/prepare`](https://docs.applivery.com/en/api/app-distribution/builds/apps-edge-prepare/) | ✓ | ✓ | ✓ | – | ✓ | ✓ | – | | `mad.build.management.get` | [`GET /apps/:applicationId/builds/:buildId`](https://docs.applivery.com/en/api/app-distribution/build/get-organizations-organizationid-apps-applicationid-builds-buildid/)
[`GET /apps/:applicationId/builds/:buildId/emm-json`](https://docs.applivery.com/en/api/app-distribution/builds/apps-emm-json/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `mad.build.management.getDownloadToken` | [`GET /apps/:applicationId/builds/:buildId/downloadToken`](https://docs.applivery.com/en/api/app-distribution/builds/apps-download-token/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `mad.build.management.list` | [`GET /apps/:applicationId/builds`](https://docs.applivery.com/en/api/app-distribution/builds/apps-list/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `mad.build.management.listPackageNames` | [`GET /apps/:applicationId/builds/list/packageName`](https://docs.applivery.com/en/api/app-distribution/builds/apps-package-names/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `mad.build.management.listVersionCodes` | [`GET /apps/:applicationId/builds/list/versionCode`](https://docs.applivery.com/en/api/app-distribution/builds/apps-version-codes/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `mad.build.management.listVersionNames` | [`GET /apps/:applicationId/builds/list/versionName`](https://docs.applivery.com/en/api/app-distribution/builds/apps-version-names/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `mad.build.management.remove` | [`DELETE /apps/:applicationId/builds/:buildId`](https://docs.applivery.com/en/api/app-distribution/builds/apps-delete/) | ✓ | ✓ | – | – | ✓ | – | – | | `mad.build.management.removeFile` | [`DELETE /apps/:applicationId/builds/:buildId/files/:fileId`](https://docs.applivery.com/en/api/app-distribution/builds/apps-files-delete/) | ✓ | ✓ | – | – | ✓ | – | – | | `mad.build.management.update` | [`PUT /apps/:applicationId/builds/:buildId`](https://docs.applivery.com/en/api/app-distribution/builds/apps-update/) | ✓ | ✓ | ✓ | – | ✓ | ✓ | – | | `mad.build.management.updateFile` | [`PUT /apps/:applicationId/builds/:buildId/files/:fileId`](https://docs.applivery.com/en/api/app-distribution/builds/apps-files-update/) | ✓ | ✓ | ✓ | – | ✓ | ✓ | – | **Descargas (mad.download) · 2 acciones, 8 endpoints** | Permiso | Endpoints | O | A | E | V | App A | App E | App V | | --- | --- | :-: | :-: | :-: | :-: | :-: | :-: | :-: | | `mad.download.management.get` | [`GET /apps/:applicationId/builds/:buildId/downloads/:downloadId`](https://docs.applivery.com/en/api/app-distribution/build-downloads-info/get-download/)
[`GET /organizations/organizationId/apps/applicationId/downloads/:downloadId`](https://docs.applivery.com/en/api/app-distribution/application-downloads-info/get-download/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `mad.download.management.list` | [`GET /apps/:applicationId/builds/:buildId/downloads`](https://docs.applivery.com/en/api/app-distribution/build-downloads-info/get-downloads/)
[`GET /apps/:applicationId/builds/:buildId/downloads/by-user`](https://docs.applivery.com/en/api/app-distribution/build-downloads-info/get-by-user/)
[`GET /apps/:applicationId/builds/:buildId/downloads/csv`](https://docs.applivery.com/en/api/app-distribution/build-downloads-info/get-csv/)
[`GET /organizations/organizationId/apps/applicationId/downloads`](https://docs.applivery.com/en/api/app-distribution/application-downloads-info/get-downloads/)
[`GET /organizations/organizationId/apps/applicationId/downloads/by-user`](https://docs.applivery.com/en/api/app-distribution/application-downloads-info/get-by-user/)
[`GET /organizations/organizationId/apps/applicationId/downloads/csv`](https://docs.applivery.com/en/api/app-distribution/application-downloads-info/get-csv/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | **Feedback (mad.feedback) · 5 acciones, 7 endpoints** | Permiso | Endpoints | O | A | E | V | App A | App E | App V | | --- | --- | :-: | :-: | :-: | :-: | :-: | :-: | :-: | | `mad.feedback.management.create` | [`POST /apps/:applicationId/feedbacks`](https://docs.applivery.com/en/api/app-distribution/application-feedbacks/post-feedback/) | ✓ | ✓ | ✓ | – | ✓ | ✓ | – | | `mad.feedback.management.get` | [`GET /apps/:applicationId/feedbacks/:feedbackId`](https://docs.applivery.com/en/api/app-distribution/application-feedbacks/get-feedback/)
[`GET /apps/:applicationId/feedbacks/:feedbackId/image`](https://docs.applivery.com/en/api/app-distribution/application-feedbacks/get-image/)
[`GET /apps/:applicationId/feedbacks/:feedbackId/video`](https://docs.applivery.com/en/api/app-distribution/application-feedbacks/get-video/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `mad.feedback.management.list` | [`GET /apps/:applicationId/feedbacks`](https://docs.applivery.com/en/api/app-distribution/application-feedbacks/get-feedbacks/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `mad.feedback.management.remove` | [`DELETE /apps/:applicationId/feedbacks/:feedbackId`](https://docs.applivery.com/en/api/app-distribution/application-feedbacks/delete-feedback/) | ✓ | ✓ | ✓ | – | ✓ | ✓ | – | | `mad.feedback.management.update` | [`PUT /apps/:applicationId/feedbacks/:feedbackId`](https://docs.applivery.com/en/api/app-distribution/application-feedbacks/put-feedback/) | ✓ | ✓ | ✓ | – | ✓ | ✓ | – | **Enterprise Stores (mad.store) · 17 acciones, 16 endpoints** | Permiso | Endpoints | O | A | E | V | App A | App E | App V | | --- | --- | :-: | :-: | :-: | :-: | :-: | :-: | :-: | | `mad.store.management.create` | — | ✓ | ✓ | – | – | – | – | – | | `mad.store.management.get` | [`GET /stores/:storeId`](https://docs.applivery.com/en/api/platform/organization-store/get-store/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `mad.store.management.list` | [`GET /stores`](https://docs.applivery.com/en/api/platform/organization-store/get-stores/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `mad.store.management.remove` | [`DELETE /stores/:storeId`](https://docs.applivery.com/en/api/platform/organization-store/delete-store/) | ✓ | ✓ | – | – | – | – | – | | `mad.store.management.update` | [`PUT /stores/:storeId`](https://docs.applivery.com/en/api/platform/organization-store/put-store/) | ✓ | ✓ | – | – | – | – | – | | `mad.store.otpUsers.create` | [`POST /organizations/:organizationSlug/stores/:storeId/otp-users`](https://docs.applivery.com/en/api/platform/otp-users/post-otp-user/) | ✓ | ✓ | – | – | ✓ | – | – | | `mad.store.otpUsers.get` | [`GET /organizations/:organizationSlug/stores/:storeId/otp-users/:otpUserId`](https://docs.applivery.com/en/api/platform/otp-users/get-otp-user/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `mad.store.otpUsers.list` | [`GET /organizations/:organizationSlug/stores/:storeId/otp-users`](https://docs.applivery.com/en/api/platform/otp-users/get-otp-users/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `mad.store.otpUsers.remove` | [`DELETE /organizations/:organizationSlug/stores/:storeId/otp-users/:otpUserId`](https://docs.applivery.com/en/api/platform/otp-users/delete-otp-user/) | ✓ | ✓ | – | – | ✓ | – | – | | `mad.store.otpUsers.update` | [`PUT /organizations/:organizationSlug/stores/:storeId/otp-users/:otpUserId`](https://docs.applivery.com/en/api/platform/otp-users/put-otp-user/) | ✓ | ✓ | – | – | ✓ | – | – | | `mad.store.publishedApplication.create` | [`POST /stores/:storeId/pubApps`](https://docs.applivery.com/en/api/app-distribution/store-published-applications/post-pub-app/) | ✓ | ✓ | – | – | ✓ | – | – | | `mad.store.publishedApplication.get` | [`GET /stores/:storeId/pubApps/:publishedApplicationId`](https://docs.applivery.com/en/api/app-distribution/store-published-applications/get-pub-app/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `mad.store.publishedApplication.list` | [`GET /stores/:storeId/pubApps`](https://docs.applivery.com/en/api/app-distribution/store-published-applications/get-pub-apps/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `mad.store.publishedApplication.notify` | [`POST /stores/:storeId/pubApps/:publishedApplicationId/notify`](https://docs.applivery.com/en/api/app-distribution/store-published-applications/post-notify/) | ✓ | ✓ | – | – | ✓ | – | – | | `mad.store.publishedApplication.remove` | [`DELETE /stores/:storeId/pubApps/:publishedApplicationId`](https://docs.applivery.com/en/api/app-distribution/store-published-applications/delete-pub-app/) | ✓ | ✓ | – | – | ✓ | – | – | | `mad.store.publishedApplication.target` | [`GET /stores/:storeId/pubApps/:publishedApplicationId/target`](https://docs.applivery.com/en/api/app-distribution/store-published-applications/get-target/) | ✓ | ✓ | ✓ | ✓ | ✓ | – | – | | `mad.store.publishedApplication.update` | [`PUT /stores/:storeId/pubApps/:publishedApplicationId`](https://docs.applivery.com/en/api/app-distribution/store-published-applications/put-pub-app/) | ✓ | ✓ | – | – | ✓ | – | – | **User Audiences (mad.userAudience) · 14 acciones, 14 endpoints** | Permiso | Endpoints | O | A | E | V | App A | App E | App V | | --- | --- | :-: | :-: | :-: | :-: | :-: | :-: | :-: | | `mad.userAudience.application.create` | [`POST /apps/:applicationId/user-audiences`](https://docs.applivery.com/en/api/platform/user-audience/apps/post-user-audience/) | ✓ | ✓ | – | – | ✓ | ✓ | – | | `mad.userAudience.application.get` | [`GET /apps/:applicationId/user-audiences/:userAudienceId`](https://docs.applivery.com/en/api/platform/user-audience/apps/get-user-audience/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `mad.userAudience.application.list` | [`GET /apps/:applicationId/user-audiences`](https://docs.applivery.com/en/api/platform/user-audience/apps/get-user-audiences/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `mad.userAudience.application.preview` | [`POST /apps/:applicationId/user-audiences/preview`](https://docs.applivery.com/en/api/platform/user-audience/apps/post-preview/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `mad.userAudience.application.remove` | [`DELETE /apps/:applicationId/user-audiences/:userAudienceId`](https://docs.applivery.com/en/api/platform/user-audience/apps/delete-user-audience/) | ✓ | ✓ | – | – | ✓ | ✓ | – | | `mad.userAudience.application.target` | [`GET /apps/:applicationId/user-audiences/:userAudienceId/target`](https://docs.applivery.com/en/api/platform/user-audience/apps/get-target/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `mad.userAudience.application.update` | [`PUT /apps/:applicationId/user-audiences/:userAudienceId`](https://docs.applivery.com/en/api/platform/user-audience/apps/put-user-audience/) | ✓ | ✓ | – | – | ✓ | ✓ | – | | `mad.userAudience.organization.create` | [`POST /user-audiences`](https://docs.applivery.com/en/api/platform/user-audience/post-user-audience/) | ✓ | ✓ | – | – | – | – | – | | `mad.userAudience.organization.get` | [`GET /user-audiences/:userAudienceId`](https://docs.applivery.com/en/api/platform/user-audience/get-user-audience/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `mad.userAudience.organization.list` | [`GET /user-audiences`](https://docs.applivery.com/en/api/platform/user-audience/get-user-audiences/) | ✓ | ✓ | ✓ | ✓ | ✓ | – | – | | `mad.userAudience.organization.preview` | [`POST /user-audiences/preview`](https://docs.applivery.com/en/api/platform/user-audience/post-preview/) | ✓ | ✓ | ✓ | ✓ | ✓ | – | – | | `mad.userAudience.organization.remove` | [`DELETE /user-audiences/:userAudienceId`](https://docs.applivery.com/en/api/platform/user-audience/delete-user-audience/) | ✓ | ✓ | – | – | – | – | – | | `mad.userAudience.organization.target` | [`GET /user-audiences/:userAudienceId/target`](https://docs.applivery.com/en/api/platform/user-audience/get-target/) | ✓ | ✓ | – | – | ✓ | – | – | | `mad.userAudience.organization.update` | [`PUT /user-audiences/:userAudienceId`](https://docs.applivery.com/en/api/platform/user-audience/put-user-audience/) | ✓ | ✓ | – | – | – | – | – | **Helheim (mad.helheim) · 6 acciones, 0 endpoints** | Permiso | Endpoints | O | A | E | V | App A | App E | App V | | --- | --- | :-: | :-: | :-: | :-: | :-: | :-: | :-: | | `mad.helheim.management.create` | — | ✓ | ✓ | – | – | ✓ | – | – | | `mad.helheim.management.get` | — | ✓ | ✓ | ✓ | – | ✓ | ✓ | – | | `mad.helheim.management.list` | — | ✓ | ✓ | ✓ | – | ✓ | ✓ | – | | `mad.helheim.management.process` | — | ✓ | ✓ | – | – | ✓ | – | – | | `mad.helheim.management.remove` | — | ✓ | ✓ | – | – | ✓ | – | – | | `mad.helheim.management.update` | — | ✓ | ✓ | – | – | ✓ | – | – | **Personas (people.mad) · 19 acciones, 21 endpoints** | Permiso | Endpoints | O | A | E | V | App A | App E | App V | | --- | --- | :-: | :-: | :-: | :-: | :-: | :-: | :-: | | `people.mad.applicationCollaborator.create` | [`POST /apps/:applicationId/collaborators`](https://docs.applivery.com/en/api/app-distribution/application-collaborators/post-collaborator/) | ✓ | ✓ | – | – | ✓ | – | – | | `people.mad.applicationCollaborator.get` | [`GET /apps/:applicationId/collaborators/:applicationCollaboratorId`](https://docs.applivery.com/en/api/app-distribution/application-collaborators/get-collaborator/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `people.mad.applicationCollaborator.invitations` | [`GET /apps/:applicationId/collaborators/invitations`](https://docs.applivery.com/en/api/app-distribution/application-collaborators/invitations/get/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `people.mad.applicationCollaborator.list` | [`GET /apps/:applicationId/collaborators`](https://docs.applivery.com/en/api/app-distribution/application-collaborators/get-collaborators/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `people.mad.applicationCollaborator.remove` | [`DELETE /apps/:applicationId/collaborators/:applicationCollaboratorId`](https://docs.applivery.com/en/api/app-distribution/application-collaborators/delete-collaborator/) | ✓ | ✓ | – | – | ✓ | – | – | | `people.mad.applicationCollaborator.removeInvitations` | [`DELETE /apps/:applicationId/collaborators/invitations/:invitationId`](https://docs.applivery.com/en/api/app-distribution/application-collaborators/invitations/delete-by-id/) | ✓ | ✓ | – | – | ✓ | – | – | | `people.mad.applicationCollaborator.update` | [`PUT /apps/:applicationId/collaborators/:applicationCollaboratorId`](https://docs.applivery.com/en/api/app-distribution/application-collaborators/put-collaborator/) | ✓ | ✓ | – | – | ✓ | – | – | | `people.mad.applicationEmployee.create` | [`POST /apps/:applicationId/employees`](https://docs.applivery.com/en/api/app-distribution/application-employees/post-employee/) | ✓ | ✓ | – | – | ✓ | – | – | | `people.mad.applicationEmployee.get` | [`GET /apps/:applicationId/employees/:applicationEmployeeId`](https://docs.applivery.com/en/api/app-distribution/application-employees/get-employee/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `people.mad.applicationEmployee.list` | [`GET /apps/:applicationId/employees`](https://docs.applivery.com/en/api/app-distribution/application-employees/get-employees/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `people.mad.applicationEmployee.remove` | [`DELETE /apps/:applicationId/employees/:applicationEmployeeId`](https://docs.applivery.com/en/api/app-distribution/application-employees/delete-employee/) | ✓ | ✓ | – | – | ✓ | – | – | | `people.mad.applicationEmployee.update` | [`PUT /apps/:applicationId/employees/:applicationEmployeeId`](https://docs.applivery.com/en/api/app-distribution/application-employees/put-employee/) | ✓ | ✓ | – | – | ✓ | – | – | | `people.mad.organizationEmployee.create` | [`POST /employees`](https://docs.applivery.com/en/api/app-distribution/organization-employees/post-employee/) | ✓ | ✓ | – | – | – | – | – | | `people.mad.organizationEmployee.get` | [`GET /employees/:organizationEmployeeId`](https://docs.applivery.com/en/api/app-distribution/organization-employees/get-employee/) | ✓ | ✓ | ✓ | ✓ | – | – | – | | `people.mad.organizationEmployee.list` | [`GET /employees`](https://docs.applivery.com/en/api/app-distribution/organization-employees/get-employees/)
[`GET /employees/apps`](https://docs.applivery.com/en/api/app-distribution/organization-employees/get-apps/) | ✓ | ✓ | ✓ | ✓ | – | – | – | | `people.mad.organizationEmployee.listAll` | [`GET /employees/all`](https://docs.applivery.com/en/api/app-distribution/organization-employees/get-all/)
[`GET /employees/all-csv`](https://docs.applivery.com/en/api/app-distribution/organization-employees/get-all-csv/) | ✓ | ✓ | ✓ | ✓ | – | – | – | | `people.mad.organizationEmployee.listGroups` | [`GET /employees/groups`](https://docs.applivery.com/en/api/app-distribution/organization-employees/get-groups/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `people.mad.organizationEmployee.remove` | [`DELETE /employees/:organizationEmployeeId`](https://docs.applivery.com/en/api/app-distribution/organization-employees/delete-employee/) | ✓ | ✓ | – | – | – | – | – | | `people.mad.organizationEmployee.update` | [`PUT /employees/:organizationEmployeeId`](https://docs.applivery.com/en/api/app-distribution/organization-employees/put-employee/) | ✓ | ✓ | ✓ | – | – | – | – | **Workspace** **Organización (base.organization) · 66 acciones, 63 endpoints** **Roles de Gestión de dispositivos** | Permiso | Endpoints | O | A | E | V | | --- | --- | :-: | :-: | :-: | :-: | | `base.organization.assistant.action` | [`POST /assistant/:action`](https://docs.applivery.com/en/api/platform/assistant/post-assistant-by-id/) | ✓ | ✓ | ✓ | ✓ | | `base.organization.audit.get` | [`GET /audit/:auditId`](https://docs.applivery.com/en/api/platform/audit/get-audit-by-id/) | ✓ | ✓ | – | – | | `base.organization.audit.list` | [`GET /audit`](https://docs.applivery.com/en/api/platform/audit/get-audit/) | ✓ | ✓ | – | – | | `base.organization.certificateProvider.assignations` | [`GET /certificate-providers/:certificateProviderId/assignations`](https://docs.applivery.com/en/api/platform/certificate-provider/get-assignations/) | ✓ | ✓ | – | – | | `base.organization.certificateProvider.create` | [`POST /certificate-providers`](https://docs.applivery.com/en/api/platform/certificate-provider/post-certificate-provider/) | ✓ | ✓ | – | – | | `base.organization.certificateProvider.get` | [`GET /certificate-providers/:certificateProviderId`](https://docs.applivery.com/en/api/platform/certificate-provider/get-certificate-provider/) | ✓ | ✓ | – | – | | `base.organization.certificateProvider.list` | [`GET /certificate-providers`](https://docs.applivery.com/en/api/platform/certificate-provider/get-certificate-providers/) | ✓ | ✓ | – | – | | `base.organization.certificateProvider.purge` | [`DELETE /certificate-providers/:certificateProviderId/purge`](https://docs.applivery.com/en/api/platform/certificateprovider/delete-organizations-organizationid-certificate-providers-certificateproviderid-purge/) | ✓ | ✓ | – | – | | `base.organization.certificateProvider.remove` | [`DELETE /certificate-providers/:certificateProviderId`](https://docs.applivery.com/en/api/platform/certificate-provider/delete-certificate-provider/) | ✓ | ✓ | – | – | | `base.organization.certificateProvider.update` | [`PUT /certificate-providers/:certificateProviderId`](https://docs.applivery.com/en/api/platform/certificate-provider/put-certificate-provider/) | ✓ | ✓ | – | – | | `base.organization.emails.list` | [`GET /emails/:scope`](https://docs.applivery.com/en/api/platform/organization-emails/get-email/) | ✓ | ✓ | ✓ | – | | `base.organization.loginProvider.create` | [`POST /providers`](https://docs.applivery.com/en/api/platform/organization-providers/post-provider/) | ✓ | ✓ | – | – | | `base.organization.loginProvider.get` | [`GET /providers/:providerId`](https://docs.applivery.com/en/api/platform/organization-providers/get-provider/) | ✓ | ✓ | – | – | | `base.organization.loginProvider.list` | [`GET /providers`](https://docs.applivery.com/en/api/platform/organization-providers/get-providers/) | ✓ | ✓ | – | – | | `base.organization.loginProvider.remove` | [`DELETE /providers/:providerId`](https://docs.applivery.com/en/api/platform/organization-providers/delete-provider/) | ✓ | ✓ | – | – | | `base.organization.loginProvider.update` | [`PUT /providers/:providerId`](https://docs.applivery.com/en/api/platform/organization-providers/put-provider/) | ✓ | ✓ | – | – | | `base.organization.loginProvider.updateSamlUris` | [`PUT /providers/:providerId/saml-uris`](https://docs.applivery.com/en/api/platform/organization-providers/put-saml-uris/) | ✓ | ✓ | – | – | | `base.organization.management.checkSlug` | [`GET /organizations/check-slug/:slug`](https://docs.applivery.com/en/api/platform/organization/get-check-slug-by-id/) | ✓ | ✓ | ✓ | ✓ | | `base.organization.management.create` | [`POST /organizations`](https://docs.applivery.com/en/api/platform/organization/post-organization/) | ✓ | ✓ | ✓ | – | | `base.organization.management.get` | [`GET /`](https://docs.applivery.com/en/api/platform/organization/get-organization/)
[`GET /actions`](https://docs.applivery.com/en/api/platform/organization/get-actions/)
[`GET /workspace`](https://docs.applivery.com/en/api/platform/organization/get-workspace/) | ✓ | ✓ | ✓ | ✓ | | `base.organization.management.getStorageProviders` | [`GET /storage-providers`](https://docs.applivery.com/en/api/platform/organization-storage-providers/get-storage-providers/) | ✓ | ✓ | ✓ | ✓ | | `base.organization.management.list` | [`GET /organizations`](https://docs.applivery.com/en/api/platform/organization/get-organizations/) | ✓ | ✓ | ✓ | ✓ | | `base.organization.management.listGroups` | [`GET /groups`](https://docs.applivery.com/en/api/platform/organization/get-groups/) | ✓ | ✓ | ✓ | ✓ | | `base.organization.management.manageIntegrations` | — | ✓ | ✓ | – | – | | `base.organization.management.sendSupportEmail` | [`GET /support-email/:action`](https://docs.applivery.com/en/api/platform/organization/get-support-email-by-id/) | ✓ | ✓ | ✓ | ✓ | | `base.organization.management.update` | [`PUT /`](https://docs.applivery.com/en/api/platform/organization/put-organization/) | ✓ | ✓ | – | – | | `base.organization.notification.create` | [`POST /notifications`](https://docs.applivery.com/en/api/platform/organization-notifications/post-notification/) | ✓ | ✓ | – | – | | `base.organization.notification.get` | [`GET /notifications/:organizationNotificationId`](https://docs.applivery.com/en/api/platform/organization-notifications/get-notification/) | ✓ | ✓ | ✓ | – | | `base.organization.notification.list` | [`GET /notifications`](https://docs.applivery.com/en/api/platform/organization-notifications/get-notifications/) | ✓ | ✓ | ✓ | – | | `base.organization.notification.remove` | [`DELETE /notifications/:organizationNotificationId`](https://docs.applivery.com/en/api/platform/organization-notifications/delete-notification/) | ✓ | ✓ | – | – | | `base.organization.notification.update` | [`PUT /notifications/:organizationNotificationId`](https://docs.applivery.com/en/api/platform/organization-notifications/put-notification/) | ✓ | ✓ | – | – | | `base.organization.pushNotificationProvider.create` | — | ✓ | ✓ | – | – | | `base.organization.pushNotificationProvider.get` | — | ✓ | ✓ | – | – | | `base.organization.pushNotificationProvider.list` | — | ✓ | ✓ | – | – | | `base.organization.pushNotificationProvider.remove` | — | ✓ | ✓ | – | – | | `base.organization.pushNotificationProvider.update` | — | ✓ | ✓ | – | – | | `base.organization.scim.create` | [`POST /providers/:providerId/scim`](https://docs.applivery.com/en/api/platform/organization-providers-scim/post-scim/) | ✓ | ✓ | – | – | | `base.organization.scim.get` | [`GET /providers/:providerId/scim`](https://docs.applivery.com/en/api/platform/organization-providers-scim/get-scim/) | ✓ | ✓ | ✓ | ✓ | | `base.organization.scim.list` | — | ✓ | ✓ | ✓ | ✓ | | `base.organization.scim.remove` | [`DELETE /providers/:providerId/scim`](https://docs.applivery.com/en/api/platform/organization-providers-scim/delete-scim/) | ✓ | ✓ | – | – | | `base.organization.scim.update` | [`PUT /providers/:providerId/scim`](https://docs.applivery.com/en/api/platform/organization-providers-scim/put-scim/) | ✓ | ✓ | – | – | | `base.organization.segment.actions` | [`GET /segments/:segmentId/actions`](https://docs.applivery.com/en/api/platform/segment/get-actions/) | ✓ | ✓ | ✓ | ✓ | | `base.organization.segment.counts` | [`GET /segments/:segmentId/counts`](https://docs.applivery.com/en/api/platform/segment/get-counts/)
[`GET /segments/:segmentId/counts-by-entity/:entity`](https://docs.applivery.com/en/api/platform/segment/get-counts-by-entity-by-id/) | ✓ | ✓ | ✓ | ✓ | | `base.organization.segment.create` | [`POST /segments`](https://docs.applivery.com/en/api/platform/segment/post-segment/) | ✓ | ✓ | – | – | | `base.organization.segment.get` | [`GET /segments/:segmentId`](https://docs.applivery.com/en/api/platform/segment/get-segment/) | ✓ | ✓ | – | – | | `base.organization.segment.list` | [`GET /segments`](https://docs.applivery.com/en/api/platform/segment/get-segments/) | ✓ | ✓ | – | – | | `base.organization.segment.remove` | [`DELETE /segments/:segmentId`](https://docs.applivery.com/en/api/platform/segment/delete-segment/) | ✓ | ✓ | – | – | | `base.organization.segment.update` | [`PUT /segments/:segmentId`](https://docs.applivery.com/en/api/platform/segment/put-segment/) | ✓ | ✓ | – | – | | `base.organization.segmentPermission.create` | [`POST /segment-permissions`](https://docs.applivery.com/en/api/platform/segment-permission/post-segment-permission/) | ✓ | ✓ | – | – | | `base.organization.segmentPermission.get` | [`GET /segment-permissions/:permissionId`](https://docs.applivery.com/en/api/platform/segment-permission/get-segment-permission/) | ✓ | ✓ | ✓ | ✓ | | `base.organization.segmentPermission.list` | [`GET /segment-permissions`](https://docs.applivery.com/en/api/platform/segment-permission/get-segment-permissions/) | ✓ | ✓ | ✓ | ✓ | | `base.organization.segmentPermission.preview` | [`POST /segment-permissions/preview`](https://docs.applivery.com/en/api/platform/segment-permission/post-preview/) | ✓ | ✓ | – | – | | `base.organization.segmentPermission.remove` | [`DELETE /segment-permissions/:permissionId`](https://docs.applivery.com/en/api/platform/segment-permission/delete-segment-permission/) | ✓ | ✓ | – | – | | `base.organization.segmentPermission.update` | [`PUT /segment-permissions/:permissionId`](https://docs.applivery.com/en/api/platform/segment-permission/put-segment-permission/) | ✓ | ✓ | – | – | | `base.organization.segmentPermission.userList` | [`GET /segment-permissions/users`](https://docs.applivery.com/en/api/platform/segment-permission/get-users/) | ✓ | ✓ | – | – | | `base.organization.segmentRole.create` | [`POST /segment-roles`](https://docs.applivery.com/en/api/platform/segment-role/post-segment-role/) | ✓ | ✓ | – | – | | `base.organization.segmentRole.get` | [`GET /segment-roles/:roleId`](https://docs.applivery.com/en/api/platform/segment-role/get-segment-role/) | ✓ | ✓ | ✓ | ✓ | | `base.organization.segmentRole.list` | [`GET /segment-roles`](https://docs.applivery.com/en/api/platform/segment-role/get-segment-roles/) | ✓ | ✓ | ✓ | ✓ | | `base.organization.segmentRole.remove` | [`DELETE /segment-roles/:roleId`](https://docs.applivery.com/en/api/platform/segment-role/delete-segment-role/) | ✓ | ✓ | – | – | | `base.organization.segmentRole.update` | [`PUT /segment-roles/:roleId`](https://docs.applivery.com/en/api/platform/segment-role/put-segment-role/) | ✓ | ✓ | – | – | | `base.organization.stats.get` | [`GET /stats`](https://docs.applivery.com/en/api/platform/organization-stats/get-stats/)
[`GET /stats/by-day`](https://docs.applivery.com/en/api/platform/organization-stats/get-by-day/) | ✓ | ✓ | ✓ | ✓ | | `base.organization.storageProvider.create` | [`POST /storage-providers`](https://docs.applivery.com/en/api/platform/organization-storage-providers/post-storage-provider/) | ✓ | ✓ | – | – | | `base.organization.storageProvider.delete` | [`DELETE /storage-providers/:storageProviderId`](https://docs.applivery.com/en/api/platform/organization-storage-providers/delete-storage-provider/) | ✓ | ✓ | – | – | | `base.organization.storageProvider.list` | [`GET /storage-providers`](https://docs.applivery.com/en/api/platform/organization-storage-providers/get-storage-providers/) | ✓ | ✓ | – | – | | `base.organization.storageProvider.test` | [`GET /storage-providers/:storageProviderId/test`](https://docs.applivery.com/en/api/platform/organization-storage-providers/get-test/) | ✓ | ✓ | – | – | | `base.organization.storageProvider.update` | [`PUT /storage-providers/:storageProviderId`](https://docs.applivery.com/en/api/platform/organization-storage-providers/put-storage-provider/) | ✓ | ✓ | – | – | **Roles de Distribución de apps** | Permiso | Endpoints | O | A | E | V | App A | App E | App V | | --- | --- | :-: | :-: | :-: | :-: | :-: | :-: | :-: | | `base.organization.assistant.action` | [`POST /assistant/:action`](https://docs.applivery.com/en/api/platform/assistant/post-assistant-by-id/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `base.organization.audit.get` | [`GET /audit/:auditId`](https://docs.applivery.com/en/api/platform/audit/get-audit-by-id/) | ✓ | ✓ | – | – | – | – | – | | `base.organization.audit.list` | [`GET /audit`](https://docs.applivery.com/en/api/platform/audit/get-audit/) | ✓ | ✓ | – | – | – | – | – | | `base.organization.certificateProvider.assignations` | [`GET /certificate-providers/:certificateProviderId/assignations`](https://docs.applivery.com/en/api/platform/certificate-provider/get-assignations/) | ✓ | – | – | – | – | – | – | | `base.organization.certificateProvider.create` | [`POST /certificate-providers`](https://docs.applivery.com/en/api/platform/certificate-provider/post-certificate-provider/) | ✓ | – | – | – | – | – | – | | `base.organization.certificateProvider.get` | [`GET /certificate-providers/:certificateProviderId`](https://docs.applivery.com/en/api/platform/certificate-provider/get-certificate-provider/) | ✓ | – | – | – | – | – | – | | `base.organization.certificateProvider.list` | [`GET /certificate-providers`](https://docs.applivery.com/en/api/platform/certificate-provider/get-certificate-providers/) | ✓ | – | – | – | – | – | – | | `base.organization.certificateProvider.purge` | [`DELETE /certificate-providers/:certificateProviderId/purge`](https://docs.applivery.com/en/api/platform/certificateprovider/delete-organizations-organizationid-certificate-providers-certificateproviderid-purge/) | ✓ | – | – | – | – | – | – | | `base.organization.certificateProvider.remove` | [`DELETE /certificate-providers/:certificateProviderId`](https://docs.applivery.com/en/api/platform/certificate-provider/delete-certificate-provider/) | ✓ | – | – | – | – | – | – | | `base.organization.certificateProvider.update` | [`PUT /certificate-providers/:certificateProviderId`](https://docs.applivery.com/en/api/platform/certificate-provider/put-certificate-provider/) | ✓ | – | – | – | – | – | – | | `base.organization.emails.list` | [`GET /emails/:scope`](https://docs.applivery.com/en/api/platform/organization-emails/get-email/) | ✓ | ✓ | ✓ | – | ✓ | ✓ | – | | `base.organization.loginProvider.create` | [`POST /providers`](https://docs.applivery.com/en/api/platform/organization-providers/post-provider/) | ✓ | ✓ | – | – | – | – | – | | `base.organization.loginProvider.get` | [`GET /providers/:providerId`](https://docs.applivery.com/en/api/platform/organization-providers/get-provider/) | ✓ | ✓ | – | – | – | – | – | | `base.organization.loginProvider.list` | [`GET /providers`](https://docs.applivery.com/en/api/platform/organization-providers/get-providers/) | ✓ | ✓ | – | – | – | – | – | | `base.organization.loginProvider.remove` | [`DELETE /providers/:providerId`](https://docs.applivery.com/en/api/platform/organization-providers/delete-provider/) | ✓ | ✓ | – | – | – | – | – | | `base.organization.loginProvider.update` | [`PUT /providers/:providerId`](https://docs.applivery.com/en/api/platform/organization-providers/put-provider/) | ✓ | ✓ | – | – | – | – | – | | `base.organization.loginProvider.updateSamlUris` | [`PUT /providers/:providerId/saml-uris`](https://docs.applivery.com/en/api/platform/organization-providers/put-saml-uris/) | ✓ | ✓ | – | – | – | – | – | | `base.organization.management.checkSlug` ¹ | [`GET /organizations/check-slug/:slug`](https://docs.applivery.com/en/api/platform/organization/get-check-slug-by-id/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `base.organization.management.create` ¹ | [`POST /organizations`](https://docs.applivery.com/en/api/platform/organization/post-organization/) | ✓ | ✓ | ✓ | – | ✓ | ✓ | – | | `base.organization.management.get` ¹ | [`GET /`](https://docs.applivery.com/en/api/platform/organization/get-organization/)
[`GET /actions`](https://docs.applivery.com/en/api/platform/organization/get-actions/)
[`GET /workspace`](https://docs.applivery.com/en/api/platform/organization/get-workspace/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `base.organization.management.getStorageProviders` ¹ | [`GET /storage-providers`](https://docs.applivery.com/en/api/platform/organization-storage-providers/get-storage-providers/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `base.organization.management.list` ¹ | [`GET /organizations`](https://docs.applivery.com/en/api/platform/organization/get-organizations/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `base.organization.management.listGroups` | [`GET /groups`](https://docs.applivery.com/en/api/platform/organization/get-groups/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `base.organization.management.manageIntegrations` | — | ✓ | ✓ | – | – | – | – | – | | `base.organization.management.sendSupportEmail` | [`GET /support-email/:action`](https://docs.applivery.com/en/api/platform/organization/get-support-email-by-id/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `base.organization.management.update` | [`PUT /`](https://docs.applivery.com/en/api/platform/organization/put-organization/) | ✓ | ✓ | – | – | – | – | – | | `base.organization.notification.create` | [`POST /notifications`](https://docs.applivery.com/en/api/platform/organization-notifications/post-notification/) | ✓ | ✓ | – | – | – | – | – | | `base.organization.notification.get` | [`GET /notifications/:organizationNotificationId`](https://docs.applivery.com/en/api/platform/organization-notifications/get-notification/) | ✓ | ✓ | ✓ | – | – | – | – | | `base.organization.notification.list` | [`GET /notifications`](https://docs.applivery.com/en/api/platform/organization-notifications/get-notifications/) | ✓ | ✓ | ✓ | – | – | – | – | | `base.organization.notification.remove` | [`DELETE /notifications/:organizationNotificationId`](https://docs.applivery.com/en/api/platform/organization-notifications/delete-notification/) | ✓ | ✓ | – | – | – | – | – | | `base.organization.notification.update` | [`PUT /notifications/:organizationNotificationId`](https://docs.applivery.com/en/api/platform/organization-notifications/put-notification/) | ✓ | ✓ | – | – | – | – | – | | `base.organization.pushNotificationProvider.create` | — | ✓ | – | – | – | – | – | – | | `base.organization.pushNotificationProvider.get` | — | ✓ | – | – | – | – | – | – | | `base.organization.pushNotificationProvider.list` | — | ✓ | – | – | – | – | – | – | | `base.organization.pushNotificationProvider.remove` | — | ✓ | – | – | – | – | – | – | | `base.organization.pushNotificationProvider.update` | — | ✓ | – | – | – | – | – | – | | `base.organization.scim.create` | [`POST /providers/:providerId/scim`](https://docs.applivery.com/en/api/platform/organization-providers-scim/post-scim/) | ✓ | ✓ | – | – | ✓ | – | – | | `base.organization.scim.get` | [`GET /providers/:providerId/scim`](https://docs.applivery.com/en/api/platform/organization-providers-scim/get-scim/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `base.organization.scim.list` | — | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `base.organization.scim.remove` | [`DELETE /providers/:providerId/scim`](https://docs.applivery.com/en/api/platform/organization-providers-scim/delete-scim/) | ✓ | ✓ | – | – | ✓ | – | – | | `base.organization.scim.update` | [`PUT /providers/:providerId/scim`](https://docs.applivery.com/en/api/platform/organization-providers-scim/put-scim/) | ✓ | ✓ | – | – | ✓ | – | – | | `base.organization.segment.actions` ¹ | [`GET /segments/:segmentId/actions`](https://docs.applivery.com/en/api/platform/segment/get-actions/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `base.organization.segment.counts` ¹ | [`GET /segments/:segmentId/counts`](https://docs.applivery.com/en/api/platform/segment/get-counts/)
[`GET /segments/:segmentId/counts-by-entity/:entity`](https://docs.applivery.com/en/api/platform/segment/get-counts-by-entity-by-id/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `base.organization.segment.create` | [`POST /segments`](https://docs.applivery.com/en/api/platform/segment/post-segment/) | ✓ | – | – | – | – | – | – | | `base.organization.segment.get` | [`GET /segments/:segmentId`](https://docs.applivery.com/en/api/platform/segment/get-segment/) | ✓ | – | – | – | – | – | – | | `base.organization.segment.list` | [`GET /segments`](https://docs.applivery.com/en/api/platform/segment/get-segments/) | ✓ | – | – | – | – | – | – | | `base.organization.segment.remove` | [`DELETE /segments/:segmentId`](https://docs.applivery.com/en/api/platform/segment/delete-segment/) | ✓ | – | – | – | – | – | – | | `base.organization.segment.update` | [`PUT /segments/:segmentId`](https://docs.applivery.com/en/api/platform/segment/put-segment/) | ✓ | – | – | – | – | – | – | | `base.organization.segmentPermission.create` | [`POST /segment-permissions`](https://docs.applivery.com/en/api/platform/segment-permission/post-segment-permission/) | ✓ | – | – | – | – | – | – | | `base.organization.segmentPermission.get` | [`GET /segment-permissions/:permissionId`](https://docs.applivery.com/en/api/platform/segment-permission/get-segment-permission/) | ✓ | – | – | – | – | – | – | | `base.organization.segmentPermission.list` | [`GET /segment-permissions`](https://docs.applivery.com/en/api/platform/segment-permission/get-segment-permissions/) | ✓ | – | – | – | – | – | – | | `base.organization.segmentPermission.preview` | [`POST /segment-permissions/preview`](https://docs.applivery.com/en/api/platform/segment-permission/post-preview/) | ✓ | – | – | – | – | – | – | | `base.organization.segmentPermission.remove` | [`DELETE /segment-permissions/:permissionId`](https://docs.applivery.com/en/api/platform/segment-permission/delete-segment-permission/) | ✓ | – | – | – | – | – | – | | `base.organization.segmentPermission.update` | [`PUT /segment-permissions/:permissionId`](https://docs.applivery.com/en/api/platform/segment-permission/put-segment-permission/) | ✓ | – | – | – | – | – | – | | `base.organization.segmentPermission.userList` | [`GET /segment-permissions/users`](https://docs.applivery.com/en/api/platform/segment-permission/get-users/) | ✓ | – | – | – | – | – | – | | `base.organization.segmentRole.create` | [`POST /segment-roles`](https://docs.applivery.com/en/api/platform/segment-role/post-segment-role/) | ✓ | – | – | – | – | – | – | | `base.organization.segmentRole.get` | [`GET /segment-roles/:roleId`](https://docs.applivery.com/en/api/platform/segment-role/get-segment-role/) | ✓ | – | – | – | – | – | – | | `base.organization.segmentRole.list` | [`GET /segment-roles`](https://docs.applivery.com/en/api/platform/segment-role/get-segment-roles/) | ✓ | – | – | – | – | – | – | | `base.organization.segmentRole.remove` | [`DELETE /segment-roles/:roleId`](https://docs.applivery.com/en/api/platform/segment-role/delete-segment-role/) | ✓ | – | – | – | – | – | – | | `base.organization.segmentRole.update` | [`PUT /segment-roles/:roleId`](https://docs.applivery.com/en/api/platform/segment-role/put-segment-role/) | ✓ | – | – | – | – | – | – | | `base.organization.stats.get` | [`GET /stats`](https://docs.applivery.com/en/api/platform/organization-stats/get-stats/)
[`GET /stats/by-day`](https://docs.applivery.com/en/api/platform/organization-stats/get-by-day/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `base.organization.storageProvider.create` | [`POST /storage-providers`](https://docs.applivery.com/en/api/platform/organization-storage-providers/post-storage-provider/) | ✓ | ✓ | – | – | – | – | – | | `base.organization.storageProvider.delete` | [`DELETE /storage-providers/:storageProviderId`](https://docs.applivery.com/en/api/platform/organization-storage-providers/delete-storage-provider/) | ✓ | ✓ | – | – | – | – | – | | `base.organization.storageProvider.list` | [`GET /storage-providers`](https://docs.applivery.com/en/api/platform/organization-storage-providers/get-storage-providers/) | ✓ | ✓ | – | – | ✓ | – | – | | `base.organization.storageProvider.test` | [`GET /storage-providers/:storageProviderId/test`](https://docs.applivery.com/en/api/platform/organization-storage-providers/get-test/) | ✓ | ✓ | – | – | – | – | – | | `base.organization.storageProvider.update` | [`PUT /storage-providers/:storageProviderId`](https://docs.applivery.com/en/api/platform/organization-storage-providers/put-storage-provider/) | ✓ | ✓ | – | – | – | – | – | ¹ También permitido para: `base.organization.management.checkSlug`: Unassigned, No Role; `base.organization.management.create`: No Role; `base.organization.management.get`: Unassigned; `base.organization.management.getStorageProviders`: No Role; `base.organization.management.list`: Unassigned, No Role; `base.organization.segment.actions`: Unassigned, No Role; `base.organization.segment.counts`: Unassigned, No Role. **Personas (people.base) · 17 acciones, 19 endpoints** **Roles de Gestión de dispositivos** | Permiso | Endpoints | O | A | E | V | | --- | --- | :-: | :-: | :-: | :-: | | `people.base.audit.audit` | [`GET /members/audit`](https://docs.applivery.com/en/api/platform/members/get-audit/) | ✓ | – | – | – | | `people.base.audit.merge` | [`POST /members/audit/merge`](https://docs.applivery.com/en/api/platform/members/post-merge/) | ✓ | – | – | – | | `people.base.management.list` | [`GET /people`](https://docs.applivery.com/en/api/platform/people/get-people/) | ✓ | ✓ | ✓ | ✓ | | `people.base.organizationCollaborator.create` | [`POST /collaborators`](https://docs.applivery.com/en/api/app-distribution/organization-collaborators/post-collaborator/) | ✓ | ✓ | – | – | | `people.base.organizationCollaborator.get` | [`GET /collaborators/:organizationCollaboratorId`](https://docs.applivery.com/en/api/app-distribution/organization-collaborators/get-collaborator/) | ✓ | ✓ | ✓ | ✓ | | `people.base.organizationCollaborator.invitations` | [`GET /collaborators/invitations`](https://docs.applivery.com/en/api/app-distribution/organization-collaborators/invitations/get/) | ✓ | ✓ | ✓ | ✓ | | `people.base.organizationCollaborator.list` | [`GET /collaborators`](https://docs.applivery.com/en/api/app-distribution/organization-collaborators/get-collaborators/)
[`GET /collaborators/apps`](https://docs.applivery.com/en/api/app-distribution/organization-collaborators/get-apps/) | ✓ | ✓ | ✓ | ✓ | | `people.base.organizationCollaborator.listAll` | [`GET /collaborators/all`](https://docs.applivery.com/en/api/app-distribution/organization-collaborators/get-all/)
[`GET /collaborators/all-csv`](https://docs.applivery.com/en/api/app-distribution/organization-collaborators/get-all-csv/) | ✓ | ✓ | ✓ | ✓ | | `people.base.organizationCollaborator.listGroups` | [`GET /collaborators/groups`](https://docs.applivery.com/en/api/app-distribution/organization-collaborators/get-groups/) | ✓ | ✓ | ✓ | ✓ | | `people.base.organizationCollaborator.remove` | [`DELETE /collaborators/:organizationCollaboratorId`](https://docs.applivery.com/en/api/app-distribution/organization-collaborators/delete-collaborator/) | ✓ | ✓ | – | – | | `people.base.organizationCollaborator.removeInvitations` | [`DELETE /collaborators/invitations/:invitationId`](https://docs.applivery.com/en/api/app-distribution/organization-collaborators/invitations/delete-by-id/) | ✓ | ✓ | – | – | | `people.base.organizationCollaborator.update` | [`PUT /collaborators/:organizationCollaboratorId`](https://docs.applivery.com/en/api/app-distribution/organization-collaborators/put-collaborator/) | ✓ | ✓ | – | – | | `people.base.serviceAccount.create` | [`POST /service-accounts`](https://docs.applivery.com/en/api/platform/organization-service-accounts/post-service-account/) | ✓ | ✓ | – | – | | `people.base.serviceAccount.get` | [`GET /service-accounts/:serviceAccountId`](https://docs.applivery.com/en/api/platform/organization-service-accounts/get-service-account/) | ✓ | ✓ | ✓ | – | | `people.base.serviceAccount.list` | [`GET /service-accounts`](https://docs.applivery.com/en/api/platform/organization-service-accounts/get-service-accounts/) | ✓ | ✓ | ✓ | – | | `people.base.serviceAccount.regenerate` | [`PUT /service-accounts/:serviceAccountId/session`](https://docs.applivery.com/en/api/platform/organization-service-accounts/put-session/) | ✓ | ✓ | ✓ | – | | `people.base.serviceAccount.remove` | [`DELETE /service-accounts/:serviceAccountId`](https://docs.applivery.com/en/api/platform/organization-service-accounts/delete-service-account/) | ✓ | ✓ | – | – | **Roles de Distribución de apps** | Permiso | Endpoints | O | A | E | V | App A | App E | App V | | --- | --- | :-: | :-: | :-: | :-: | :-: | :-: | :-: | | `people.base.audit.audit` | [`GET /members/audit`](https://docs.applivery.com/en/api/platform/members/get-audit/) | ✓ | ✓ | – | – | – | – | – | | `people.base.audit.merge` | [`POST /members/audit/merge`](https://docs.applivery.com/en/api/platform/members/post-merge/) | ✓ | ✓ | – | – | – | – | – | | `people.base.management.list` | [`GET /people`](https://docs.applivery.com/en/api/platform/people/get-people/) | ✓ | ✓ | ✓ | ✓ | – | – | – | | `people.base.organizationCollaborator.create` | [`POST /collaborators`](https://docs.applivery.com/en/api/app-distribution/organization-collaborators/post-collaborator/) | ✓ | ✓ | – | – | – | – | – | | `people.base.organizationCollaborator.get` | [`GET /collaborators/:organizationCollaboratorId`](https://docs.applivery.com/en/api/app-distribution/organization-collaborators/get-collaborator/) | ✓ | ✓ | ✓ | ✓ | – | – | – | | `people.base.organizationCollaborator.invitations` | [`GET /collaborators/invitations`](https://docs.applivery.com/en/api/app-distribution/organization-collaborators/invitations/get/) | ✓ | ✓ | ✓ | ✓ | – | – | – | | `people.base.organizationCollaborator.list` | [`GET /collaborators`](https://docs.applivery.com/en/api/app-distribution/organization-collaborators/get-collaborators/)
[`GET /collaborators/apps`](https://docs.applivery.com/en/api/app-distribution/organization-collaborators/get-apps/) | ✓ | ✓ | ✓ | ✓ | – | – | – | | `people.base.organizationCollaborator.listAll` | [`GET /collaborators/all`](https://docs.applivery.com/en/api/app-distribution/organization-collaborators/get-all/)
[`GET /collaborators/all-csv`](https://docs.applivery.com/en/api/app-distribution/organization-collaborators/get-all-csv/) | ✓ | ✓ | ✓ | ✓ | – | – | – | | `people.base.organizationCollaborator.listGroups` | [`GET /collaborators/groups`](https://docs.applivery.com/en/api/app-distribution/organization-collaborators/get-groups/) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | `people.base.organizationCollaborator.remove` | [`DELETE /collaborators/:organizationCollaboratorId`](https://docs.applivery.com/en/api/app-distribution/organization-collaborators/delete-collaborator/) | ✓ | ✓ | – | – | – | – | – | | `people.base.organizationCollaborator.removeInvitations` | [`DELETE /collaborators/invitations/:invitationId`](https://docs.applivery.com/en/api/app-distribution/organization-collaborators/invitations/delete-by-id/) | ✓ | ✓ | – | – | – | – | – | | `people.base.organizationCollaborator.update` | [`PUT /collaborators/:organizationCollaboratorId`](https://docs.applivery.com/en/api/app-distribution/organization-collaborators/put-collaborator/) | ✓ | ✓ | – | – | – | – | – | | `people.base.serviceAccount.create` | [`POST /service-accounts`](https://docs.applivery.com/en/api/platform/organization-service-accounts/post-service-account/) | ✓ | ✓ | – | – | – | – | – | | `people.base.serviceAccount.get` | [`GET /service-accounts/:serviceAccountId`](https://docs.applivery.com/en/api/platform/organization-service-accounts/get-service-account/) | ✓ | ✓ | ✓ | – | – | – | – | | `people.base.serviceAccount.list` | [`GET /service-accounts`](https://docs.applivery.com/en/api/platform/organization-service-accounts/get-service-accounts/) | ✓ | ✓ | ✓ | – | – | – | – | | `people.base.serviceAccount.regenerate` | [`PUT /service-accounts/:serviceAccountId/session`](https://docs.applivery.com/en/api/platform/organization-service-accounts/put-session/) | ✓ | ✓ | ✓ | – | – | – | – | | `people.base.serviceAccount.remove` | [`DELETE /service-accounts/:serviceAccountId`](https://docs.applivery.com/en/api/platform/organization-service-accounts/delete-service-account/) | ✓ | ✓ | – | – | – | – | – | **Acciones masivas (base.bulk) · 6 acciones, 5 endpoints** **Roles de Gestión de dispositivos** | Permiso | Endpoints | O | A | E | V | | --- | --- | :-: | :-: | :-: | :-: | | `base.bulk.management.check` | [`POST /bulk-tasks/check`](https://docs.applivery.com/en/api/platform/bulk-tasks/post-check/) | ✓ | ✓ | ✓ | – | | `base.bulk.management.create` | [`POST /bulk-tasks/edge/create`](https://docs.applivery.com/en/api/platform/bulk-tasks/edge/post-create/) | ✓ | ✓ | ✓ | – | | `base.bulk.management.get` | [`GET /bulk-tasks/:bulkTaskId`](https://docs.applivery.com/en/api/platform/bulk-tasks/get-bulk-task/)
[`GET /bulk-tasks/edge/prepare`](https://docs.applivery.com/en/api/platform/bulk-tasks/edge/get-prepare/) | ✓ | ✓ | ✓ | – | | `base.bulk.management.list` | [`GET /bulk-tasks`](https://docs.applivery.com/en/api/platform/bulk-tasks/get-bulk-tasks/) | ✓ | ✓ | ✓ | – | | `base.bulk.management.remove` | — | ✓ | ✓ | ✓ | – | | `base.bulk.management.update` | — | ✓ | ✓ | ✓ | – | **Roles de Distribución de apps** | Permiso | Endpoints | O | A | E | V | App A | App E | App V | | --- | --- | :-: | :-: | :-: | :-: | :-: | :-: | :-: | | `base.bulk.management.check` | [`POST /bulk-tasks/check`](https://docs.applivery.com/en/api/platform/bulk-tasks/post-check/) | ✓ | ✓ | ✓ | – | – | – | – | | `base.bulk.management.create` | [`POST /bulk-tasks/edge/create`](https://docs.applivery.com/en/api/platform/bulk-tasks/edge/post-create/) | ✓ | ✓ | ✓ | – | – | – | – | | `base.bulk.management.get` | [`GET /bulk-tasks/:bulkTaskId`](https://docs.applivery.com/en/api/platform/bulk-tasks/get-bulk-task/)
[`GET /bulk-tasks/edge/prepare`](https://docs.applivery.com/en/api/platform/bulk-tasks/edge/get-prepare/) | ✓ | ✓ | ✓ | – | – | – | ✓ | | `base.bulk.management.list` | [`GET /bulk-tasks`](https://docs.applivery.com/en/api/platform/bulk-tasks/get-bulk-tasks/) | ✓ | ✓ | ✓ | – | – | – | ✓ | | `base.bulk.management.remove` | — | ✓ | ✓ | ✓ | – | – | – | – | | `base.bulk.management.update` | — | ✓ | ✓ | ✓ | – | – | – | – | **Subidas (base.upload) · 1 acciones, 1 endpoints** **Roles de Gestión de dispositivos** | Permiso | Endpoints | O | A | E | V | | --- | --- | :-: | :-: | :-: | :-: | | `base.upload.action.uploadLogo` | [`POST /upload/logo/logo`](https://docs.applivery.com/en/api/app-distribution/uploads/post-logo/) | ✓ | ✓ | ✓ | – | **Roles de Distribución de apps** | Permiso | Endpoints | O | A | E | V | App A | App E | App V | | --- | --- | :-: | :-: | :-: | :-: | :-: | :-: | :-: | | `base.upload.action.uploadLogo` ¹ | [`POST /upload/logo/logo`](https://docs.applivery.com/en/api/app-distribution/uploads/post-logo/) | ✓ | ✓ | ✓ | – | ✓ | ✓ | – | ¹ También permitido para: `base.upload.action.uploadLogo`: No Role. **Facturación (base.billing) · 2 acciones, 0 endpoints** **Roles de Gestión de dispositivos** | Permiso | Endpoints | O | A | E | V | | --- | --- | :-: | :-: | :-: | :-: | | `base.billing.management.get` | — | ✓ | ✓ | – | – | | `base.billing.management.list` | — | ✓ | ✓ | – | – | **Roles de Distribución de apps** | Permiso | Endpoints | O | A | E | V | App A | App E | App V | | --- | --- | :-: | :-: | :-: | :-: | :-: | :-: | :-: | | `base.billing.management.get` | — | ✓ | ✓ | – | – | – | – | – | | `base.billing.management.list` | — | ✓ | ✓ | – | – | – | – | – | **Gestión de facturación (billing.base) · 23 acciones, 0 endpoints** **Roles de Gestión de dispositivos** | Permiso | Endpoints | O | A | E | V | | --- | --- | :-: | :-: | :-: | :-: | | `billing.base.invoice.create` | — | ✓ | – | – | – | | `billing.base.invoice.get` | — | ✓ | – | – | – | | `billing.base.invoice.list` | — | ✓ | – | – | – | | `billing.base.invoice.remove` | — | ✓ | – | – | – | | `billing.base.invoice.update` | — | ✓ | – | – | – | | `billing.base.management.checkVatNumber` | — | ✓ | – | – | – | | `billing.base.management.create` | — | ✓ | – | – | – | | `billing.base.management.get` | — | ✓ | – | – | – | | `billing.base.management.getCountries` | — | ✓ | – | – | – | | `billing.base.management.list` | — | ✓ | – | – | – | | `billing.base.management.remove` | — | ✓ | – | – | – | | `billing.base.management.update` | — | ✓ | – | – | – | | `billing.base.plan.addPlan` | — | ✓ | – | – | – | | `billing.base.plan.cancelPlan` | — | ✓ | – | – | – | | `billing.base.plan.reactivatePlan` | — | ✓ | – | – | – | | `billing.base.plan.retryPayment` | — | ✓ | – | – | – | | `billing.base.plan.updatePlan` | — | ✓ | – | – | – | | `billing.base.source.create` | — | ✓ | – | – | – | | `billing.base.source.get` | — | ✓ | – | – | – | | `billing.base.source.list` | — | ✓ | – | – | – | | `billing.base.source.remove` | — | ✓ | – | – | – | | `billing.base.source.setDefault` | — | ✓ | – | – | – | | `billing.base.source.update` | — | ✓ | – | – | – | **Roles de Distribución de apps** | Permiso | Endpoints | O | A | E | V | App A | App E | App V | | --- | --- | :-: | :-: | :-: | :-: | :-: | :-: | :-: | | `billing.base.invoice.create` | — | ✓ | – | – | – | – | – | – | | `billing.base.invoice.get` | — | ✓ | – | – | – | – | – | – | | `billing.base.invoice.list` | — | ✓ | – | – | – | – | – | – | | `billing.base.invoice.remove` | — | ✓ | – | – | – | – | – | – | | `billing.base.invoice.update` | — | ✓ | – | – | – | – | – | – | | `billing.base.management.checkVatNumber` | — | ✓ | – | – | – | – | – | – | | `billing.base.management.create` | — | ✓ | – | – | – | – | – | – | | `billing.base.management.get` | — | ✓ | – | – | – | – | – | – | | `billing.base.management.getCountries` | — | ✓ | – | – | – | – | – | – | | `billing.base.management.list` | — | ✓ | – | – | – | – | – | – | | `billing.base.management.remove` | — | ✓ | – | – | – | – | – | – | | `billing.base.management.update` | — | ✓ | – | – | – | – | – | – | | `billing.base.plan.addPlan` | — | ✓ | – | – | – | – | – | – | | `billing.base.plan.cancelPlan` | — | ✓ | – | – | – | – | – | – | | `billing.base.plan.reactivatePlan` | — | ✓ | – | – | – | – | – | – | | `billing.base.plan.retryPayment` | — | ✓ | – | – | – | – | – | – | | `billing.base.plan.updatePlan` | — | ✓ | – | – | – | – | – | – | | `billing.base.source.create` | — | ✓ | – | – | – | – | – | – | | `billing.base.source.get` | — | ✓ | – | – | – | – | – | – | | `billing.base.source.list` | — | ✓ | – | – | – | – | – | – | | `billing.base.source.remove` | — | ✓ | – | – | – | – | – | – | | `billing.base.source.setDefault` | — | ✓ | – | – | – | – | – | – | | `billing.base.source.update` | — | ✓ | – | – | – | – | – | – | **Propiedad (owner.organization) · 2 acciones, 2 endpoints** **Roles de Gestión de dispositivos** | Permiso | Endpoints | O | A | E | V | | --- | --- | :-: | :-: | :-: | :-: | | `owner.organization.management.ownerChange` | [`POST /change-owner`](https://docs.applivery.com/en/api/platform/organization/post-change-owner/) | ✓ | – | – | – | | `owner.organization.management.remove` | [`DELETE /`](https://docs.applivery.com/en/api/platform/organization/delete-organization/) | ✓ | – | – | – | **Roles de Distribución de apps** | Permiso | Endpoints | O | A | E | V | App A | App E | App V | | --- | --- | :-: | :-: | :-: | :-: | :-: | :-: | :-: | | `owner.organization.management.ownerChange` | [`POST /change-owner`](https://docs.applivery.com/en/api/platform/organization/post-change-owner/) | ✓ | – | – | – | – | – | – | | `owner.organization.management.remove` | [`DELETE /`](https://docs.applivery.com/en/api/platform/organization/delete-organization/) | ✓ | – | – | – | – | – | – | ---