# 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-09-08T09:49:59.031Z - Documents: 1392 - Approx. word count: 437,783 - 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, SOC2, CIS, GDPR, and HIPAA 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 (proprietary Applivery technology) - **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 - **HIPAA Compliance** - Ensure medical device compliance with encryption, remote wipe, and audit trails - **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 - **FedRAMP & NIST Compliance** - Government-grade security controls and compliance certifications - **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 - **SOC 2 Type II Certified** - Third-party audited security controls - **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), Linux (via custom agents) #### 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 - **SOC 2 Type II Certified** - Third-party validated security controls - **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 | SOC2 | 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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. ## Delete enterprise **Required Permission:** `mdm.android.enterprise.remove` Permanently removes the EMM enterprise and disassociates it from the organization. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## Delete collaborator Source: https://docs.applivery.com/en/api/app-distribution/application-collaborators/delete-collaborator/ Description: **Required Permission:** `base.people.applicationCollaborator.remove` Delete collaborator ## Delete collaborator **Required Permission:** `base.people.applicationCollaborator.remove` Delete collaborator _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ --- ## Get collaborator by ID Source: https://docs.applivery.com/en/api/app-distribution/application-collaborators/get-collaborator/ Description: **Required Permission:** `base.people.applicationCollaborator.get` Get collaborator by ID ## Get collaborator by ID **Required Permission:** `base.people.applicationCollaborator.get` Get collaborator by ID _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ --- ## Get list of collaborator Source: https://docs.applivery.com/en/api/app-distribution/application-collaborators/get-collaborators/ Description: **Required Permission:** `base.people.applicationCollaborator.list` Get list of collaborator ## Get list of collaborator **Required Permission:** `base.people.applicationCollaborator.list` Get list of collaborator _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse 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:** `base.people.applicationCollaborator.removeInvitations` Remove invitations pending ## Remove invitations pending **Required Permission:** `base.people.applicationCollaborator.removeInvitations` Remove invitations pending _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse 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:** `base.people.applicationCollaborator.invitations` Get list of collaborator invitations pending ## Get list of collaborator invitations pending **Required Permission:** `base.people.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]_ --- ## Add new collaborator Source: https://docs.applivery.com/en/api/app-distribution/application-collaborators/post-collaborator/ Description: **Required Permission:** `base.people.applicationCollaborator.create` Add new collaborator ## Add new collaborator **Required Permission:** `base.people.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]_ --- ## Update collaborator Source: https://docs.applivery.com/en/api/app-distribution/application-collaborators/put-collaborator/ Description: **Required Permission:** `base.people.applicationCollaborator.update` Update collaborator ## Update collaborator **Required Permission:** `base.people.applicationCollaborator.update` Update collaborator _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## Delete employee Source: https://docs.applivery.com/en/api/app-distribution/application-employees/delete-employee/ Description: **Required Permission:** `base.people.applicationEmployee.remove` Delete employee ## Delete employee **Required Permission:** `base.people.applicationEmployee.remove` Delete employee _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ --- ## Get employee by ID Source: https://docs.applivery.com/en/api/app-distribution/application-employees/get-employee/ Description: **Required Permission:** `base.people.applicationEmployee.get` Get employee by ID ## Get employee by ID **Required Permission:** `base.people.applicationEmployee.get` Get employee by ID _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ --- ## Get list of employees Source: https://docs.applivery.com/en/api/app-distribution/application-employees/get-employees/ Description: **Required Permission:** `base.people.applicationEmployee.list` Get list of employees ## Get list of employees **Required Permission:** `base.people.applicationEmployee.list` Get list of employees _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ --- ## Add new employee Source: https://docs.applivery.com/en/api/app-distribution/application-employees/post-employee/ Description: **Required Permission:** `base.people.applicationEmployee.create` Add new employee ## Add new employee **Required Permission:** `base.people.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]_ --- ## Update employee Source: https://docs.applivery.com/en/api/app-distribution/application-employees/put-employee/ Description: **Required Permission:** `base.people.applicationEmployee.update` Update employee ## Update employee **Required Permission:** `base.people.applicationEmployee.update` Update employee _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## Get application actions Source: https://docs.applivery.com/en/api/app-distribution/application/get-actions/ Description: **Required Permission:** `mad.application.management.actions` Get application actions ## Get application actions **Required Permission:** `mad.application.management.actions` Get application actions _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse 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]_ --- ## 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]_ --- ## 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]_ --- ## Get list of download by csv Source: https://docs.applivery.com/en/api/app-distribution/application/get-downloads-csv/ Description: **Required Permission:** `mad.application.management.list` Get list of download by csv ## Get list of download by csv **Required Permission:** `mad.application.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]_ --- ## Retrieve distribution groups assigned to application Source: https://docs.applivery.com/en/api/app-distribution/application/get-groups/ Description: **Required Permission:** `mad.application.management.listGroups` Retrieves the list of distribution groups or user segments that have been granted access to this application, showing which teams or employee groups can download and install builds. ## Retrieve distribution groups assigned to application **Required Permission:** `mad.application.management.listGroups` Retrieves the list of distribution groups or user segments that have been granted access to this application, showing which teams or employee groups can download and install builds. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## Add new build Source: https://docs.applivery.com/en/api/app-distribution/build/post-organizations-organizationid-apps-applicationid-builds/ Description: **Required Permission:** `mad.build.management.create` Add new build ## Add new build **Required Permission:** `mad.build.management.create` Add new build _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## Delete collaborator Source: https://docs.applivery.com/en/api/app-distribution/organization-collaborators/delete-collaborator/ Description: **Required Permission:** `base.people.organizationCollaborator.remove` Delete collaborator ## Delete collaborator **Required Permission:** `base.people.organizationCollaborator.remove` Delete collaborator _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse 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:** `base.people.organizationCollaborator.listAll` Get list all collaborators csv ## Get list all collaborators csv **Required Permission:** `base.people.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]_ --- ## Get list all collaborators group by user Source: https://docs.applivery.com/en/api/app-distribution/organization-collaborators/get-all/ Description: **Required Permission:** `base.people.organizationCollaborator.listAll` Get list all collaborators group by user ## Get list all collaborators group by user **Required Permission:** `base.people.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]_ --- ## Get list of organization application collaborators Source: https://docs.applivery.com/en/api/app-distribution/organization-collaborators/get-apps/ Description: **Required Permission:** `base.people.organizationCollaborator.list` Get list of organization application collaborators ## Get list of organization application collaborators **Required Permission:** `base.people.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]_ --- ## Get collaborator by ID Source: https://docs.applivery.com/en/api/app-distribution/organization-collaborators/get-collaborator/ Description: **Required Permission:** `base.people.organizationCollaborator.get` Get collaborator by ID ## Get collaborator by ID **Required Permission:** `base.people.organizationCollaborator.get` Get collaborator by ID _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ --- ## Get list of collaborator Source: https://docs.applivery.com/en/api/app-distribution/organization-collaborators/get-collaborators/ Description: **Required Permission:** `base.people.organizationCollaborator.list` Get list of collaborator ## Get list of collaborator **Required Permission:** `base.people.organizationCollaborator.list` Get list of collaborator _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse 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:** `base.people.organizationCollaborator.listGroups` Get list of organization collaborators groups ## Get list of organization collaborators groups **Required Permission:** `base.people.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]_ --- ## Remove invitation pending Source: https://docs.applivery.com/en/api/app-distribution/organization-collaborators/invitations/delete-by-id/ Description: **Required Permission:** `base.people.organizationCollaborator.removeInvitations` Remove invitation pending ## Remove invitation pending **Required Permission:** `base.people.organizationCollaborator.removeInvitations` Remove invitation pending _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse 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:** `base.people.organizationCollaborator.invitations` Get list of collaborator invitations pending ## Get list of collaborator invitations pending **Required Permission:** `base.people.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]_ --- ## Add new collaborator Source: https://docs.applivery.com/en/api/app-distribution/organization-collaborators/post-collaborator/ Description: **Required Permission:** `base.people.organizationCollaborator.create` Add new collaborator ## Add new collaborator **Required Permission:** `base.people.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]_ --- ## Update collaborator Source: https://docs.applivery.com/en/api/app-distribution/organization-collaborators/put-collaborator/ Description: **Required Permission:** `base.people.organizationCollaborator.update` Update collaborator ## Update collaborator **Required Permission:** `base.people.organizationCollaborator.update` Update collaborator _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse schema — see canonical URL]_ --- ## Delete employee Source: https://docs.applivery.com/en/api/app-distribution/organization-employees/delete-employee/ Description: **Required Permission:** `base.people.organizationEmployee.remove` Delete employee ## Delete employee **Required Permission:** `base.people.organizationEmployee.remove` Delete employee _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse 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:** `base.people.organizationEmployee.listAll` Get list all employees csv ## Get list all employees csv **Required Permission:** `base.people.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]_ --- ## Get list all employees group by employee Source: https://docs.applivery.com/en/api/app-distribution/organization-employees/get-all/ Description: **Required Permission:** `base.people.organizationEmployee.listAll` Get list all employees group by employee ## Get list all employees group by employee **Required Permission:** `base.people.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]_ --- ## Get list of organization application employees Source: https://docs.applivery.com/en/api/app-distribution/organization-employees/get-apps/ Description: **Required Permission:** `base.people.organizationEmployee.list` Get list of organization application employees ## Get list of organization application employees **Required Permission:** `base.people.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]_ --- ## Get employee by ID Source: https://docs.applivery.com/en/api/app-distribution/organization-employees/get-employee/ Description: **Required Permission:** `base.people.organizationEmployee.get` Get employee by ID ## Get employee by ID **Required Permission:** `base.people.organizationEmployee.get` Get employee by ID _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ --- ## Get list of employees Source: https://docs.applivery.com/en/api/app-distribution/organization-employees/get-employees/ Description: **Required Permission:** `base.people.organizationEmployee.list` Get list of employees ## Get list of employees **Required Permission:** `base.people.organizationEmployee.list` Get list of employees _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse 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:** `base.people.organizationEmployee.listGroups` Get list of organization Employees groups ## Get list of organization Employees groups **Required Permission:** `base.people.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]_ --- ## Add new employees Source: https://docs.applivery.com/en/api/app-distribution/organization-employees/post-employee/ Description: **Required Permission:** `base.people.organizationEmployee.create` Add new employees ## Add new employees **Required Permission:** `base.people.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]_ --- ## Update employee Source: https://docs.applivery.com/en/api/app-distribution/organization-employees/put-employee/ Description: **Required Permission:** `base.people.organizationEmployee.update` Update employee ## Update employee **Required Permission:** `base.people.organizationEmployee.update` Update employee _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## Add new build Source: https://docs.applivery.com/en/api/platform/integration-builds/post-build/ Description: Add new build ## Add new build Add new build _[ApiSecurity schema — see canonical URL]_ No parameters. _[ApiRequest schema — see canonical URL]_ _[ApiResponse 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## Get members audit Source: https://docs.applivery.com/en/api/platform/members/get-audit/ Description: **Required Permission:** `base.people.audit.audit` Get members audit ## Get members audit **Required Permission:** `base.people.audit.audit` Get members audit _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse schema — see canonical URL]_ --- ## Audit Merge member Source: https://docs.applivery.com/en/api/platform/members/post-merge/ Description: **Required Permission:** `base.people.audit.merge` Audit Merge member ## Audit Merge member **Required Permission:** `base.people.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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## Remove service account by Id Source: https://docs.applivery.com/en/api/platform/organization-service-accounts/delete-service-account/ Description: **Required Permission:** `base.people.serviceAccount.remove` Remove service account by Id ## Remove service account by Id **Required Permission:** `base.people.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]_ --- ## Get service account by Id Source: https://docs.applivery.com/en/api/platform/organization-service-accounts/get-service-account/ Description: **Required Permission:** `base.people.serviceAccount.get` Get service account by Id ## Get service account by Id **Required Permission:** `base.people.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]_ --- ## Get list of service accounts Source: https://docs.applivery.com/en/api/platform/organization-service-accounts/get-service-accounts/ Description: **Required Permission:** `base.people.serviceAccount.list` Get list of service accounts ## Get list of service accounts **Required Permission:** `base.people.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]_ --- ## Add new serviceAccount Source: https://docs.applivery.com/en/api/platform/organization-service-accounts/post-service-account/ Description: **Required Permission:** `base.people.serviceAccount.create` Add new serviceAccount ## Add new serviceAccount **Required Permission:** `base.people.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]_ --- ## Regenerate serviceAccount session Source: https://docs.applivery.com/en/api/platform/organization-service-accounts/put-session/ Description: **Required Permission:** `base.people.serviceAccount.regenerate` Regenerate serviceAccount session ## Regenerate serviceAccount session **Required Permission:** `base.people.serviceAccount.regenerate` Regenerate serviceAccount session _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## Delete organization workspace permanently Source: https://docs.applivery.com/en/api/platform/organization/delete-organization/ Description: **Required Permission:** `base.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:** `base.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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## Transfer organization ownership to user Source: https://docs.applivery.com/en/api/platform/organization/post-change-owner/ Description: **Required Permission:** `base.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:** `base.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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## Get list of people paginated Source: https://docs.applivery.com/en/api/platform/people/get-people/ Description: **Required Permission:** `base.people.management.list` Get list of people paginated ## Get list of people paginated **Required Permission:** `base.people.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]_ --- ## 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]_ --- ## 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 ## Delete segment permission **Required Permission:** `base.organization.segmentPermission.remove` Delete segment permission _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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 ## Create segment permission **Required Permission:** `base.organization.segmentPermission.create` Create segment permission _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse 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 ## Update segment permission **Required Permission:** `base.organization.segmentPermission.update` Update segment permission _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse 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` Delete segment role ## Delete segment role **Required Permission:** `base.organization.segmentRole.remove` Delete segment role _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse 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` Get segment role ## Get segment role **Required Permission:** `base.organization.segmentRole.get` Get segment role _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse 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` List segment roles ## List segment roles **Required Permission:** `base.organization.segmentRole.list` List segment roles _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse 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` Create segment role ## Create segment role **Required Permission:** `base.organization.segmentRole.create` Create segment role _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse 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` Update segment role ## Update segment role **Required Permission:** `base.organization.segmentRole.update` Update segment role _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ No parameters. _[ApiRequest schema — see canonical URL]_ _[ApiResponse 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## Add new asset Source: https://docs.applivery.com/en/api/uem/managed-assets/post-asset/ Description: **Required Permission:** `mdm.global.asset.create` Add new asset ## Add new asset **Required Permission:** `mdm.global.asset.create` Add new asset _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## Send push notification Source: https://docs.applivery.com/en/api/uem/push-notifications/post-send/ Description: Send push notification ## Send push notification Send push notification _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ _[ApiRequest schema — see canonical URL]_ _[ApiResponse 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]_ --- ## 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]_ --- ## 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]_ --- ## Retrieve available user tags Source: https://docs.applivery.com/en/api/uem/users/get-tags/ Description: **Required Permission:** `mdm.global.mdmUser.list` Retrieve all distinct tag values currently assigned to device management users for filtering and organizational categorization purposes. ## Retrieve available user tags **Required Permission:** `mdm.global.mdmUser.list` Retrieve all distinct tag values currently assigned to device management users for filtering and organizational categorization purposes. _[ApiSecurity schema — see canonical URL]_ _[ApiParams schema — see canonical URL]_ No request body. _[ApiResponse 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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]_ --- ## 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. This section covers the available endpoints for managing Builds and Publications, including how to upload, update, query, and remove resources through the API. --- ## 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. This section explains the available authentication options for store users and how to 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. This section covers everything related to Builds: uploading, tagging, notifying Collaborators, managing download tokens, and working 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](/mobile-app-distribution/storage-regions/) in [AWS S3](#aws-s3) and [GCP Cloud Storage](#gcp-cloud-storage). This tutorial will help you properly configure your custom Storage region in AWS and GCP. ### 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. This page is a quick reference for the most commonly used Markdown elements. For the full 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. Please check [this tutorial](https://docs.applivery.com/en/app-distribution/builds/custom-storage-regions/) that will guide you through the process. --- ## 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. This section covers how to 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 This section covers how to 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. | ![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. --- ## Rolling Back a Release Source: https://docs.applivery.com/en/app-distribution/distribute/rolling-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. This section covers how to configure each integration and customize the events and messages that get 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. This section covers platform-specific topics such as signing certificates, app bundles, UDID provisioning, and distribution requirements for each supported platform. --- ## 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. This section covers working with Android App Bundles (AAB), managing signing certificates and keystores, distributing self-hosted Private Apps, and handling 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. This section covers collecting UDIDs for device provisioning, understanding app signing types (Ad-Hoc, Enterprise, App Store), troubleshooting installation issues, and working with platform-specific distribution requirements. Whether you're running an internal beta or distributing an enterprise app, this section has everything you need for Apple platform distribution. --- ## 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 not covered in the table above. 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/bedug-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. This tutorial will guide you through the process of conditionally excluding the Applivery SDK based on the Environment of the App (i.e., Live, Test, Staging, or Quality). :::info For the purpose of this tutorial, we are considering that you already know the basics of how to manage different environments by using Schemas and Configurations. If not, we recommend taking 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.0 **Minimum iOS version:** 15.0 **Language:** Swift **Distribution:** Swift Package Manager (recommended), CocoaPods (deprecated) #### 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`. | #### 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:** 4.8.0 **Minimum Android version:** Android 7.0 (API level 24) **Language:** Kotlin **Distribution:** Maven Central #### 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 This section helps you 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/bedug-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/bedug-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/bedug-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. This section covers everything for Android Device Management: 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 recommended enrollment method for fleet rollouts and one-off enrollments alike. 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. ::: :::info **Coming June 2026** - **Remote Support & Control** — remotely view and control AOSP Devices directly from the Applivery Dashboard. - **Advanced Kiosk Mode & Launcher** — expanded kiosk capabilities including the Basic and Advanced Launcher modes for AOSP. - **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. This section covers the different ways to distribute Android Apps — including public Play Store Apps, private Apps, and self-hosted APKs — as well as how to manage App behavior within your Policies. --- ## Block & Allow Apps Source: https://docs.applivery.com/en/device-management/android/app-management/app-blocking-allowing/ 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) --- ## 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. ::: --- ## 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-filter-format/) 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. #### Policies not covered here 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. This article covers `defaultApplicationSettings` only. ::: ### 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-distribution-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-distribution-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** Applivery gives you a key option for automatic installation. If you select **Forced Install**, the App will be downloaded and installed automatically on the Device—no user interaction required—and it cannot be uninstalled. However, you also have a couple of other useful options: - **Available**: Setting the installation type to **Available** lets you configure a Managed Google Play setup, making the Apps you select available for users to download. - **Blocked**: The App will be blocked and cannot be installed—even if the user tries to search for it in Managed Google Play. If the App was already installed on the Device, it will be automatically uninstalled. ![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 This article describes automatic App installation through **Managed Google Play**, which 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-device-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 described in this article — 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. In this guide, we’ll walk you through the process. ### 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://www.applivery.com/wp-content/uploads/2021/12/unknown-sources.jpeg "unknown-sources | Applivery") 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. ::: It’s important to select the **Force installed** install type to ensure its presence on the Device’s home screen. ![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. This section documents all available remote commands for Android, including when to use each one and what happens on the Device when the command is 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**. ::: #### 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. This section covers each available enrollment method — including QR code, Zero-touch, Smart Enrollment, and COPE — so you can choose the right approach for your deployment. --- ## 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-device-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 This page lists the complete set of Android Enterprise features supported by Applivery. 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). ### 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. We’ll walk you through how to configure each of these requirements in the next steps. :::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. This section covers how OEM Configs work in Applivery and provides guidance for supported manufacturers and their available configuration options. --- ## 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:** - [How to update Zebra Devices using Zebra OEMConfig](/android-mdm/oem-configs/update-zebra-devices/) - [How to change the Time Zone on Zebra Devices](/android-mdm/oem-configs/change-zebra-timezone/) - [Legacy Zebra OEMConfig](/android-mdm/oem-configs/legacy-zebra-oemconfig/) - [Android Management sample Policies](/android-mdm/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-device-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, refer [to this article](https://docs.samsungknox.com/admin/knox-efota/features/create-a-campaign/create-a-campaign/). --- ## 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. In this guide, we’ll explain how to change the time zone and configure the NTP server on **Zebra Devices**. To do so, we’ll use 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. This section covers all available Android Policy settings — 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. ::: --- ## 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-device-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. #### 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/disabling-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. --- ## 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).

### 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-device-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 The settings in this section 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-interpolation-tags/) — 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 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.

##### 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-interpolation-tags/) — 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 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. --- ## 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 This section helps you 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. --- ## 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. --- ## URL Filtering Source: https://docs.applivery.com/en/device-management/android/troubleshooting/url-filter-format/ 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. This section covers everything for Apple Device Management: 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. This section covers App distribution methods available for Apple platforms, including 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. This article dives into the two key approaches: app blocking and app allowing through Applivery. - **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. ::: --- ## Managing Apps Source: https://docs.applivery.com/en/device-management/apple/app-management/managing-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. :::note 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. ::: ### 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 This article will guide you through the process of Web Clip creation and how Applivery’s support streamlines and automates the task of generating 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. This section covers the commands that work across Apple platforms. Commands exclusive to one platform are documented 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 Welcome to this set of articles on managing Apple Devices in Applivery. If you are not familiar with the Apple ecosystem, we recommend that you continue reading this introductory article that summarizes the main concepts that you must take into account to successfully deploy the management of your Apple Devices. 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. If you’re already familiar with Apple Business or programs like the Apple Device Enrollment Program (DEP), Apple Volume Purchase Program (VPP), and features like supervision, feel free to skip ahead. If not, let’s make a brief introduction: ### 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/).  ### 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. This section covers the full range of available Policy settings for Apple platforms, including 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://www.applivery.com/wp-content/uploads/2024/05/Screenshot-2024-05-10-at-061435-1024x651.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-device-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, which is outside the scope of this article. - **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. If you take one thing from this article, take this: 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-device-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. This section covers each available enrollment method for iOS, iPadOS, and macOS — including DEP, Apple Configurator, account-driven enrollment, and manual enrollment — so you can choose the right approach for your deployment. --- ## 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. ### 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-device-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 [this guide](https://docs.applivery.com/en/device-management/apple/get-started/) for detailed instructions. 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. You can follow [this guide](https://docs.applivery.com/en/device-management/apple/enrollment/dep/) to learn how to connect your **DEP** token, and [this one](https://docs.applivery.com/en/device-management/apple/app-management/vpp/) for configuring **VPP** licenses. 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. ::: --- ## 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. This section is focused specifically on iOS and iPadOS: Policies, remote commands, and platform-specific troubleshooting. --- ## 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. This section documents all available remote commands for iOS and iPadOS, including when to use each one and what happens on the Device when the command is 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. This section covers all available Policy settings for iOS and iPadOS, organized by category. --- ## 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/6665d3bf-dc52-45af-942d-27b27858c74b.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 This section helps you 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. This section is focused specifically on macOS: App management, Policies, remote commands, and platform-specific troubleshooting. --- ## 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. This section covers the different App distribution methods for macOS, step-by-step deployment guides for common enterprise applications, and how to 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. TL;DR: Applivery's macOS App Catalog enables easy installation and management of macOS apps not found on the App Store, simplifying deployment and user access control. Key topics: macOS App Catalog, App Deployment, Applivery Platform, Application Management, Applivery, macOS, App Store, Apple Business, 1Clipboard, 1Password, Adobe Acrobat Reader, Aircall, Android Studio, AnyDo 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-device-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. --- ## 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. TL;DR: Deploy Cortex XDR on macOS silently using Applivery MDM by uploading the package, configuring a policy with an activation script, and applying a custom .mobileconfig profile. Key topics: Cortex XDR deployment, macOS MDM, Applivery configuration, Endpoint security, Cortex XDR, macOS, Applivery, Palo Alto Networks, MDM [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-device-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. TL;DR: Deploy and configure CrowdStrike Falcon on macOS using Applivery by uploading the package, configuring policies, and setting up full disk access for enhanced endpoint security. Key topics: CrowdStrike Falcon deployment, macOS configuration, Applivery MDM, Endpoint security, Full Disk Access policy, CrowdStrike Falcon, Applivery, macOS, CID, Grouping Tag **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-device-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/ Description: Escrow FileVault recovery keys to your MDM using Escrow Buddy and Applivery — silent deployment and configuration for macOS Devices. TL;DR: Deploy Escrow Buddy with Applivery to securely escrow FileVault recovery keys on macOS devices, enhancing security and compliance. Key topics: FileVault Encryption, macOS Device Management, Escrow Buddy Configuration, Escrow Buddy, Applivery, FileVault, GitHub **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-device-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.. --- ## App Permissions with PPPC Profiles Source: https://docs.applivery.com/en/device-management/apple/macos/app-management/managing-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-device-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. --- ## 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. TL;DR: Deploy PKG files to macOS devices using Applivery for streamlined app installation and management, either individually or through policies. Key topics: macOS app deployment, PKG file management, Mobile device management, Applivery, macOS, PKG files 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-device-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. TL;DR: Learn how to deploy and configure SentinelOne on macOS devices using Applivery MDM for enhanced endpoint security. Key topics: SentinelOne installation, macOS MDM configuration, Full Disk Access, Configuration profiles, Activation script, SentinelOne, macOS, Applivery, macOS Sequoia 15 **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. This section documents all available remote commands for macOS, including prerequisites such as supervision status and what happens on the Device when each command is 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. This section covers all available Policy settings for macOS, 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. This guide walks through each one, and through the trap that catches most people in Safari. ### 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-device-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-check-point/ 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-device-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-interpolation-tags/). - **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-device-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-device-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-device-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. ::: --- ## 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-device-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-device-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-device-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-device-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-device-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. --- ## 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-interpolation-tags/), 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 This section helps you 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. ::: --- ## 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. The configuration form includes the following sections: #### Server Configuration - **Server URL**: `https:///certsrv/mscep/mscep.dll`. - **CA Fingerprint**: This value must be extracted from the CA certificate used by the NDES server. To obtain it, open the CA certificate, navigate to the **Extensions** section, and locate the **CA Fingerprint entry**. Copy this value and paste it into the field. - **Authority name**: Enter the intermediate/issuing CA name exactly as it appears in the CA certificate. #### Key Configuration - **Key Size**: Typically **2048** or **4096**, depending on security policy. - **Key Type**: RSA. #### Subject Configuration Configure subject fields as required by the consuming service. Applivery supports [interpolation tags](https://docs.applivery.com/en/device-management/general-settings/dynamic-variables-interpolation-tags/) to auto-fill values from device or user attributes. #### Challenge Configuration - **Mode**: NDES. - **URL**: `https:///certsrv/mscep_admin`. - **Username**: Domain user with permissions for the Certificate Template configured on the NDES server. - **Password**: Password for the above user. Click **Save**, then reopen the configuration to copy the **Auth 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/) --- ## 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-device-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: Create dynamic Device Audiences in Applivery based on tags, serial numbers, and employee assignments for targeted Policy application. TL;DR: Device Audiences in Applivery enable dynamic device grouping for targeted policy application and simplified device management through automation. Key topics: Creating Device Audiences, Device Selection Criteria, Matched Devices Preview, Automation Rules Integration, Applivery, Device Audiences, Automation Rules **Device Audiences** is a powerful feature in Applivery that allows administrators to create **dynamic groups of Devices** based on specific criteria. These audiences simplify large-scale device management by enabling **targeted application of Policies**, **configurations**, and **deployments** **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 set of **selectors**—rules that determine which Devices are included. Each audience can include multiple selectors, and a Device becomes part of the audience if it matches **at least one** of them. 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. ### 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. ![create Device Audience](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/f4821f27-7529-4108-8369-8bf7c3060cab.png) The configuration form includes the following sections: #### Configuration - **Name**: Enter a descriptive name for the audience. - **Description** (Optional): Provide context about the audience’s purpose or usage scenario. #### Devices selection Each selector defines a condition for device inclusion. You can combine multiple selectors to capture Devices that match any of the specified rules. - **Device tags**: Include Devices based on their assigned tags or tag groups. Click **Add groups** to select existing tag groups. Each time you add a group, an **OR** condition is created — meaning a Device will match if it has **any tag** from **any of the selected groups**. - **Employee tags**: Include Devices linked to employees with specific tags or tag groups. Click **Add groups** to select existing employee tag groups. Each time you add a group, an **OR** condition is created — meaning a Device will match if it has **any tag** from **any of the selected groups**. - **Serial numbers**: Explicitly include specific Devices by their unique serial numbers. Click **Add serial numbers** and enter one or more values, separated by commas. Devices listed here will always be included in the audience, regardless of other selector criteria. - **Add device**: Manually add enrolled Devices to the audience. Click **Select a Device** to search among enrolled Devices, then click + Add to include it in the audience. - **Add employee**: Manually add specific employees, including all Devices associated with them. Click **Select an employee** to search existing users, then click + Add to include it in the audience. **Only existing employees can be added**. If an employee is missing, create them first in the **Directory** section. You can remove any selector at any time by clicking **Remove**. #### Matched Devices preview At the bottom of the editor, you’ll find the **Matched Devices preview** panel, which provides a real-time view of all Devices that currently meet your audience criteria. - **Device details**: Displays each Device’s name, serial number, and linked employee (if any). - **Matching selectors**: Shows which rule(s) caused each Device to be included (e.g., _Matched by Device Tag: test_ or _Matched by Serial Number: G4M6GKFXJT_). - **Live updates**: As Devices are tagged, untagged, or reassigned, the preview refreshes automatically. Use this preview to confirm that your selectors are working as intended before saving. If no Devices appear, double-check your criteria for accuracy or missing tags. :::info Device Audiences are dynamic — once created, they continuously update based on the most recent device and employee data. This ensures Policies and configurations remain automatically aligned with your organization’s current structure. ::: --- ## Distribute Resources Source: https://docs.applivery.com/en/device-management/general-settings/distributing-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-interpolation-tags/ 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**. 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**. 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-device-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/distributing-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/distributing-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. ![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. This section covers all available Device Management integrations, 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. This section covers how to 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. This section covers how to 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. This section covers how to 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. This section covers everything for Windows Device Management: 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. This section covers the available App distribution methods for Windows, how to upload and configure Apps, and how to 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) --- ## Managing Apps Source: https://docs.applivery.com/en/device-management/windows/app-management/managing-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 In this section, you will find two different 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. In this guide, we’ll 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. This section documents all available remote commands for Windows, including when to use each one and what happens on the Device when the command is 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, this page links to Microsoft's own reference for it. ::: ### 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. This section covers each available enrollment method for Windows, including manual enrollment, Azure AD join, and Autopilot, so you can choose the right approach for your deployment. --- ## 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. This section covers all available Windows Policy settings, 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/managing-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: Deploy BitLocker on Windows Devices using Applivery — silent deployment, user interaction methods, and PowerShell scripting covered. TL;DR: Learn how to deploy BitLocker using Applivery through silent policies, user interaction, or PowerShell scripting for Windows device encryption. Key topics: BitLocker deployment, Applivery configuration, PowerShell scripting, Silent encryption, User interaction encryption, BitLocker, Applivery, Windows, Entra ID, Active Directory, PowerShell BitLocker is a built-in Windows encryption feature that safeguards your data by encrypting drives. It offers extensive customization options, including the choice of drives to encrypt, encryption methods, recovery options, and protectors. With Applivery, you can enable BitLocker using different approaches: - Silently, without user intervention, or with end-user interaction. - By applying BitLocker configuration Policies or deploying custom PowerShell scripts. The best method depends on your specific Windows and Microsoft environment. ### Set up your silent policy To silently activate BitLocker using Applivery Policies, the Device must be joined to either **Entra ID** or **Active Directory**. This is required so BitLocker can back up the recovery keys. Once in the [**Applivery Dashboard**](https://dashboard.applivery.io/), head to **Policies** 1. Choose the Policy where you want to configure BitLocker. Then, from the left-hand menu, click **\+ Add configuration** 2 and use the search bar to find the **BitLocker** 3 configuration. ![bitlocker](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/c97d9a4a-02fb-4a94-a173-451d27f41bb5.png) The deployment process is straightforward: BitLocker settings can be customized as needed, but the Policy must include the following configurations: - **Allow Standard User Encryption** – Set to **1**. Enables the `RequireDeviceEncryption` policy to encrypt all fixed drives, even if the currently logged-in user is a standard (non-admin) account. - **Allow Warning for Other Disk Encryption** – Set to **0**. Disables the warning prompt. Starting with Windows 10 version 1803, this value can only be set on Azure Active Directory–joined Devices. When set to 0, Windows attempts to silently enable BitLocker. - **Require Device Encryption** – Set to **1**. Enforces device encryption. Setting this to 1 triggers encryption of all drives—silently or with user interaction—depending on the `AllowWarningForOtherDiskEncryption` setting. These settings ensure that encryption is enforced, standard user permissions are bypassed, and the recovery key is securely backed up to Entra ID or Active Directory. ### Deploy BitLocker with user interaction If Devices are not joined to Entra ID or Active Directory, you can still enable encryption using Applivery configuration Policies—however, the deployment will not be silent: - The user will be notified that the organization requires encryption. - The user will be prompted to start the encryption process. - The user will choose where to save the recovery key. In this scenario, you must enable the **Require Device Encryption** setting. If your users are not local administrators, you must also enable the **Allow Standard User Encryption** setting. ### Configure silent encryption using PowerShell You can activate BitLocker silently with a PowerShell script, even if your Devices are not joined to Entra ID or Active Directory. The following example enables BitLocker on the `C:` drive using TPM and a password protector. It saves the recovery key to the C: drive by default, but you can customize the save location to any folder or API endpoint: ``` if (($pshome -like "*syswow64*") -and ((Get-WmiObject Win32_OperatingSystem).OSArchitecture -like "64*")) { # relaunch this script under 64 bit shell & (join-path ($pshome -replace "syswow64", "sysnative")\powershell.exe) -file $myinvocation.mycommand.Definition @args exit } ## Set variables $mountPoint = "C:" $recoveryKeyPath = "C:\RecoveryKeys" # Change this to your desired path $timestamp = Get-Date -Format "yyyyMMdd_HHmmss" $computerName = $env:COMPUTERNAME $recoveryKeyFile = "$recoveryKeyPath\${computerName}_BitLockerKey_$timestamp.txt" ## Ensure the recovery key folder exists if (-not (Test-Path $recoveryKeyPath)) { New-Item -Path $recoveryKeyPath -ItemType Directory | Out-Null } ## Enable BitLocker with TPM and skip hardware test Enable-BitLocker -MountPoint $mountPoint -EncryptionMethod XtsAes256 -TPMProtector -UsedSpaceOnly -SkipHardwareTest ## Add Recovery Password Protector $protector = Add-BitLockerKeyProtector -MountPoint $mountPoint -RecoveryPasswordProtector ## Extract the recovery password and Id $recoveryPassword = (Get-BitLockerVolume -MountPoint "C:").KeyProtector | Where-Object {$_.KeyProtectorType -eq 'RecoveryPassword'} | Select-Object -ExpandProperty RecoveryPassword $keyProtectorId = (Get-BitLockerVolume -MountPoint "C:").KeyProtector | Where-Object {$_.KeyProtectorType -eq 'RecoveryPassword'} | Select-Object -ExpandProperty KeyProtectorId ## Save recovery password to file "Computer Name: $computerName`nDrive: $mountPoint`nKey ID: $keyProtectorId`nRecovery Password: $recoveryPassword`nDate: $timestamp" | Out-File -FilePath $recoveryKeyFile -Encoding UTF8 -Force Write-Host "Recovery password saved to: $recoveryKeyFile" -ForegroundColor Green exit 0 ``` Name the script `activateBitlocker.ps1`. To avoid permission issues, run it via a **scheduled task**. Create another script named `scheduledtask.ps1` to configure the task. ``` $targetFolder = "C:\tempScriptFolder" $scriptName = "activateBitlocker.ps1" # Change if you chose a different name. $scriptDestination = "$targetFolder\activateBitlocker.ps1" $taskName = "EnableBitLocker" ## Path where your Bitlocker activation script is within the msi file $scriptPath = Join-Path -Path $PSScriptRoot -ChildPath $scriptName #Creates a folder and copies script to it New-Item -ItemType Directory -Path $targetFolder -Force | Out-Null Copy-Item -Path $scriptPath -Destination $scriptDestination -Force ## Creates a scheduled task to execute the script. schtasks /Create /TN $taskName /TR "Powershell.exe -WindowStyle Hidden -ExecutionPolicy bypass -File `"$scriptDestination`"" /SC ONCE /ST 00:00 /RL HIGHEST /RU SYSTEM /F Start-Sleep -Seconds 3 ## Runs the scheduled task immediately schtasks /Run /TN $taskName Start-Sleep -Seconds 3 ## Removes the temporary folder and the scheduled task. Remove-Item -Path $targetFolder -Recurse -Force schtasks /Delete /TN $taskName /F ``` Place both scripts in the same folder, along with the following `.bat` file: ``` @echo off net session >nul 2>&1 if %errorLevel% NEQ 0 ( powershell.exe -WindowStyle Hidden -ExecutionPolicy bypass -Command "Start-Process -Verb RunAs -FilePath 'cmd.exe' -ArgumentList '/c %~f0'" exit /b ) powershell.exe -WindowStyle Hidden -ExecutionPolicy bypass -File "%~dp0scheduledtask.ps1" ``` Once the three files are packaged into a single `.msi`, upload it to Applivery and deploy it as an App within a Policy: - The `.bat` file creates the scheduled task. - Required files are temporarily copied to the C: drive. - BitLocker encryption is activated. - Temporary files are automatically removed after completion. --- ## 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/disabling-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 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 The group policy we’ll use can manage various local groups; however, this article will focus specifically on managing 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**. --- ## Manage Clipboard History Source: https://docs.applivery.com/en/device-management/windows/policies/managing-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) --- ## 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. ::: --- ## 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-accesss/ 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. #### 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** 2, and search for **Power** 3. ![power](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/8a9db0f9-5743-4fec-ac35-2e1407d9ca5b.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**. ![sleep timeout](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/e0d931d8-58a3-4b5b-b4b4-1dbffb471997.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/9f697318-b56f-4027-a8a3-2948f3a2f0d6.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/). ::: This section covers how to enable it, how licenses are counted, the session types you can pick from, and what to check when a session won't start. --- ## 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. ### 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 This section helps you 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. --- ## 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. --- ## index Source: https://docs.applivery.com/en/platform/api/ --- title: API description: >- Applivery Platform API — manage Service Accounts, authentication, and access control for programmatic integration with your systems. updatedDate: '2026-06-08' type: archive order: 8 itemName: API sidebarIcon: columns-3-cog slug: index updated_date: '2026-04-01' item_name: API sidebar_icon: columns-3-cog order_num: 8 featured: false category: Platform section: API platform: API audience: developers difficulty: intermediate keywords: - API - Service Accounts - Authentication - Access Control - Integration - Endpoints - Request Formats - Responses schema_type: APIReference faqs: - question: What is the Open API? answer: The Open API allows programmatic interaction with the platform. - question: What does the Open API provide? answer: >- It provides guidance on Service Accounts for authentication and a complete API reference. - question: How do I authenticate with the Open API? answer: You can authenticate using Service Accounts. - question: What kind of information is in the API reference? answer: >- The API reference details available endpoints, request formats, and responses. - question: What can I do with the Open API? answer: You can integrate the platform with your systems. - question: How does the Open API help with access control? answer: It uses Service Accounts for access control. - question: Where can I find information about API endpoints? answer: The API reference contains information about available endpoints. language: en domain: platform-administration capability: api-integration headline: 'API: Programmatic Access and Integration' target_keyword: Platform API secondary_keywords: - API integration - Service accounts - Authentication intent: informational reading_time: 2 prerequisites: - Basic understanding of APIs - Familiarity with authentication concepts faq_items: - question: What is the Open API? answer: The Open API allows programmatic interaction with the platform. - question: What does the Open API provide? answer: >- It provides guidance on Service Accounts for authentication and a complete API reference. - question: How do I authenticate with the Open API? answer: You can authenticate using Service Accounts. - question: What kind of information is in the API reference? answer: >- The API reference details available endpoints, request formats, and responses. - question: What can I do with the Open API? answer: You can integrate the platform with your systems. - question: How does the Open API help with access control? answer: It uses Service Accounts for access control. - question: Where can I find information about API endpoints? answer: The API reference contains information about available endpoints. how_to_steps: [] show_child_grid: true noindex: false evergreen: false pillar_content: false og_title: 'Platform API: Integrate with Ease' og_description: >- Discover how to use the Platform API for programmatic access, manage service accounts, and integrate with your existing systems. og_type: article og_template: gradient-modern twitter_card: summary_large_image summary: >- The Platform API provides developers with the tools needed to interact programmatically with the platform. It offers guidance on managing service accounts for authentication and access control, as well as a comprehensive API reference. This enables seamless integration with external systems. tldr: >- The Platform API allows developers to programmatically interact with the platform through service accounts, authentication, and a complete API reference. answer_target: >- The Platform API allows programmatic interaction with the platform. It uses service accounts for authentication and access control. A comprehensive API reference provides details on available endpoints, request formats, and responses, enabling seamless integration with your systems. key_takeaways: - The API enables programmatic interaction with the platform. - Service accounts are used for authentication and access control. - A complete API reference is available for exploring endpoints. - Integration with external systems is possible through the API. main_topics: - API - Service Accounts - Authentication - API Reference - Integration entities: - API - Service Accounts related_queries: - How do I authenticate with the Platform API? - What are service accounts and how do I manage them? - Where can I find the Platform API reference? - How can I integrate my system with the Platform API? - What request formats does the API support? related_topics: - service-accounts - authentication-methods - api-reference content_scope: introductory confidence_level: well-established limitations: >- This content provides an overview of the API. It does not cover specific code examples or advanced usage scenarios. update_frequency: occasionally word_count: 47 sources: [] organization: Not specified related_articles: [] see_also: [] translations: {} doc-type: api-reference section: "api-reference" --- 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. This section covers Service Account management and the full API reference, with endpoint details, request formats, and response examples. --- ## service-accounts Source: https://docs.applivery.com/en/platform/api/service-accounts/ --- title: Service Accounts description: >- Applivery Service Accounts for secure, automated API access — roles, permissions, and best practices for token management. slug: service-accounts type: article collection: docs locale: en visible: true canonical: 'https://docs.applivery.com/en/platform/api/service-accounts/' category: App Distribution section: API platform: API audience: administrators difficulty: intermediate keywords: - Service Account - API - Automation - Bearer Token - Workspace API - CI/CD - Security item_name: Service Accounts schema_type: TechArticle faqs: - question: What is an Applivery Service Account? answer: >- A Service Account is a special Applivery account for non-human authentication, representing an automated system that interacts with the Applivery API. - question: How do Service Accounts authenticate? answer: >- Service Accounts authenticate against the Workspace API using a Bearer token, granting workspace-level access. - question: When should I use a Service Account vs. an App API Token? answer: >- Use a Service Account for workspace-wide access (multiple apps) and the Workspace API. Use an App API Token for single-app access and the Integrations API. - question: What roles can I assign to a Service Account? answer: >- You can assign Admin (full access), Developer (app resource access), or Viewer (read-only access) roles to a Service Account. - question: How do I create a Service Account in Applivery? answer: >- Go to Workspace Settings > Service Accounts and click '+ Create Service Account'. You must have Admin permissions. - question: Where can I find the Service Account Bearer token? answer: >- The Bearer token is displayed after creating the Service Account. Copy it immediately, as it cannot be retrieved later. - question: How should I store the Service Account Bearer token securely? answer: >- Store the token as a secret in your CI/CD platform or secret manager, and never commit it to source control. - question: What Applivery features require a Service Account? answer: >- The Workspace API, BrowserStack App Live integration, and cross-app automation scripts require a Service Account. language: en domain: api-management capability: api-authentication headline: Understanding and Using Service Accounts for API Access target_keyword: Applivery Service Account secondary_keywords: - Workspace API - Bearer Token - API Authentication intent: informational reading_time: 8 prerequisites: - Basic understanding of APIs - Familiarity with Applivery platform - Knowledge of authentication methods faq_items: - question: What is an Applivery Service Account? answer: >- A Service Account is a special Applivery account for non-human authentication, representing an automated system that interacts with the Applivery API. - question: How do Service Accounts authenticate? answer: >- Service Accounts authenticate against the Workspace API using a Bearer token, granting workspace-level access. - question: When should I use a Service Account vs. an App API Token? answer: >- Use a Service Account for workspace-wide access (multiple apps) and the Workspace API. Use an App API Token for single-app access and the Integrations API. - question: What roles can I assign to a Service Account? answer: >- You can assign Admin (full access), Developer (app resource access), or Viewer (read-only access) roles to a Service Account. - question: How do I create a Service Account in Applivery? answer: >- Go to Workspace Settings > Service Accounts and click '+ Create Service Account'. You must have Admin permissions. - question: Where can I find the Service Account Bearer token? answer: >- The Bearer token is displayed after creating the Service Account. Copy it immediately, as it cannot be retrieved later. - question: How should I store the Service Account Bearer token securely? answer: >- Store the token as a secret in your CI/CD platform or secret manager, and never commit it to source control. - question: What Applivery features require a Service Account? answer: >- The Workspace API, BrowserStack App Live integration, and cross-app automation scripts require a Service Account. how_to_steps: [] updatedDate: '2026-04-01' show_child_grid: true featured: false noindex: false evergreen: false pillar_content: false og_title: 'Applivery Service Accounts: Secure API Access' og_description: >- Learn how to use Applivery Service Accounts for secure, automated API access. Understand roles, permissions, and best practices. og_type: article og_template: gradient-modern twitter_card: summary_large_image summary: >- Applivery Service Accounts provide a secure way for non-human entities like automated systems and CI/CD pipelines to interact with the Applivery API. They use Bearer tokens for authentication and offer workspace-level access, enabling cross-app automation and platform-level integrations. Understanding the roles, permissions, and secure storage of these tokens is crucial for maintaining the security of your Applivery workspace. tldr: >- Applivery Service Accounts enable secure, automated API access for non-human entities using Bearer tokens and workspace-level permissions. answer_target: >- An Applivery Service Account is a special type of account designed for non-human, machine-to-machine authentication with the Applivery API. It uses a Bearer token for authentication and provides workspace-level access, allowing automated systems, integrations, or pipelines to interact with resources across all apps and modules in your organization. This is ideal for cross-app automation and platform-level integrations. key_takeaways: - Service Accounts are for non-human API access. - Bearer tokens provide workspace-level access. - Securely store and rotate tokens regularly. - Choose the appropriate role based on the principle of least privilege. - Understand the difference between Service Accounts and App API Tokens. main_topics: - Service Account creation - Roles and Permissions - Bearer token usage - Secure token storage - Service Account vs App API Token entities: - Applivery - Workspace API - BrowserStack App Live - GitHub Actions - Azure Pipelines - Bitrise - Jenkins related_queries: - What is an Applivery Service Account? - How do I create an Applivery Service Account? - What are the different roles for Applivery Service Accounts? - How do I use a Bearer token for API authentication? - Where should I store my Applivery Service Account token? - What is the difference between a Service Account and an App API Token? - How do I manage existing Applivery Service Accounts? - How to rotate Applivery Service Account tokens? related_topics: - app-api-token - workspace-api - api-authentication content_scope: comprehensive confidence_level: well-established limitations: This guide provides comprehensive coverage of the topic. update_frequency: occasionally word_count: 858 sources: [] organization: Not specified related_articles: [] see_also: [] translations: {} doc-type: api-reference section: "api-reference" --- 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. This section covers how to configure each authentication method for your organization and 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. This section covers how to configure SSO and SCIM for your identity provider of choice, including 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** starting this guide. 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 the separate app approach described at the end of this guide. ::: **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. This guide covers the exact values to use for each portal type. ::: :::info If you plan to use a custom domain for your App Store or MDM Portal, configure it in Applivery **before** starting this guide. 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** starting this guide. 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. This section covers everything related to how your organization is set up and 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. This section covers the available roles, how permissions are structured across App Distribution and Device Management, and how to assign and manage Collaborator access. --- ## Windows Device Management Source: https://docs.applivery.com/en/roadmap/in-progress/windows-11-support/ Description: Enroll and manage Windows devices in Applivery, alongside your Apple and Android fleet. ## Windows Device Management ### What it is We are bringing Windows into the same console you already use for Apple and Android. The goal is one place to enroll, secure, and act on every device in your fleet, whatever it runs. ### Available now - Enrollment through Microsoft Entra ID and domain join - Remote actions: lock, wipe, and lost mode - Block or erase a Windows device - Pre-made policies to get implementations started quickly - A Windows management agent ### In progress - Certificate deployment over SCEP - Deeper policy parity with Apple and Android - More paths for new-device provisioning and migration from other tools ### Why it matters Most fleets are mixed. Managing Windows in the same place as your phones and Macs means one enrollment model, one policy engine, and one set of workflows, rather than a separate tool bolted on the side. --- *In progress. Enrollment and core remote actions are available today; policy and certificate coverage is expanding.* --- ## Agentic Mobile Device Management Source: https://docs.applivery.com/en/roadmap/planned/agentic-mdm/ Description: AI-assisted, proactive device management that handles routine work for you. ## Agentic Device Management ### The idea Most MDM is reactive. Something breaks or drifts out of policy, and someone reacts. Agentic MDM flips that around. The platform watches the fleet, spots problems early, and takes the routine action itself, so your team spends less time on repetitive work. ### Where we are today Several of the building blocks are already live: - Automation Rules run event-triggered workflows without manual steps - The macOS agent recovers on its own if its background service is stopped - Compliance checks catch devices that drift out of policy ### Where we are heading - Proactive suggestions that surface the right action before an issue becomes a problem - Natural-language operations, where you describe what you want and the platform assembles the steps - Wider self-healing across every platform we manage This is a direction rather than a dated release. We will share specifics as the work firms up. --- *Planned. Built on the Automation Rules, self-healing agents, and compliance checks that have already shipped.* --- ## Advanced Certificate Management Source: https://docs.applivery.com/en/roadmap/shipped/advanced-certificate-management/ Description: Connect a custom certificate provider for automated issuing and renewal. ## Advanced Certificate Management ### What it does Applivery can connect to your own certificate provider and handle issuing and renewal automatically. Certificates are requested, deployed, and renewed as part of your normal device workflows, so they do not lapse. ### Why it helps Expired certificates are a common and avoidable source of outages. With a connected provider, renewal happens on schedule without someone tracking dates by hand. It pairs with Automation Rules, so you can trigger a renewal when a certificate is close to expiring. --- *Shipped October 2025. Available on Enterprise plans.* --- ## Android App Controls Source: https://docs.applivery.com/en/roadmap/shipped/android-app-deployment/ Description: Deploy private APKs through the Android Management API and reset any app remotely. ## Android App Controls ### What it does Two upgrades to how you handle apps on managed Android devices: - **Private APK deployment** through the Android Management API. Your own in-house apps reach the fleet without being published anywhere public. - **Clear App Data command** resets a single app to a clean state without uninstalling it. The device stays enrolled and every other app is untouched. ### Why it helps When an app misbehaves, a shared device changes hands, or someone leaves, you fix it at the app level in seconds. There is no reinstall, no full device wipe, and no trip to the device. ### Docs [Android App Management](https://docs.applivery.com/en/device-management/android/app-management/app-updates/) --- *Shipped December 2025.* --- ## Android Kiosk and Custom Launcher Source: https://docs.applivery.com/en/roadmap/shipped/android-kiosk-launcher/ Description: Lock Android devices to a single app or a curated home screen, on an in-house engine. ## Android Kiosk and Custom Launcher ### What it does Kiosk mode locks an Android device to one app or a set you choose. The custom launcher gives shared and frontline devices a purpose-built home screen, with control over the layout for the way your teams work. Both run on an Android management engine we built in-house. ### Why it helps Single-purpose devices, shared devices, and frontline hardware need a locked-down, predictable experience. Owning the engine behind it means the end-user experience and the controls evolve together, so improvements reach devices sooner and behave consistently. ### Docs [Android Kiosk Mode](https://docs.applivery.com/en/device-management/android/policies/kiosk-mode/) --- *Shipped April 2026.* --- ## AOSP Platform Support Source: https://docs.applivery.com/en/roadmap/shipped/aosp-platform/ Description: Manage Android devices that run without Google Mobile Services. ## AOSP Platform Support ### What it does You can now enroll and manage Android devices that do not run Google Mobile Services: the rugged scanners, kiosks, and purpose-built hardware that a Google-dependent MDM cannot reach. Applivery's own device engine handles enrollment, policies, and app delivery directly. ### Why it helps A whole category of devices that used to sit outside your management plane is now inside it. The same enrollment, policy, and app workflows you already use cover mainstream phones and tablets and this specialized hardware, all in one place. ### Docs [AOSP Device Management](https://docs.applivery.com/en/device-management/android/aosp/) --- *Shipped May 2026.* --- ## Apple Device Migration Source: https://docs.applivery.com/en/roadmap/shipped/apple-device-migration/ Description: Move an Apple fleet to Applivery from another MDM without a factory reset. ## Apple Device Migration ### What it does You can move iOS, iPadOS, and macOS devices to Applivery from your current MDM without wiping them. Devices keep their data, apps, and settings through the switch. ### How it works Assign the devices to Applivery in Apple Business, set a migration deadline (1 to 90 days, reversible until it arrives), and users finish a short guided enrollment. Applivery also handles Activation Lock: it clears the old lock and applies a new one with its own bypass code, so devices arrive fully under your control. ### Why it helps Changing providers stops being a disruptive re-provisioning project. It becomes a scheduled, reversible change you can pilot with one team before committing the rest. ### Docs [Migrate Apple Devices to Applivery](https://docs.applivery.com/en/device-management/apple/enrollment/migrate-apple-devices/) --- *Shipped October 2025. Supported on iOS 26, iPadOS 26, and macOS 26.* --- ## Automation Rules Source: https://docs.applivery.com/en/roadmap/shipped/automation-rules/ Description: Event-triggered actions that run device-management workflows without manual work. ## Automation Rules ### What it does Automation Rules run predefined actions automatically when something happens in your fleet. You configure a trigger and its actions once, then the platform handles the routine work: enrollment workflows, policy assignments, certificate renewals, and compliance remediation. ### How it works You pair a trigger with a set of actions: ``` Trigger: Device joins the "Sales Team Android" audience Actions: Apply the Sales-Department policy (Priority: 200) Install the CRM app Send a welcome email to the user Tag the device "Sales-Provisioned" ``` The platform watches for the trigger continuously and runs the actions as soon as the condition is met. ### Triggers - Device events: enrolled, unenrolled, joins or leaves an audience, becomes non-compliant, OS version changes - User events: assigned or unassigned, attribute changes (department, location, role) - Time-based: certificate expiration approaching, scheduled checks - Security events: passcode violation, encryption change, jailbreak or root detection ### Actions - Apply or remove policies, install or uninstall apps, send device commands - Update tags and audience membership - Notify users or IT, create tickets, write audit-log entries - Call webhooks to external systems ### Safety Dry-run mode to test rules before they act, rate limiting, full audit logging, and an emergency switch to disable rules instantly. ### Docs [Automation Rules](https://docs.applivery.com/en/device-management/general-settings/automation-rules/) --- *Shipped October 2025. Available on Enterprise plans.* --- ## Device Audiences Source: https://docs.applivery.com/en/roadmap/shipped/device-audience/ Description: Dynamic fleet segmentation based on device and user properties for targeted management. ## Device Audiences ### What it does Device Audiences segment your fleet automatically based on device properties, user attributes, or custom criteria. You build smart groups that update on their own as devices change state or new ones enroll. There are no static lists to maintain. ### How it works Define criteria, and membership stays current: ``` Audience: "iOS Devices Needing Update" - OS Type = iOS - OS Version < 17.0 - Enrollment Status = Active ``` As devices update or users change departments, the audience updates automatically. You target policies, apps, and configurations at the audience instead of at individual devices. ### Criteria you can combine - Device: OS type and version, model, manufacturer, enrollment type, ownership, hardware and storage - User: department, job title, location, employee type, custom fields - Status: enrollment method, supervision, compliance state, last check-in, tags Mix any of these with AND/OR logic. A device can belong to several audiences at once. ### Why it helps - No manual list maintenance: audiences track the current state of the fleet - Precise targeting for phased rollouts and OS update campaigns - Works with Policy Composition, Automation Rules, and Smart Attributes ### Docs [Device Audiences](https://docs.applivery.com/en/device-management/general-settings/device-audiences/) --- *Shipped October 2025. Available on Enterprise plans.* --- ## macOS Setup Assistant Source: https://docs.applivery.com/en/roadmap/shipped/macos-setup-assistant/ Description: A guided onboarding flow that gets a new Mac ready right after enrollment. ## macOS Setup Assistant ### What it does Right after a Mac is enrolled, the Setup Assistant greets the user and walks them through getting the machine ready. It guides the first-run steps so the device reaches a working, correctly configured state. ### Why it helps New hires get to a productive Mac without IT holding their hand on day one. The steps that used to require a walkthrough or a support ticket now happen in a guided flow on the device itself. --- *Shipped April 2026.* --- ## Policy Composition Source: https://docs.applivery.com/en/roadmap/shipped/policy-composition/ Description: Apply multiple overlapping policies per device with priority-based conflict resolution. ## Policy Composition ### What it does Policy Composition lets you stack several policies on the same device, each with a priority weight from 1 to 1000. Instead of one giant policy that duplicates settings, you build your strategy in layers: a company baseline, department rules, regional compliance, and individual exceptions, all working together. ### How it works Rather than one monolithic policy, you compose from focused ones: ``` Corporate-Baseline (Priority: 100) Sales-Department (Priority: 200) EU-Region (Priority: 300) Manager-Overrides (Priority: 400) ``` When settings overlap, the higher priority wins. Non-conflicting settings from every policy still apply, so each policy stays small and reusable. ### Priority bands - 1 to 100: foundation policies (security baselines, core compliance) - 101 to 300: organizational policies (department, region, office) - 301 to 700: team and role-specific policies - 701 to 1000: individual exceptions and temporary overrides ### Why it helps - Cleaner architecture: single-purpose policies that are easier to maintain - Less duplication: write common settings once and reuse them - Safer changes: update one layer without rebuilding a whole configuration - Guaranteed baselines: core security applies regardless of other layers ### Docs [Policy Composition](https://docs.applivery.com/en/device-management/general-settings/policy-composition/) --- *Shipped October 2025. Available on Enterprise plans.* --- ## Policy Interpolation Source: https://docs.applivery.com/en/roadmap/shipped/policy-interpolation/ Description: Deploy personalized device configurations at scale using dynamic variables. ## Policy Interpolation ### What it does Interpolation lets you put dynamic variables in your configurations and policies. You write a policy once with placeholders, and the platform fills in the right value for each device or user at deployment time. No more maintaining dozens of near-identical policies or tracking custom values in a spreadsheet. ### How it works Instead of hardcoding values per device, you configure once with variables: ``` Device Name: {{department}}-Laptop-{{device.serial_short}} Email: {{user.email}} Department: {{user.department}} ``` The platform substitutes the correct values for each device and user during deployment. ### Available variables - User attributes: name, email, department, employee ID, location - Device properties: serial number, model, OS version, enrollment date - Custom fields: any custom attributes defined in your organization - Organizational data: team names, cost centers, office locations ### Common uses - Consistent device naming across the fleet - User-specific email and app configuration - Department-specific network profiles ### Docs [Dynamic Variables and Interpolation](https://docs.applivery.com/en/device-management/general-settings/dynamic-variables-interpolation-tags/) --- *Shipped October 2025. Generally available.* --- ## Segments Source: https://docs.applivery.com/en/roadmap/shipped/segments/ Description: Organize your fleet and every MDM resource into a hierarchical structure. ## Segments ### What it does Segments organize your fleet and its resources into a tree that matches how your company is actually laid out: regions, sites, departments, teams. You bind devices, policies, and apps to the branch where they belong. ### Why it helps Handing a region to a local admin, or aiming a policy at a single department, becomes a matter of picking the right node instead of selecting devices one at a time. As you add sites and teams, the tree grows with you, so a fleet of thousands stays as easy to navigate as your first hundred devices. ### Docs [Segments](https://docs.applivery.com/en/device-management/general-settings/segments/) --- *Shipped February 2026.* --- ## Native Self Service Apps Source: https://docs.applivery.com/en/roadmap/shipped/self-service-apps/ Description: Rebuilt Self Service apps that let employees install approved apps and check device status themselves. ## Native Self Service Apps ### What it does Employees get a native app where they can browse and install the apps you have approved, check their device status, and run self-service actions on their own. The iOS app was rebuilt from the ground up, Android got its own native Self Service app, and the macOS experience moved onto a refreshed design system. ### Why it helps Most routine requests to the help desk are things people can handle themselves if the tool is fast and clear. Native apps that load quickly and are easy to navigate cut those tickets down and give employees a cleaner day-to-day experience. --- *Android Self Service shipped March 2026. iOS Self Service and the refreshed macOS experience shipped April 2026.* --- ## SIM and eSIM Inventory Source: https://docs.applivery.com/en/roadmap/shipped/sim-esim-inventory/ Description: Track physical SIMs and eSIMs as inventory items linked to their devices. ## SIM and eSIM Inventory ### What it does Physical SIM and eSIM are now inventory item types of their own. You track each one as an asset and link it to the device that uses it. ### Why it helps Your connectivity assets stop living in a separate spreadsheet and start sitting next to the hardware they power. When a device is reassigned, retired, or lost, you already know which SIM or eSIM goes with it. The record for each device is more complete: hardware, apps, and the SIM or eSIM that keeps it online, all in one place. ### Docs [eSIM Management](https://docs.applivery.com/en/device-management/android/commands/esim-management/) --- *Shipped June 2026.* --- ## Smart Attributes Source: https://docs.applivery.com/en/roadmap/shipped/smart-attributes/ Description: Define custom fields on devices and users, then target and personalize with them. ## Smart Attributes ### What it does Smart Attributes are your own fields on devices and users, either free-form values or a fixed list to pick from. Once defined, you can build Device Audiences from them, target policies with them, and drop them into configurations through interpolation. ### Why it helps Your data model finally matches how you actually think about your fleet, rather than bending to whatever fixed fields happened to exist. It extends the same audience and interpolation engine already in the platform, so segmenting and personalizing stays consistent across every platform you manage. ### Docs [Smart Attributes](https://docs.applivery.com/en/device-management/general-settings/smart-attributes/) --- *Shipped March 2026.* --- ## 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, SOC2, CIS, GDPR y HIPAA. - **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 (tecnología propietaria de Applivery). - **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 - **Cumplimiento HIPAA** - Asegure el cumplimiento de dispositivos médicos con cifrado, borrado remoto y pistas de auditoría. - **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 - **Cumplimiento FedRAMP y NIST** - Controles de seguridad y certificaciones de cumplimiento de grado gubernamental. - **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 SOC 2 Tipo II** - Controles de seguridad auditados por terceros. - **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), Linux (a través de agentes personalizados). #### Puntos de referencia de rendimiento - **Implementación de políticas** - <5 minutos desde el guardado de la política hasta la aplicación en el dispositivo. - **Distribución de aplicaciones** - Carga de compilaciones de hasta 4 GB, distribución a más de 1.000 dispositivos en minutos. - **Registro de dispositivos** - <30 segundos para registro sin contacto, <2 minutos para registro manual. - **Tiempo de respuesta de la API** - <200 ms de latencia promedio para llamadas a la API. - **Tiempo de carga --- ## 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. Esta sección cubre los endpoints disponibles para gestionar Builds y Publicaciones, incluyendo cómo cargar, actualizar, consultar y eliminar recursos a través de la API. --- ## 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/en/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/en/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/en/app-distribution/api/builds/upload-build/) y [GET – Lista de Builds](https://docs.applivery.com/en/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/en/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/en/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/en/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/en/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/en/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/en/app-distribution/api/builds/upload-build/) y [GET – Lista de Builds](https://docs.applivery.com/en/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/en/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/en/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/en/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/en/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/en/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/en/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/en/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/en/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/en/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/en/app-distribution/api/builds/upload-build/) y [GET – Lista de Builds](https://docs.applivery.com/en/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/en/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/en/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/en/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/en/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/en/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/en/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/en/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/en/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/en/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/en/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/en/app-distribution/api/publications/create-publication/) y [GET – Lista de Publicaciones](https://docs.applivery.com/en/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/en/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/en/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/en/app-distribution/api/publications/update-publication/) y [DELETE](https://docs.applivery.com/en/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/en/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/en/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/en/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/en/app-distribution/api/publications/create-publication/) y [GET – Lista de Publicaciones](https://docs.applivery.com/en/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/en/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/en/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/en/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/en/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. Esta sección explica las opciones de autenticación disponibles para los usuarios de la tienda y cómo 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. Esta sección cubre todo lo relacionado con las Builds: carga, etiquetado, notificaciones a Colaboradores, gestión de tokens de descarga y 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](/mobile-app-distribution/storage-regions/) en [AWS S3](#aws-s3) y [GCP Cloud Storage](#gcp-cloud-storage). Este tutorial te ayudará a configurar correctamente tu región de almacenamiento personalizada en AWS y GCP. ### 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. Esta página es una referencia rápida de los elementos de Markdown más utilizados. Para la especificación completa, 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/en/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/en/app-distribution/distribute/user-groups/). - [Gestión de audiencias](https://docs.applivery.com/en/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**. Consulta [este tutorial](https://docs.applivery.com/en/app-distribution/builds/custom-storage-regions/) que te guiará por el proceso. --- ## 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. Esta sección explica cómo configurar cada integración, qué parámetros usar y cómo automatizar 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/en/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/en/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/en/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/en/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/en/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/en/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/en/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/en/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/en/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/en/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/en/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/en/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/en/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? Esta sección explica cómo hacer tus Apps disponibles para 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. | ![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/en/app-distribution/sdk/sdk-users/). ::: :::info Puedes obtener más información sobre los usuarios OTP siguiendo este [enlace](https://docs.applivery.com/en/app-distribution/distribute/distribute-apps/#otp-one-time-password-access). ::: * * * ### 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/en/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/en/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/rolling-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/en/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/en/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/en/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/en/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/en/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/en/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/en/app-distribution/distribute/manage-users/). ::: ### Grupos Un [**Grupo**](https://docs.applivery.com/en/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/en/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/en/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/en/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/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) 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/en/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. Esta sección cubre cómo configurar cada integración y personalizar 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. Esta sección cubre temas específicos de cada plataforma como certificados de firma, App Bundles, aprovisionamiento de UDIDs y requisitos de distribución para cada plataforma compatible. --- ## 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. Esta sección cubre el trabajo con Android App Bundles (AAB), la gestión de certificados de firma y keystores, la distribución de Apps Privadas self-hosted, y el manejo de 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/en/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/en/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/en/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/en/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. Esta sección cubre la recopilación de UDIDs para el aprovisionamiento de dispositivos, los tipos de firma de apps (Ad-Hoc, Enterprise, Development, TestFlight), la resolución de problemas de instalación y el trabajo con los requisitos de distribución específicos de la plataforma Apple. Tanto si estás ejecutando una beta interna como si distribuyes una app empresarial, esta sección tiene todo lo que necesitas para la distribución en plataformas 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/bedug-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. Este tutorial te guiará a través del proceso de excluir condicionalmente el SDK de Applivery según el entorno de la App (por ejemplo, Live, Test, Staging o Quality). :::info Para este tutorial, consideramos que ya conoces los conceptos básicos de cómo gestionar diferentes entornos usando Esquemas y Configuraciones. Si no es así, te recomendamos que eches 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/en/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/en/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/en/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/en/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. --- ## 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 Esta sección te ayuda a identificar y resolver 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/bedug-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/bedug-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/bedug-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. Esta sección cubre todo lo relacionado con la gestión de dispositivos Android: 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/#self-service-portal). 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 método de inscripción recomendado tanto para despliegues de flota como para inscripciones puntuales. 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. ::: :::info **Próximamente en junio de 2026** - **Soporte y control remoto** — visualiza y controla dispositivos AOSP de forma remota directamente desde el panel de Applivery. - **Modo quiosco y Launcher avanzados** — capacidades de quiosco expandidas incluyendo los modos Básico y Launcher Avanzado para AOSP. - **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. Esta sección cubre las diferentes formas de distribuir apps Android —incluyendo apps públicas de Play Store, apps privadas y APKs autoalojados—, así como la forma de gestionar el comportamiento de las apps dentro de tus políticas. --- ## Bloquear y permitir apps Source: https://docs.applivery.com/es/device-management/android/app-management/app-blocking-allowing/ 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) --- ## 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/#self-service-portal), 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. ::: --- ## 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. 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-filter-format/) 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 no incluidas en este artículo 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/#self-service-portal) — 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/#self-service-portal) 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. 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. Este artículo trata únicamente `defaultApplicationSettings`. ::: ### 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-distribution-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.es/device-management/android/app-management/private-app-distribution-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.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** Applivery te ofrece una opción clave para la instalación automática. Si seleccionas **Forzar la instalación**, la app se descargará e instalará automáticamente en el dispositivo —sin requerir interacción del usuario— y no podrá desinstalarse. Sin embargo, también tienes otras opciones útiles: - **Disponible**: Configurar el tipo de instalación como disponible te permite configurar Managed Google Play, haciendo que las apps que selecciones estén disponibles para que los usuarios las descarguen. - **Bloqueada**: La app será bloqueada y no podrá instalarse, incluso si el usuario intenta buscarla en Managed Google Play. Si la app ya estaba instalada en el dispositivo, se desinstalará automáticamente. ![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 Este artículo describe la instalación automática de apps a través de **Managed Google Play**, que 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-Servce de Applivery**](https://docs.applivery.es/device-management/android/policies/agent/#self-service-portal). 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.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. 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-device-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/#self-service-portal) utilizando el mismo flujo de trabajo descrito en este artículo, 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/#self-service-portal). 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. En esta guía, te explicaremos el proceso. ### 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. ::: Es importante seleccionar el tipo de instalación en modo **Forzar instalación** para asegurar su presencia en la pantalla de inicio del dispositivo. ![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. Esta sección documenta todos los comandos remotos disponibles para Android, incluyendo cuándo usar cada uno y qué sucede en el dispositivo cuando se ejecuta el comando. --- ## 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**. ::: #### 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. Esta sección cubre cada método de inscripción disponible — incluyendo código QR, Zero-Touch, Inscripción inteligente y COPE — para que puedas elegir el enfoque adecuado para tu implementación. --- ## 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-device-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í](#obtain-the-json-for-the-dcp-extras-field). ::: ![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 Esta página enumera el conjunto completo de funciones de Android Enterprise compatibles con Applivery. 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). ### 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. 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. Te guiaremos a través de cómo configurar cada uno de estos requisitos en los próximos pasos. :::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. Esta sección cubre cómo funcionan los OEM Configs en Applivery y proporciona orientación sobre los fabricantes compatibles y sus opciones de configuración disponibles. --- ## 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-device-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 [este artículo](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. En esta guía, te explicaremos cómo cambiar la zona horaria y configurar el servidor NTP en dispositivos Zebra. Para ello, utilizaremos 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. Esta sección cubre todas las configuraciones de políticas de Android disponibles —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. ::: --- ## 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-device-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. #### 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/disabling-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/#solucion-de-problemas-el-comando-restablecer-contrasena-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. --- ## 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/#management-options) 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).

### 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-device-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 Los ajustes de esta sección 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-interpolation-tags/) — 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 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.

##### 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-interpolation-tags/) — 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 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](#single-app-kiosk-mode) 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/#advanced-launcher-multi-app-kiosk-mode) 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. --- ## 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 Esta sección te ayuda a diagnosticar y resolver 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. --- ## 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/). --- ## Filtros URL Source: https://docs.applivery.com/es/device-management/android/troubleshooting/url-filter-format/ 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. Esta sección cubre todo lo relacionado con la Gestión de dispositivos Apple: 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. Esta sección cubre los métodos de distribución de apps disponibles para plataformas Apple, incluyendo 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. Este artículo explora los dos enfoques principales: el bloqueo y el permiso de apps a través de Applivery. - 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/managing-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. Answers: ¿Qué es Apple VPP? · ¿Cómo configurar Apple VPP en Applivery? · ¿Cuáles son los diferentes métodos de asignación de apps en VPP? · ¿Cómo comprar licencias de apps a través de Apple Business? · ¿Cómo sincronizar licencias VPP en Applivery? · ¿Qué es la asignación de apps basada en dispositivos? · ¿Qué es la asignación de apps basada en usuarios? · ¿Cómo funcionan los códigos de canje en VPP? 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. ::: ### 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 Este artículo te guiará a través del proceso de creación de Web Clips y cómo el soporte de Applivery agiliza y automatiza la tarea de generar 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. Esta sección recoge los comandos que funcionan en todas las plataformas Apple. Los comandos exclusivos de una plataforma están documentados 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 Bienvenido a esta serie de artículos sobre la gestión de dispositivos Apple en Applivery. Si no estás familiarizado con el ecosistema Apple, te recomendamos que continúes leyendo este artículo introductorio, que resume los principales conceptos que debes tener en cuenta para desplegar con éxito la gestión de tus 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. Si ya conoces Apple Business o programas como el Programa de inscripción de dispositivos Apple (DEP), el Programa de compra por volumen Apple (VPP) y funciones como la supervisión, puedes saltarte esta parte. Si no es así, haremos una breve introducción: ### 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) #### 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. Esta sección cubre toda la gama de ajustes de políticas disponibles para plataformas Apple, incluyendo 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. Answers: ¿Cuál es el propósito del Agente Apple de Applivery? · ¿Qué es el Self-Service para macOS en el Agente de Applivery? · ¿Qué pueden hacer los usuarios con el Self-Service en el Agente macOS de Applivery? · ¿Qué tipo de informes de estado proporciona el Agente macOS de Applivery? · ¿Qué es la lista de bloqueo de apps en el Agente macOS de Applivery? · ¿Qué informes de geolocalización ofrece el Agente iOS de Applivery? · ¿Con qué frecuencia informa el Agente iOS de Applivery la ubicación? · ¿Cómo activo el Agente iOS en Applivery? 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://www.applivery.com/wp-content/uploads/2024/05/Screenshot-2024-05-10-at-061435-1024x651.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) | #### 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) --- ## 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. 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-device-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, fuera del alcance de este artículo. - **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. 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í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-device-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. Esta sección cubre cada método de inscripción disponible para iOS, iPadOS y macOS — incluyendo DEP, Apple Configurator, inscripción por cuenta y inscripción manual — para que puedas elegir el enfoque adecuado para tu despliegue. --- ## 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. ### 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-device-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 [esta guía](https://docs.applivery.com/es/device-management/apple/get-started/) para obtener instrucciones detalladas. 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. Puedes seguir [esta guía](https://docs.applivery.com/es/device-management/apple/enrollment/dep/) para aprender a conectar tu token **DEP**, y [esta otra](https://docs.applivery.com/es/device-management/apple/app-management/vpp/) para configurar las licencias **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. ::: --- ## 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. Esta sección está centrada específicamente en iOS y iPadOS: políticas, comandos remotos y resolución de problemas específicos de la plataforma. --- ## 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. Esta sección documenta todos los comandos remotos disponibles para iOS y iPadOS, incluyendo cuándo usar cada uno y qué ocurre en el dispositivo cuando se ejecuta el comando. --- ## 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. Esta sección cubre todos los ajustes de política disponibles para iOS y iPadOS, organizados por categoría. --- ## 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. :::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. 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/6665d3bf-dc52-45af-942d-27b27858c74b.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 Esta sección te ayuda a diagnosticar y resolver 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. Esta sección está centrada específicamente en macOS: gestión de apps, políticas, comandos remotos y resolución de problemas específicos de la plataforma. --- ## 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. Esta sección cubre los distintos métodos de distribución de apps para macOS, guías de despliegue paso a paso para aplicaciones empresariales comunes y cómo gestionar 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-device-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. --- ## 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. 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-device-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. 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-device-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/ 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-device-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. --- ## Permisos de apps con perfiles PPPC Source: https://docs.applivery.com/es/device-management/apple/macos/app-management/managing-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-device-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. --- ## 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-device-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. Esta sección documenta todos los comandos remotos disponibles para macOS, incluyendo los requisitos previos como el estado de supervisión y lo que ocurre en el dispositivo cuando se envía cada comando. --- ## 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/#restablece-la-contraseña-del-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. Esta sección cubre todos los ajustes de política disponibles para macOS, 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. 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. Esta guía recorre cada uno, y también la trampa con la que tropieza casi todo el mundo en Safari. ### 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. - **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.** ### 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 — consulta [Bloquear y permitir apps](https://docs.applivery.com/es/device-management/apple/app-management/block-allow-apps/). ### 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-device-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-check-point/ 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-device-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. | **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+. | **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. | :::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-interpolation-tags/). - **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-device-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-device-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-device-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. ::: --- ## 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-device-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-device-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-device-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-device-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-device-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. --- ## 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/#agent-app-for-macos-devices). ::: ### 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-interpolation-tags/), 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/#agent-app-for-macos-devices). ::: ### 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/#agent-app-for-macos-devices). ::: ### 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/#agent-app-for-macos-devices). ::: ### 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/#agent-app-for-macos-devices). ::: ### 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 Esta sección te ayuda a diagnosticar y resolver 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. ::: --- ## 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) El formulario de configuración incluye las siguientes secciones: #### Configuración del servidor - **URL del servidor**: `https:///certsrv/mscep/mscep.dll`. - **Huella digital de la CA**: Este valor debe extraerse del certificado de la CA utilizado por el servidor NDES. Para obtenerlo, abre el certificado de la CA, navega a la sección **Extensiones** y localiza la entrada **Huella digital de la CA**. Copia este valor y pégalo en el campo. - **Nombre de la autoridad**: Introduce el nombre de la CA intermedia/emisora exactamente como aparece en el certificado de la CA. #### Configuración de la clave - **Tamaño de la clave**: Normalmente **2048** o **4096**, dependiendo de la política de seguridad. - **Tipo de clave**: RSA. #### Configuración del sujeto Configura los campos del sujeto según lo requiera el servicio consumidor. Applivery admite [etiquetas de interpolación](https://docs.applivery.com/es/device-management/general-settings/dynamic-variables-interpolation-tags/) para rellenar automáticamente los valores a partir de los atributos de dispositivo o usuario. #### Configuración del desafío - **Modo**: NDES. - **URL**: `https:///certsrv/mscep_admin`. - **Nombre de usuario**: Usuario de dominio con permisos para la plantilla de certificado configurada en el servidor NDES. - **Contraseña**: Contraseña del usuario anterior. Haz clic en **Guardar**, luego vuelve a abrir la configuración para copiar el **Token del Auth Connector** 4 que se muestra 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/) --- ## 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-device-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 basadas en etiquetas, números de serie y empleados para aplicar políticas de forma dirigida. TL;DR: Las audiencias de dispositivos de Applivery permiten agrupar dispositivos dinámicamente para aplicar políticas y configuraciones de forma dirigida y automatizada. Answers: ¿Qué son las audiencias de dispositivos de Applivery? · ¿Cómo funcionan las audiencias de dispositivos en Applivery? · ¿Cómo creo una audiencia de dispositivos en Applivery? · ¿Qué opciones de selección de dispositivos hay disponibles al crear una audiencia de dispositivos? · ¿Cómo funcionan las etiquetas de dispositivos en las audiencias de dispositivos de Applivery? · ¿Cómo funcionan las etiquetas de empleados en las audiencias de dispositivos de Applivery? · ¿Cómo puedo previsualizar los dispositivos que coinciden con los criterios de mi audiencia de dispositivos? · ¿Las audiencias de dispositivos de Applivery se actualizan automáticamente? Key topics: Definición de audiencias de dispositivos, Criterios de selección de dispositivos, Configuración de selectores, Vista previa de dispositivos coincidentes, Integración con reglas de automatización, Applivery, Audiencias de dispositivos, Reglas de automatización, MDM, UEM Las **audiencias de dispositivos** son una potente función de Applivery que permite a los administradores crear **grupos dinámicos de dispositivos** basados en criterios específicos. Estas audiencias simplifican la gestión de dispositivos a gran escala al permitir la **aplicación dirigida de políticas**, **configuraciones** y **despliegues** **a través de 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 conjunto de **selectores**, que son reglas que determinan qué dispositivos se incluyen. Cada audiencia puede incluir múltiples selectores, y un dispositivo pasa a formar parte de la audiencia si coincide con **al menos uno** de ellos. 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. ### 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. ![create Device Audience](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/f4821f27-7529-4108-8369-8bf7c3060cab.png) El formulario de configuración incluye las siguientes secciones: #### Configuración - **Nombre**: introduce un nombre descriptivo para la audiencia. - **Descripción** (Opcional): proporciona contexto sobre el propósito o el escenario de uso de la audiencia. #### Selección de dispositivos Cada selector define una condición para la inclusión de dispositivos. Puedes combinar múltiples selectores para capturar dispositivos que coincidan con cualquiera de las reglas especificadas. - **Etiquetas de dispositivos**: incluye dispositivos basándose en sus etiquetas o grupos de etiquetas asignados. Haz clic en **Añadir grupos** para seleccionar grupos de etiquetas existentes. Cada vez que añades un grupo, se crea una condición **OR**, lo que significa que un dispositivo coincidirá si tiene **alguna etiqueta** de **cualquiera de los grupos seleccionados**. - **Etiquetas de empleados**: incluye dispositivos vinculados a empleados con etiquetas o grupos de etiquetas específicos. Haz clic en **Añadir grupos** para seleccionar grupos de etiquetas de empleados existentes. Cada vez que añades un grupo, se crea una condición **OR**, lo que significa que un dispositivo coincidirá si tiene **alguna etiqueta** de **cualquiera de los grupos seleccionados**. - **Números de serie**: incluye explícitamente dispositivos específicos por sus números de serie únicos. Haz clic en **Añadir números de serie** e introduce uno o más valores, separados por comas. Los dispositivos listados aquí siempre se incluirán en la audiencia, independientemente de otros criterios de selección. - **Añadir dispositivo**: añade manualmente dispositivos inscritos en la audiencia. Haz clic en **Seleccionar un dispositivo** para buscar entre los dispositivos inscritos, luego haz clic en + Añadir para incluirlo en la audiencia. - **Añadir empleado**: añade manualmente empleados específicos, incluyendo todos los dispositivos asociados a ellos. Haz clic en **Seleccionar un empleado** para buscar usuarios existentes, luego haz clic en + Añadir para incluirlo en la audiencia. **Solo se pueden añadir empleados existentes**. Si falta un empleado, créalo primero en la sección **Directorio**. Puedes eliminar cualquier selector en cualquier momento haciendo clic en **Eliminar**. #### Vista previa de dispositivos coincidentes En la parte inferior del editor, encontrarás el panel de **Vista previa de dispositivos coincidentes**, que proporciona una visión en tiempo real de todos los dispositivos que actualmente cumplen tus criterios de audiencia. - **Detalles del dispositivo**: muestra el nombre de cada dispositivo, su número de serie y el empleado vinculado (si lo hay). - **Selectores coincidentes**: muestra qué regla(s) hicieron que cada dispositivo fuera incluido (por ejemplo, _Coincide por etiqueta de dispositivo: test_ o _Coincide por número de serie: G4M6GKFXJT_). - **Actualizaciones en tiempo real**: a medida que los dispositivos se etiquetan, se desetiquetan o se reasignan, la vista previa se actualiza automáticamente. Utiliza esta vista previa para confirmar que tus selectores funcionan como se espera antes de guardar. Si no aparece ningún dispositivo, verifica tus criterios para detectar errores o etiquetas faltantes. :::info Las audiencias de dispositivos son dinámicas: una vez creadas, se actualizan continuamente basándose en los datos más recientes de dispositivos y empleados. Esto garantiza que las políticas y configuraciones permanezcan automáticamente alineadas con la estructura actual de tu organización. ::: --- ## Distribución de recursos Source: https://docs.applivery.com/es/device-management/general-settings/distributing-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-interpolation-tags/ 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**. 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**. 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 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-device-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/distributing-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/distributing-resources/) es cualquier activo desplegable que se puede asignar a [**d**](https://docs.applivery.com/es/device-management/general-settings/distributing-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. ![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. Esta sección cubre todas las integraciones disponibles en la Gestión de Dispositivos, 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. Esta sección cubre cómo configurar 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. Esta sección cubre cómo conectar cada integración de seguridad con Applivery y configurarla 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. Esta sección cubre cómo configurar 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. Esta sección cubre todo lo relacionado con la Gestión de Dispositivos Windows: 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. Esta sección cubre los métodos de distribución de apps disponibles para Windows, cómo subir y configurar apps, y cómo asignarlas 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/managing-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 En esta sección encontrarás dos opciones diferentes 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. En esta guía, usaremos **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. Esta sección documenta todos los comandos remotos disponibles para Windows, incluyendo cuándo usar cada uno y qué sucede en el dispositivo cuando se ejecuta el comando. --- ## 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. 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, esta página enlaza 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. Esta sección cubre cada método de inscripción disponible para Windows, incluyendo la inscripción manual, la unión a Azure AD y Autopilot, para que puedas elegir el enfoque más adecuado para tu despliegue. --- ## 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. Esta sección cubre todos los ajustes de políticas de Windows disponibles, 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/managing-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: Despliega BitLocker en dispositivos Windows con Applivery — despliegue silencioso, métodos de interacción del usuario y scripting PowerShell incluidos. TL;DR: Aprende a desplegar BitLocker con Applivery mediante políticas silenciosas, interacción del usuario o scripts de PowerShell para el cifrado de Windows. Answers: ¿Qué es BitLocker? · ¿Cuáles son las formas de habilitar BitLocker con Applivery? · ¿Qué se necesita para la activación silenciosa de BitLocker con Applivery? · ¿Qué ajustes de BitLocker son obligatorios en las políticas de Applivery? · ¿Cómo puedo habilitar BitLocker si los dispositivos no están unidos a Entra ID o Active Directory? · ¿Puedo habilitar BitLocker silenciosamente con PowerShell si los dispositivos no están unidos a Entra ID o Active Directory? · ¿Cómo despliego un script PowerShell para la activación de BitLocker con Applivery? · ¿Qué hace el archivo .bat en el paquete de despliegue de BitLocker con PowerShell? BitLocker es una función de cifrado integrada en Windows que protege tus datos cifrando las unidades. Ofrece amplias opciones de personalización, incluyendo la elección de las unidades a cifrar, los métodos de cifrado, las opciones de recuperación y los protectores. Con Applivery, puedes habilitar BitLocker usando diferentes enfoques: - De forma silenciosa, sin intervención del usuario, o con interacción del usuario final. - Aplicando políticas de configuración de BitLocker o desplegando scripts PowerShell personalizados. El mejor método depende de tu entorno Windows y Microsoft específico. ### Configurar tu política silenciosa Para activar BitLocker de forma silenciosa usando las políticas de Applivery, el dispositivo debe estar unido a **Entra ID** o **Active Directory**. Esto es necesario para que BitLocker pueda hacer copia de seguridad de las claves de recuperación. 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. 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 configuración de **BitLocker** 3. ![bitlocker](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/c97d9a4a-02fb-4a94-a173-451d27f41bb5.png) El proceso de despliegue es sencillo: los ajustes de BitLocker pueden personalizarse según sea necesario, pero la política debe incluir las siguientes configuraciones: - **Permitir cifrado de usuario estándar** – Establecer en **1**. Habilita la política `RequireDeviceEncryption` para cifrar todas las unidades fijas, incluso si el usuario que ha iniciado sesión actualmente es una cuenta estándar (sin privilegios de administrador). - **Permitir advertencia para otro cifrado de disco** – Establecer en **0**. Deshabilita la advertencia. A partir de Windows 10 versión 1803, este valor solo puede establecerse en Dispositivos unidos a Azure Active Directory. Cuando se establece en 0, Windows intenta habilitar BitLocker de forma silenciosa. - **Requerir cifrado de dispositivo** – Establecer en **1**. Aplica el cifrado del dispositivo. Establecer esto en 1 activa el cifrado de todas las unidades — de forma silenciosa o con interacción del usuario — dependiendo del ajuste `AllowWarningForOtherDiskEncryption`. Estos ajustes garantizan que se aplique el cifrado, se omitan los permisos de usuario estándar y la clave de recuperación se guarde de forma segura en Entra ID o Active Directory. ### Desplegar BitLocker con interacción del usuario Si los dispositivos no están unidos a Entra ID o Active Directory, puedes habilitar igualmente el cifrado usando las políticas de configuración de Applivery — sin embargo, el despliegue no será silencioso: - Se notificará al usuario que la organización requiere cifrado. - Se pedirá al usuario que inicie el proceso de cifrado. - El usuario elegirá dónde guardar la clave de recuperación. En este escenario, debes habilitar el ajuste **Requerir cifrado de dispositivo**. Si tus usuarios no son administradores locales, también debes habilitar el ajuste **Permitir cifrado de usuario estándar**. ### Configurar el cifrado silencioso con PowerShell Puedes activar BitLocker de forma silenciosa con un script PowerShell, incluso si tus dispositivos no están unidos a Entra ID o Active Directory. El siguiente ejemplo habilita BitLocker en la unidad `C:` usando TPM y un protector de contraseña. Guarda la clave de recuperación en la unidad C: de forma predeterminada, pero puedes personalizar la ubicación de guardado a cualquier carpeta o endpoint de API: ``` if (($pshome -like "*syswow64*") -and ((Get-WmiObject Win32_OperatingSystem).OSArchitecture -like "64*")) { # relaunch this script under 64 bit shell & (join-path ($pshome -replace "syswow64", "sysnative")\powershell.exe) -file $myinvocation.mycommand.Definition @args exit } ## Set variables $mountPoint = "C:" $recoveryKeyPath = "C:\RecoveryKeys" # Change this to your desired path $timestamp = Get-Date -Format "yyyyMMdd_HHmmss" $computerName = $env:COMPUTERNAME $recoveryKeyFile = "$recoveryKeyPath\${computerName}_BitLockerKey_$timestamp.txt" ## Ensure the recovery key folder exists if (-not (Test-Path $recoveryKeyPath)) { New-Item -Path $recoveryKeyPath -ItemType Directory | Out-Null } ## Enable BitLocker with TPM and skip hardware test Enable-BitLocker -MountPoint $mountPoint -EncryptionMethod XtsAes256 -TPMProtector -UsedSpaceOnly -SkipHardwareTest ## Add Recovery Password Protector $protector = Add-BitLockerKeyProtector -MountPoint $mountPoint -RecoveryPasswordProtector ## Extract the recovery password and Id $recoveryPassword = (Get-BitLockerVolume -MountPoint "C:").KeyProtector | Where-Object {$_.KeyProtectorType -eq 'RecoveryPassword'} | Select-Object -ExpandProperty RecoveryPassword $keyProtectorId = (Get-BitLockerVolume -MountPoint "C:").KeyProtector | Where-Object {$_.KeyProtectorType -eq 'RecoveryPassword'} | Select-Object -ExpandProperty KeyProtectorId ## Save recovery password to file "Computer Name: $computerName`nDrive: $mountPoint`nKey ID: $keyProtectorId`nRecovery Password: $recoveryPassword`nDate: $timestamp" | Out-File -FilePath $recoveryKeyFile -Encoding UTF8 -Force Write-Host "Recovery password saved to: $recoveryKeyFile" -ForegroundColor Green exit 0 ``` Nombra el script `activateBitlocker.ps1`. Para evitar problemas de permisos, ejecútalo a través de una **tarea programada**. Crea otro script llamado `scheduledtask.ps1` para configurar la tarea. ``` $targetFolder = "C:\tempScriptFolder" $scriptName = "activateBitlocker.ps1" # Change if you chose a different name. $scriptDestination = "$targetFolder\activateBitlocker.ps1" $taskName = "EnableBitLocker" ## Path where your Bitlocker activation script is within the msi file $scriptPath = Join-Path -Path $PSScriptRoot -ChildPath $scriptName #Creates a folder and copies script to it New-Item -ItemType Directory -Path $targetFolder -Force | Out-Null Copy-Item -Path $scriptPath -Destination $scriptDestination -Force ## Creates a scheduled task to execute the script. schtasks /Create /TN $taskName /TR "Powershell.exe -WindowStyle Hidden -ExecutionPolicy bypass -File `"$scriptDestination`"" /SC ONCE /ST 00:00 /RL HIGHEST /RU SYSTEM /F Start-Sleep -Seconds 3 ## Runs the scheduled task immediately schtasks /Run /TN $taskName Start-Sleep -Seconds 3 ## Removes the temporary folder and the scheduled task. Remove-Item -Path $targetFolder -Recurse -Force schtasks /Delete /TN $taskName /F ``` Coloca ambos scripts en la misma carpeta, junto con el siguiente archivo `.bat`: ``` @echo off net session >nul 2>&1 if %errorLevel% NEQ 0 ( powershell.exe -WindowStyle Hidden -ExecutionPolicy bypass -Command "Start-Process -Verb RunAs -FilePath 'cmd.exe' -ArgumentList '/c %~f0'" exit /b ) powershell.exe -WindowStyle Hidden -ExecutionPolicy bypass -File "%~dp0scheduledtask.ps1" ``` Una vez que los tres archivos estén empaquetados en un único `.msi`, súbelo a Applivery y despliégalo como una App dentro de una política: - El archivo `.bat` crea la tarea programada. - Los archivos necesarios se copian temporalmente a la unidad C:. - Se activa el cifrado de BitLocker. - Los archivos temporales se eliminan automáticamente tras la finalización. --- ## 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/disabling-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 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 La política de grupo que usaremos puede gestionar varios grupos locales; sin embargo, este artículo se centra específicamente en la gestión del 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**. --- ## Gestionar el historial del portapapeles Source: https://docs.applivery.com/es/device-management/windows/policies/managing-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) --- ## 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. ::: --- ## 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-accesss/ 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. 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. #### 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. Answers: ¿Cómo configuro el tiempo de espera de suspensión para dispositivos Windows en Applivery? · ¿Dónde encuentro la configuración de Energía en Applivery? · ¿En qué unidad de tiempo se especifica el tiempo de espera de suspensión en Applivery? · ¿Cómo puedo configurar un dispositivo Windows para que se suspenda después de 5 minutos de inactividad con Applivery? · ¿Cómo puedo solicitar una contraseña cuando un dispositivo Windows se reactiva desde la suspensión con Applivery? · ¿Cuál es el propósito de configurar el tiempo de espera de suspensión en Applivery? · ¿Puedo configurar tiempos de espera de suspensión separados para dispositivos con batería y enchufados en Applivery? 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** 2 y busca **Energía** 3. ![power](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/8a9db0f9-5743-4fec-ac35-2e1407d9ca5b.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**. ![sleep timeout](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/e0d931d8-58a3-4b5b-b4b4-1dbffb471997.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/9f697318-b56f-4027-a8a3-2948f3a2f0d6.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/). ::: En esta sección verás cómo habilitarlo, cómo se contabilizan las licencias, qué tipos de sesión puedes elegir y qué revisar cuando una sesión no arranca. --- ## 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. 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. ### 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 instalda 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? Esta sección te ayuda a diagnosticar y resolver 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. --- ## push-notifications Source: https://docs.applivery.com/es/glossary/push-notifications/ --- term: Notificaciones push definition: Mensajes de alerta enviados desde un servidor a aplicaciones móviles en dispositivos inscritos, utilizados para la participación del usuario, comunicaciones urgentes y activación de actualizaciones de políticas MDM. description: Las notificaciones automáticas 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. aliases: - Mensajes push - Servicio de notificación - APN/FCM category: Comunicación tags: - mensajería - compromiso - gestión related: - mdm keywords: - notificaciones push - notificaciones moviles - APN - FCM inDefinedTermSet: Applivery Glossary updatedDate: 2026-01-24 title: Notificaciones push slug: push-notifications type: article updated_date: '2026-01-24' translation_key: push-notifications featured: false schema_type: DefinedTerm language: es target_keyword: notificaciones push secondary_keywords: - notificaciones moviles - APN - FCM intent: informational llm_summary: >- Notificaciones push es un término de movilidad empresarial en el glosario de Applivery. Proporciona un contexto práctico para las decisiones de distribución de aplicaciones, seguridad y administración de dispositivos. summary: >- Definición de referencia y uso práctico de las notificaciones push en operaciones de movilidad empresarial. tldr: >- Notificaciones push explicadas para casos de uso de administración de dispositivos y distribución de aplicaciones empresariales. og_title: Notificaciones push og_description: >- Descubra qué significan las notificaciones automáticas, por qué son importantes y cómo se aplican en los flujos de trabajo de movilidad empresarial. --- 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. --- ## 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. --- ## index Source: https://docs.applivery.com/es/platform/api/ --- title: 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. slug: index domain: platform-administration platform: API capability: api-integration content_type: article applivery_type: docs_product keywords: - API - Cuentas de servicio - autenticación - control de acceso - integración - endpoints - formatos de solicitud - respuestas intent: informational llm_summary: >- La API de la plataforma Applivery permite la integración programática con la plataforma. Las Cuentas de servicio se usan para la autenticación mediante tokens Bearer con acceso a nivel de Workspace. La sección cubre la gestión de Cuentas de servicio y la referencia completa de la API. difficulty: intermediate reading_time: 2 estimated_read_time: 2 minutos prerequisites: - Comprensión básica de las APIs - Familiaridad con los conceptos de autenticación related_topics: - service-accounts - authentication-methods - api-reference answers_questions: - ¿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? schema_type: APIReference headline: 'API: acceso programático e integración con Applivery' target_keyword: API de la plataforma Applivery secondary_keywords: - integración con la API Applivery - Cuentas de servicio - autenticación API category: Plataforma section: API audience: developers language: es version: '' reviewer: '' og_title: 'API de Applivery: integra tu plataforma fácilmente' og_description: >- Descubre cómo usar la API de la plataforma Applivery para el acceso programático, gestionar Cuentas de servicio e integrar con tus sistemas existentes. og_type: article og_template: gradient-modern twitter_card: summary_large_image tldr: >- 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. answer_target: >- La API de la plataforma Applivery permite la interacción programática con la plataforma. Usa Cuentas de servicio para la autenticación y el control de acceso. Una referencia completa de la API proporciona detalles sobre los endpoints disponibles, los formatos de solicitud y las respuestas, lo que permite la integración con tus sistemas. key_takeaways: - La API permite la interacción programática con la plataforma Applivery. - Las Cuentas de servicio se usan para la autenticación y el control de acceso. - Está disponible una referencia completa de la API para explorar los endpoints. - Es posible la integración con sistemas externos a través de la API. main_topics: - API - Cuentas de servicio - Autenticación - Referencia de la API - Integración entities: - API - Cuentas de servicio - Applivery content_scope: introductory confidence_level: well-established limitations: >- Este contenido ofrece una visión general de la API. No cubre ejemplos de código específicos ni escenarios de uso avanzados. update_frequency: occasionally word_count: 47 sources: [] organization: Not specified fact_checker: '' related_articles: [] see_also: [] translation_key: platform-api-index translations: en: content/en/docs/platform/api/index.mdx faq_items: - question: ¿Qué es la API abierta de Applivery? answer: >- La API abierta de Applivery permite la interacción programática con la plataforma para automatizar tareas y crear integraciones. - question: ¿Cómo me autentico con la API de Applivery? answer: >- Puedes autenticarte usando Cuentas de servicio con un token Bearer para acceso a nivel de Workspace. - question: ¿Qué son las Cuentas de servicio en Applivery? answer: >- Las Cuentas de servicio son cuentas especiales para la autenticación no humana (sistemas automatizados, pipelines de CI/CD) que interactúan con la API de Applivery. - question: ¿Dónde encuentro la referencia de la API de Applivery? answer: >- La referencia de la API detalla los endpoints disponibles, los formatos de solicitud y las respuestas, y se encuentra en la sección API de la documentación. - question: ¿Qué puedo hacer con la API de Applivery? answer: >- Puedes automatizar tareas, gestionar apps y dispositivos, y crear integraciones con tus sistemas internos. - question: ¿Cuál es la diferencia entre una Cuenta de servicio y un App API Token? answer: >- La Cuenta de servicio da acceso a nivel de Workspace (todas las apps). El App API Token da acceso solo a una app específica y se usa con la API de Integraciones. - question: ¿Quién puede crear Cuentas de servicio en Applivery? answer: >- Solo los usuarios con permisos de Admin pueden crear o eliminar Cuentas de servicio desde los Ajustes del Workspace. type: archive item_name: API faqs: - question: ¿Qué es la API abierta de Applivery? answer: >- La API abierta de Applivery permite la interacción programática con la plataforma para automatizar tareas y crear integraciones. - question: ¿Cómo me autentico con la API de Applivery? answer: >- Puedes autenticarte usando Cuentas de servicio con un token Bearer para acceso a nivel de Workspace. - question: ¿Qué son las Cuentas de servicio en Applivery? answer: >- Las Cuentas de servicio son cuentas especiales para la autenticación no humana (sistemas automatizados, pipelines de CI/CD) que interactúan con la API de Applivery. - question: ¿Dónde encuentro la referencia de la API de Applivery? answer: >- La referencia de la API detalla los endpoints disponibles, los formatos de solicitud y las respuestas, y se encuentra en la sección API de la documentación. - question: ¿Qué puedo hacer con la API de Applivery? answer: >- Puedes automatizar tareas, gestionar apps y dispositivos, y crear integraciones con tus sistemas internos. - question: ¿Cuál es la diferencia entre una Cuenta de servicio y un App API Token? answer: >- La Cuenta de servicio da acceso a nivel de Workspace (todas las apps). El App API Token da acceso solo a una app específica y se usa con la API de Integraciones. - question: ¿Quién puede crear Cuentas de servicio en Applivery? answer: >- Solo los usuarios con permisos de Admin pueden crear o eliminar Cuentas de servicio desde los Ajustes del Workspace. how_to_steps: [] updatedDate: '2026-06-08' show_child_grid: true featured: false noindex: false evergreen: false pillar_content: false related_queries: - ¿Cómo autenticarme con la API de Applivery? - ¿Qué son las Cuentas de servicio y cómo gestionarlas? - ¿Dónde encontrar la referencia de la API de Applivery? updated_date: '2026-06-08' summary: >- La API de la plataforma Applivery proporciona a los desarrolladores las herramientas necesarias para interactuar programáticamente con la plataforma. Ofrece orientación sobre la gestión de Cuentas de servicio para la autenticación y el control de acceso, así como una referencia completa de la API con detalles sobre endpoints, formatos de solicitud y respuestas. doc-type: api-reference section: "api-reference" --- 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. Esta sección cubre la gestión de Cuentas de servicio y la referencia completa de la API, con detalles sobre endpoints, formatos de solicitud y ejemplos de respuesta. --- ## service-accounts Source: https://docs.applivery.com/es/platform/api/service-accounts/ --- title: Cuentas de servicio 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. slug: service-accounts collection: docs locale: es visible: true canonical: 'https://docs.applivery.com/es/platform/api/service-accounts/' category: Distribución de apps section: API platform: API audience: administrators difficulty: intermediate keywords: - Cuenta de servicio - API - automatización - token Bearer - Workspace API - CI/CD - seguridad item_name: Cuentas de servicio schema_type: TechArticle language: es domain: api-management capability: api-authentication headline: Entender y usar las Cuentas de servicio para el acceso a la API target_keyword: Cuenta de servicio Applivery secondary_keywords: - Workspace API - token Bearer - autenticación API intent: informational reading_time: 8 prerequisites: - Comprensión básica de las APIs - Familiaridad con la plataforma Applivery - Conocimiento de los métodos de autenticación content_type: article applivery_type: docs_product llm_summary: >- Las Cuentas de servicio de Applivery son un tipo especial de cuenta para la autenticación no humana. Se autentican contra la Workspace API usando un token Bearer y proporcionan acceso a nivel de Workspace para automatización transversal de apps. Hay tres roles: Admin, Developer y Viewer. El token solo se muestra una vez al crearse — debe copiarse de inmediato. answers_questions: - ¿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? version: '' reviewer: '' faq_items: - question: ¿Qué es una Cuenta de servicio de Applivery? answer: >- Una Cuenta de servicio es un tipo especial de cuenta de Applivery para la autenticación no humana, que representa un sistema automatizado que interactúa con la API de Applivery. - question: ¿Cómo se autentican las Cuentas de servicio? answer: >- Las Cuentas de servicio se autentican contra la Workspace API usando un token Bearer, lo que les da acceso a nivel de Workspace. - question: ¿Cuándo debo usar una Cuenta de servicio en lugar de un App API Token? answer: >- Usa una Cuenta de servicio para el acceso a nivel de Workspace (múltiples apps) y la Workspace API. Usa un App API Token para el acceso a una sola app y la API de Integraciones. - question: ¿Qué roles puedo asignar a una Cuenta de servicio? answer: >- Puedes asignar los roles Admin (acceso completo), Developer (acceso a recursos de apps) o Viewer (solo lectura) a una Cuenta de servicio. - question: ¿Cómo creo una Cuenta de servicio en Applivery? answer: >- Ve a Ajustes del Workspace > Cuentas de servicio y haz clic en '+ Crear Cuenta de servicio'. Debes tener permisos de Admin. - question: ¿Dónde encuentro el token Bearer de la Cuenta de servicio? answer: >- El token Bearer se muestra después de crear la Cuenta de servicio. Cópialo de inmediato, ya que no se puede recuperar más adelante. - question: >- ¿Cómo debo almacenar de forma segura el token Bearer de la Cuenta de servicio? answer: >- Guarda el token como secreto en tu plataforma de CI/CD o gestor de secretos, y nunca lo confirmes en el control de versiones. - question: ¿Qué funciones de Applivery requieren una Cuenta de servicio? answer: >- La Workspace API, la integración BrowserStack App Live y los scripts de automatización transversal de apps requieren una Cuenta de servicio. how_to_steps: [] updatedDate: '2026-06-08' show_child_grid: true featured: false noindex: false evergreen: false pillar_content: false og_title: 'Cuentas de servicio de Applivery: acceso seguro a la API' og_description: >- Aprende a usar las Cuentas de servicio de Applivery para el acceso a la API seguro y automatizado. Entiende los roles, permisos y buenas prácticas. og_type: article og_template: gradient-modern twitter_card: summary_large_image summary: >- Las Cuentas de servicio de Applivery proporcionan una forma segura para que entidades no humanas como sistemas automatizados y pipelines de CI/CD interactúen con la API de Applivery. Usan tokens Bearer para la autenticación y ofrecen acceso a nivel de Workspace, lo que permite la automatización transversal de apps y las integraciones a nivel de plataforma. tldr: >- 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. answer_target: >- Una Cuenta de servicio de Applivery es un tipo especial de cuenta diseñada para la autenticación no humana con la API de Applivery. Usa un token Bearer para la autenticación y proporciona acceso a nivel de Workspace, lo que permite a los sistemas automatizados, integraciones o pipelines interactuar con los recursos de todas las apps y módulos de tu organización. key_takeaways: - Las Cuentas de servicio son para el acceso a la API no humano. - Los tokens Bearer proporcionan acceso a nivel de Workspace. - Almacena y rota los tokens de forma segura regularmente. - Elige el rol apropiado basándote en el principio de mínimo privilegio. - Entiende la diferencia entre las Cuentas de servicio y los App API Tokens. main_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 entities: - Applivery - Workspace API - BrowserStack App Live - GitHub Actions - Azure Pipelines - Bitrise - Jenkins related_queries: - ¿Qué es una Cuenta de servicio de Applivery? - ¿Cómo creo una Cuenta de servicio de Applivery? - ¿Cuáles son los diferentes roles para las Cuentas de servicio de Applivery? - ¿Cómo uso un token Bearer para la autenticación de la API? - ¿Dónde debo guardar el token de la Cuenta de servicio de Applivery? - ¿Cuál es la diferencia entre una Cuenta de servicio y un App API Token? - ¿Cómo gestionar las Cuentas de servicio existentes de Applivery? - ¿Cómo rotar los tokens de las Cuentas de servicio de Applivery? related_topics: - app-api-token - workspace-api - api-authentication content_scope: comprehensive confidence_level: well-established limitations: Esta guía ofrece una cobertura completa del tema. update_frequency: occasionally word_count: 858 sources: [] organization: Not specified fact_checker: '' related_articles: [] see_also: [] translations: en: content/en/docs/platform/api/service-accounts.mdx translation_key: platform-service-accounts faqs: - question: ¿Qué es una Cuenta de servicio de Applivery? answer: >- Una Cuenta de servicio es un tipo especial de cuenta de Applivery para la autenticación no humana, que representa un sistema automatizado que interactúa con la API de Applivery. - question: ¿Cómo se autentican las Cuentas de servicio? answer: >- Las Cuentas de servicio se autentican contra la Workspace API usando un token Bearer, lo que les da acceso a nivel de Workspace. - question: ¿Cuándo debo usar una Cuenta de servicio en lugar de un App API Token? answer: >- Usa una Cuenta de servicio para el acceso a nivel de Workspace (múltiples apps) y la Workspace API. Usa un App API Token para el acceso a una sola app y la API de Integraciones. - question: ¿Qué roles puedo asignar a una Cuenta de servicio? answer: >- Puedes asignar los roles Admin (acceso completo), Developer (acceso a recursos de apps) o Viewer (solo lectura) a una Cuenta de servicio. - question: ¿Cómo creo una Cuenta de servicio en Applivery? answer: >- Ve a Ajustes del Workspace > Cuentas de servicio y haz clic en '+ Crear Cuenta de servicio'. Debes tener permisos de Admin. - question: ¿Dónde encuentro el token Bearer de la Cuenta de servicio? answer: >- El token Bearer se muestra después de crear la Cuenta de servicio. Cópialo de inmediato, ya que no se puede recuperar más adelante. - question: >- ¿Cómo debo almacenar de forma segura el token Bearer de la Cuenta de servicio? answer: >- Guarda el token como secreto en tu plataforma de CI/CD o gestor de secretos, y nunca lo confirmes en el control de versiones. - question: ¿Qué funciones de Applivery requieren una Cuenta de servicio? answer: >- La Workspace API, la integración BrowserStack App Live y los scripts de automatización transversal de apps requieren una Cuenta de servicio. updated_date: '2026-06-08' type: article doc-type: api-reference section: "api-reference" --- 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/#how-to-create-segments-and-permissions). ::: 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. Esta sección cubre cómo configurar cada método de autenticación para tu organización y 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. Esta sección explica cómo configurar el SSO y el SCIM para tu proveedor de identidad, incluyendo 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 seguir esta guía. 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 el enfoque con aplicación separada descrito al final de esta guía. ::: **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. Esta guía cubre los valores exactos a usar para cada tipo de portal. ::: :::info Si planeas usar un dominio personalizado para tu Store Enterprise o MDM Portal, configúralo en Applivery **antes** de seguir esta guía. 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 seguir esta guía. 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. Esta sección cubre todo lo relacionado con cómo está configurada y representada tu organización 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. ::: --- ## Gestión de dispositivos Windows Source: https://docs.applivery.com/es/roadmap/in-progress/windows-11-support/ Description: Inscriba y administre dispositivos Windows en Applivery, junto con su flota de Apple y Android. ## Gestión de dispositivos Windows ### que es Llevamos Windows a la misma consola que ya usas para Apple y Android. El objetivo es un lugar para inscribir, proteger y actuar en cada dispositivo de su flota, independientemente de lo que ejecute. ### Disponible ahora - Inscripción a través de Microsoft Entra ID y unión de dominio - Acciones remotas: bloquear, borrar y modo perdido - Bloquear o borrar un dispositivo Windows - Políticas prediseñadas para iniciar implementaciones rápidamente - Un agente de administración de Windows ### En curso - Implementación de certificados sobre SCEP - Mayor paridad política con Apple y Android - Más rutas para el aprovisionamiento de nuevos dispositivos y la migración desde otras herramientas ### Por qué es importante La mayoría de las flotas son mixtas. Administrar Windows en el mismo lugar que sus teléfonos y Mac significa un modelo de inscripción, un motor de políticas y un conjunto de flujos de trabajo, en lugar de una herramienta independiente incorporada al costado. --- *En curso. La inscripción y las principales acciones remotas están disponibles hoy; La cobertura de pólizas y certificados se está ampliando.* --- ## Gestión agente de dispositivos móviles Source: https://docs.applivery.com/es/roadmap/planned/agentic-mdm/ Description: Gestión proactiva de dispositivos asistida por IA que gestiona el trabajo rutinario por usted. ## Gestión de dispositivos agentes ### la idea La mayoría de los MDM son reactivos. Algo se rompe o se sale de la política y alguien reacciona. Agentic MDM le da la vuelta a eso. La plataforma vigila la flota, detecta los problemas a tiempo y toma las medidas de rutina por sí misma, por lo que su equipo dedica menos tiempo al trabajo repetitivo. ### donde estamos hoy Varios de los componentes básicos ya están activos: - Las reglas de automatización ejecutan flujos de trabajo activados por eventos sin pasos manuales - El agente de macOS se recupera por sí solo si se detiene su servicio en segundo plano - Los controles de cumplimiento detectan dispositivos que se salen de la política ### hacia donde nos dirigimos - Sugerencias proactivas que muestran la acción correcta antes de que un problema se convierta en un problema. - Operaciones en lenguaje natural, donde usted describe lo que quiere y la plataforma ensambla los pasos. - Autocuración más amplia en todas las plataformas que administramos Esta es una dirección más que un comunicado fechado. Compartiremos detalles específicos a medida que el trabajo se consolide. --- *Planificado. Basado en las reglas de automatización, los agentes de autorreparación y las comprobaciones de cumplimiento que ya se han enviado.* --- ## Gestión avanzada de certificados Source: https://docs.applivery.com/es/roadmap/shipped/advanced-certificate-management/ Description: Conecte un proveedor de certificados personalizado para la emisión y renovación automatizadas. ## Gestión avanzada de certificados ### que hace Applivery puede conectarse a su propio proveedor de certificados y gestionar la emisión y renovación automáticamente. Los certificados se solicitan, implementan y renuevan como parte de los flujos de trabajo normales de su dispositivo, para que no caduquen. ### Por que ayuda Los certificados caducados son una fuente común y evitable de interrupciones. Con un proveedor conectado, la renovación se realiza según lo programado sin que nadie realice un seguimiento manual de las fechas. Se combina con las reglas de automatización, por lo que puede activar una renovación cuando un certificado está a punto de caducar. --- *Enviado en octubre de 2025. Disponible en planes Enterprise.* --- ## Controles de aplicaciones de Android Source: https://docs.applivery.com/es/roadmap/shipped/android-app-deployment/ Description: Implemente APK privados a través de la API de administración de Android y restablezca cualquier aplicación de forma remota. ## Controles de aplicaciones de Android ### que hace Dos mejoras en la forma de manejar aplicaciones en dispositivos Android administrados: - **Implementación de APK privado** a través de la API de administración de Android. Sus propias aplicaciones internas llegan a la flota sin publicarse en ningún lugar público. - **El comando Borrar datos de la aplicación** restablece una sola aplicación a un estado limpio sin desinstalarla. El dispositivo permanece registrado y todas las demás aplicaciones permanecen intactas. ### Por que ayuda Cuando una aplicación se comporta mal, un dispositivo compartido cambia de manos o alguien se va, lo arreglas a nivel de aplicación en segundos. No es necesario reinstalar, borrar completamente el dispositivo ni acceder al dispositivo. ### Documentos [Administración de aplicaciones de Android](https://docs.applivery.com/en/device-management/android/app-management/app-updates/) --- *Enviado en diciembre de 2025.* --- ## Quiosco de Android y lanzador personalizado Source: https://docs.applivery.com/es/roadmap/shipped/android-kiosk-launcher/ Description: Bloquee dispositivos Android en una sola aplicación o en una pantalla de inicio seleccionada, en un motor interno. ## Quiosco de Android y lanzador personalizado ### que hace El modo quiosco bloquea un dispositivo Android en una aplicación o conjunto que usted elija. El iniciador personalizado brinda a los dispositivos compartidos y de primera línea una pantalla de inicio especialmente diseñada, con control sobre el diseño de la forma en que trabajan sus equipos. Ambos se ejecutan en un motor de administración de Android que construimos internamente. ### Por que ayuda Los dispositivos de propósito único, los dispositivos compartidos y el hardware de primera línea necesitan una experiencia predecible y bloqueada. Ser propietario del motor que hay detrás significa que la experiencia del usuario final y los controles evolucionan juntos, por lo que las mejoras llegan antes a los dispositivos y se comportan de manera consistente. ### Documentos [Modo quiosco de Android](https://docs.applivery.com/en/device-management/android/policies/kiosk-mode/) --- *Enviado en abril de 2026.* --- ## Soporte de plataforma AOSP Source: https://docs.applivery.com/es/roadmap/shipped/aosp-platform/ Description: Administre dispositivos Android que se ejecutan sin los servicios móviles de Google. ## Soporte de plataforma AOSP ### que hace Ahora puede inscribir y administrar dispositivos Android que no ejecutan los servicios móviles de Google: escáneres resistentes, quioscos y hardware especialmente diseñado a los que un MDM dependiente de Google no puede acceder. El propio motor de dispositivo de Applivery maneja la inscripción, las políticas y la entrega de aplicaciones directamente. ### Por que ayuda Toda una categoría de dispositivos que solían estar fuera de su plano de gestión ahora están dentro de él. Los mismos flujos de trabajo de inscripción, pólizas y aplicaciones que ya utiliza cubren los teléfonos y tabletas convencionales y este hardware especializado, todo en un solo lugar. ### Documentos [Administración de dispositivos AOSP](https://docs.applivery.com/en/device-management/android/aosp/) --- *Enviado en mayo de 2026.* --- ## Migración de dispositivos Apple Source: https://docs.applivery.com/es/roadmap/shipped/apple-device-migration/ Description: Mueva una flota de Apple a Applivery desde otro MDM sin restablecer los valores de fábrica. ## Migración de dispositivos Apple ### que hace Puede mover dispositivos iOS, iPadOS y macOS a Applivery desde su MDM actual sin borrarlos. Los dispositivos conservan sus datos, aplicaciones y configuraciones a través del interruptor. ### como funciona Asigne los dispositivos a Applivery en Apple Business, establezca una fecha límite de migración (de 1 a 90 días, reversible hasta que llegue) y los usuarios finalizarán una breve inscripción guiada. Applivery también maneja el bloqueo de activación: borra el bloqueo antiguo y aplica uno nuevo con su propio código de derivación, para que los dispositivos lleguen completamente bajo su control. ### Por que ayuda Cambiar de proveedor deja de ser un proyecto disruptivo de reaprovisionamiento. Se convierte en un cambio programado y reversible que puedes pilotear con un equipo antes de comprometer al resto. ### Documentos [Migrar dispositivos Apple a Applivery](https://docs.applivery.com/en/device-management/apple/enrollment/migrate-apple-devices/) --- *Enviado en octubre de 2025. Compatible con iOS 26, iPadOS 26 y macOS 26.* --- ## Reglas de automatización Source: https://docs.applivery.com/es/roadmap/shipped/automation-rules/ Description: Acciones activadas por eventos que ejecutan flujos de trabajo de administración de dispositivos sin trabajo manual. ## Reglas de automatización ### que hace Las reglas de automatización ejecutan acciones predefinidas automáticamente cuando sucede algo en su flota. Usted configura un activador y sus acciones una vez, luego la plataforma maneja el trabajo de rutina: flujos de trabajo de inscripción, asignaciones de políticas, renovaciones de certificados y corrección de cumplimiento. ### como funciona Empareja un disparador con un conjunto de acciones: ``` Trigger: Device joins the "Sales Team Android" audience Actions: Apply the Sales-Department policy (Priority: 200) Install the CRM app Send a welcome email to the user Tag the device "Sales-Provisioned" ``` La plataforma vigila continuamente el disparador y ejecuta las acciones tan pronto como se cumple la condición. ### Desencadenantes - Eventos del dispositivo: inscrito, cancelado, unirse o abandonar una audiencia, deja de ser compatible, cambia la versión del sistema operativo - Eventos de usuario: asignados o no asignados, cambios de atributos (departamento, ubicación, rol) - Basado en el tiempo: se acerca la caducidad del certificado, comprobaciones programadas - Eventos de seguridad: violación de contraseña, cambio de cifrado, jailbreak o detección de raíz ### Comportamiento - Aplicar o eliminar políticas, instalar o desinstalar aplicaciones, enviar comandos al dispositivo - Actualizar etiquetas y membresía de audiencia - Notificar a los usuarios o al departamento de TI, crear tickets, escribir entradas en el registro de auditoría - Llamar webhooks a sistemas externos ### Seguridad Modo de ejecución en seco para probar las reglas antes de que actúen, limitación de velocidad, registro de auditoría completo y un interruptor de emergencia para desactivar las reglas al instante. ### Documentos [Reglas de automatización](https://docs.applivery.com/en/device-management/general-settings/automation-rules/) --- *Enviado en octubre de 2025. Disponible en planes Enterprise.* --- ## Audiencias de dispositivos Source: https://docs.applivery.com/es/roadmap/shipped/device-audience/ Description: Segmentación dinámica de flotas basada en propiedades de dispositivos y usuarios para una gestión específica. ## Audiencias de dispositivos ### que hace Device Audiences segmenta su flota automáticamente según las propiedades del dispositivo, los atributos del usuario o los criterios personalizados. Usted crea grupos inteligentes que se actualizan por sí solos a medida que los dispositivos cambian de estado o se inscriben nuevos. No hay listas estáticas que mantener. ### como funciona Defina los criterios y la membresía se mantendrá actualizada: ``` Audience: "iOS Devices Needing Update" - OS Type = iOS - OS Version < 17.0 - Enrollment Status = Active ``` A medida que los dispositivos se actualizan o los usuarios cambian de departamento, la audiencia se actualiza automáticamente. Dirige políticas, aplicaciones y configuraciones a la audiencia en lugar de a dispositivos individuales. ### Criterios que puedes combinar - Dispositivo: tipo y versión del sistema operativo, modelo, fabricante, tipo de inscripción, propiedad, hardware y almacenamiento - Usuario: departamento, puesto de trabajo, ubicación, tipo de empleado, campos personalizados - Estado: método de inscripción, supervisión, estado de cumplimiento, último check-in, etiquetas Mezcle cualquiera de estos con la lógica Y/O. Un dispositivo puede pertenecer a varios públicos a la vez. ### Por que ayuda - Sin mantenimiento manual de listas: las audiencias rastrean el estado actual de la flota - Orientación precisa para implementaciones por fases y campañas de actualización del sistema operativo - Funciona con composición de políticas, reglas de automatización y atributos inteligentes ### Documentos [Públicos de dispositivos](https://docs.applivery.com/en/device-management/general-settings/device-audiences/) --- *Enviado en octubre de 2025. Disponible en planes Enterprise.* --- ## Asistente de configuración de macOS Source: https://docs.applivery.com/es/roadmap/shipped/macos-setup-assistant/ Description: Un flujo de incorporación guiado que prepara una nueva Mac inmediatamente después de la inscripción. ## Asistente de configuración de macOS ### que hace Inmediatamente después de registrar una Mac, el asistente de configuración saluda al usuario y lo guía para preparar la máquina. Guía los pasos de la primera ejecución para que el dispositivo alcance un estado funcional y configurado correctamente. ### Por que ayuda Los nuevos empleados obtienen una Mac productiva sin que TI los tome de la mano desde el primer día. Los pasos que antes requerían un recorrido o un ticket de soporte ahora ocurren en un flujo guiado en el propio dispositivo. --- *Enviado en abril de 2026.* --- ## Composición de políticas Source: https://docs.applivery.com/es/roadmap/shipped/policy-composition/ Description: Aplique múltiples políticas superpuestas por dispositivo con resolución de conflictos basada en prioridades. ## Composición de políticas ### que hace La composición de políticas le permite acumular varias políticas en el mismo dispositivo, cada una con un peso de prioridad de 1 a 1000. En lugar de una política gigante que duplica la configuración, usted construye su estrategia en capas: una línea de base de la empresa, reglas de departamento, cumplimiento regional y excepciones individuales, todo trabajando en conjunto. ### como funciona En lugar de una política monolítica, se compone de políticas enfocadas: ``` Corporate-Baseline (Priority: 100) Sales-Department (Priority: 200) EU-Region (Priority: 300) Manager-Overrides (Priority: 400) ``` Cuando las configuraciones se superponen, gana la prioridad más alta. Se siguen aplicando configuraciones no conflictivas de cada política, por lo que cada política sigue siendo pequeña y reutilizable. ### Bandas prioritarias - 1 a 100: políticas básicas (líneas de base de seguridad, cumplimiento básico) - 101 a 300: políticas organizacionales (departamento, región, oficina) - 301 a 700: políticas específicas de rol y equipo - 701 a 1000: excepciones individuales y anulaciones temporales ### Por que ayuda - Arquitectura más limpia: políticas de propósito único que son más fáciles de mantener - Menos duplicación: escriba configuraciones comunes una vez y reutilícelas - Cambios más seguros: actualice una capa sin reconstruir una configuración completa - Líneas de base garantizadas: la seguridad central se aplica independientemente de otras capas ### Documentos [Composición de la política](https://docs.applivery.com/en/device-management/general-settings/policy-composition/) --- *Enviado en octubre de 2025. Disponible en planes Enterprise.* --- ## Interpolación de políticas Source: https://docs.applivery.com/es/roadmap/shipped/policy-interpolation/ Description: Implemente configuraciones de dispositivos personalizadas a escala utilizando variables dinámicas. ## Interpolación de políticas ### que hace La interpolación le permite poner variables dinámicas en sus configuraciones y políticas. Usted escribe una política una vez con marcadores de posición y la plataforma completa el valor correcto para cada dispositivo o usuario en el momento de la implementación. Ya no es necesario mantener docenas de políticas casi idénticas ni realizar un seguimiento de valores personalizados en una hoja de cálculo. ### como funciona En lugar de codificar valores por dispositivo, configura una vez con variables: ``` Device Name: {{department}}-Laptop-{{device.serial_short}} Email: {{user.email}} Department: {{user.department}} ``` La plataforma sustituye los valores correctos para cada dispositivo y usuario durante la implementación. ### Variables disponibles - Atributos de usuario: nombre, correo electrónico, departamento, ID de empleado, ubicación - Propiedades del dispositivo: número de serie, modelo, versión del sistema operativo, fecha de inscripción - Campos personalizados: cualquier atributo personalizado definido en su organización - Datos organizacionales: nombres de equipos, centros de costos, ubicaciones de oficinas ### Usos comunes - Nomenclatura coherente de dispositivos en toda la flota - Configuración de aplicaciones y correo electrónico específica del usuario - Perfiles de red específicos del departamento ### Documentos [Variables dinámicas e interpolación](https://docs.applivery.com/en/device-management/general-settings/dynamic-variables-interpolation-tags/) --- *Enviado en octubre de 2025. Disponible con carácter general.* --- ## Segmentos Source: https://docs.applivery.com/es/roadmap/shipped/segments/ Description: Organice su flota y todos los recursos de MDM en una estructura jerárquica. ## Segmentos ### que hace Los segmentos organizan su flota y sus recursos en un árbol que coincide con la distribución real de su empresa: regiones, sitios, departamentos, equipos. Vincula dispositivos, políticas y aplicaciones a la rama a la que pertenecen. ### Por que ayuda Entregar una región a un administrador local o dirigir una política a un solo departamento se convierte en una cuestión de elegir el nodo correcto en lugar de seleccionar los dispositivos uno por uno. A medida que agrega sitios y equipos, el árbol crece con usted, por lo que una flota de miles sigue siendo tan fácil de navegar como sus primeros cien dispositivos. ### Documentos [Segmentos](https://docs.applivery.com/en/device-management/general-settings/segments/) --- *Enviado en febrero de 2026.* --- ## Aplicaciones nativas de autoservicio Source: https://docs.applivery.com/es/roadmap/shipped/self-service-apps/ Description: Aplicaciones de autoservicio reconstruidas que permiten a los empleados instalar aplicaciones aprobadas y verificar ellos mismos el estado del dispositivo. ## Aplicaciones nativas de autoservicio ### que hace Los empleados obtienen una aplicación nativa donde pueden explorar e instalar las aplicaciones que usted haya aprobado, verificar el estado de su dispositivo y ejecutar acciones de autoservicio por su cuenta. La aplicación de iOS se reconstruyó desde cero, Android obtuvo su propia aplicación de autoservicio nativa y la experiencia de macOS pasó a un sistema de diseño renovado. ### Por que ayuda La mayoría de las solicitudes de rutina al servicio de asistencia técnica son cosas que las personas pueden manejar por sí mismas si la herramienta es rápida y clara. Las aplicaciones nativas que se cargan rápidamente y son fáciles de navegar reducen esos tickets y brindan a los empleados una experiencia diaria más limpia. --- *Android Self Service se lanzó en marzo de 2026. iOS Self Service y la experiencia actualizada de macOS se enviaron en abril de 2026.* --- ## Inventario de SIM y eSIM Source: https://docs.applivery.com/es/roadmap/shipped/sim-esim-inventory/ Description: Realice un seguimiento de las SIM físicas y las eSIM como elementos de inventario vinculados a sus dispositivos. ## Inventario de SIM y eSIM ### que hace La SIM física y la eSIM ahora son tipos de artículos propios del inventario. Realiza un seguimiento de cada uno como un activo y lo vincula al dispositivo que lo utiliza. ### Por que ayuda Sus activos de conectividad dejan de vivir en una hoja de cálculo separada y comienzan a ubicarse junto al hardware que alimentan. Cuando un dispositivo se reasigna, se retira o se pierde, ya sabes qué SIM o eSIM va con él. El registro de cada dispositivo es más completo: hardware, apps y la SIM o eSIM que lo mantiene online, todo en un solo lugar. ### Documentos [Gestión de eSIM](https://docs.applivery.com/en/device-management/android/commands/esim-management/) --- *Enviado en junio de 2026.* --- ## Atributos inteligentes Source: https://docs.applivery.com/es/roadmap/shipped/smart-attributes/ Description: Defina campos personalizados en dispositivos y usuarios, luego oriente y personalice con ellos. ## Atributos inteligentes ### que hace Los atributos inteligentes son sus propios campos en dispositivos y usuarios, ya sean valores de formato libre o una lista fija para elegir. Una vez definidos, puede crear audiencias de dispositivos a partir de ellos, orientar políticas con ellos y colocarlos en configuraciones mediante interpolación. ### Por que ayuda Su modelo de datos finalmente coincide con lo que realmente piensa acerca de su flota, en lugar de ceder a cualquier campo fijo que existiera. Amplía la misma audiencia y el mismo motor de interpolación que ya está en la plataforma, por lo que la segmentación y la personalización se mantienen consistentes en todas las plataformas que administra. ### Documentos [Atributos inteligentes](https://docs.applivery.com/en/device-management/general-settings/smart-attributes/) --- *Enviado en marzo de 2026.* ---