Skip to main content
Developer Portal
Mendix

New App Checklist

A comprehensive checklist for preparing, configuring, and deploying new Mendix applications within BYU’s infrastructure.

Overview

Before you begin developing or deploying a new Mendix application, several setup steps must be completed to ensure your app is secure, approved, and properly hosted within BYU’s infrastructure.

This New App Checklist walks you through the required preparation steps — from requesting data access and provisioning environments to setting up your app’s custom domain. Completing these steps first ensures your application follows BYU’s data governance, security, and hosting standards and is ready for development, testing, and production deployment.

Tip: Don’t try to perform configuration steps from memory. Always follow the official documentation or your project’s internal runbook. Skipping or reordering steps can lead to subtle configuration errors that take hours to troubleshoot, often requiring you to restart from scratch to get it right.

Step 0: Verify Project Readiness

Before any development begins, confirm the project is truly ready to start.

  • Leadership Approval: Ensure the project has been reviewed and approved through the proper governance channel.
  • Defined MVP: Product Manager must provide a clear Minimum Viable Product (MVP) description with documented acceptance criteria.

  • Data & API Readiness:

    • Confirm all required APIs already exist and expose the exact data your app needs.
    • Validate data sources are authoritative, current, and accessible.
    • Do not begin if data sources or API definitions are incomplete — push back until finalized.

✅ Go/No-Go Gate: Proceed only when all the above are confirmed; otherwise, the project is not ready to begin.

Step 1: Submit a Data Sharing Agreement (DSA)

Before your Mendix app can access BYU data (like user information from the Persons API), you must request a Data Sharing Agreement (DSA) through InfoHub.
Work with your service manager to prepare and submit the DSA — they can help ensure the request includes the correct data fields and aligns with BYU’s data governance requirements.

The DSA ensures that any data your app uses is appropriate, secure, and approved by the data steward responsible for that information.

When submitting your DSA:

  • Request only the minimal data your app needs — typically the basic category fields (e.g., byu_id, net_id, and name fields) so users can sign in, but this can vary from app to app.
  • If your app needs to distinguish between employees, students, and others, include a few fields from employee_summary and student_summary.
  • Provide clear justification for why the data is necessary and describe how it will be securely handled (only accessible to authorized administrators).
  • Link your Mendix service account to the request and include your app’s name and development shop.

Once submitted, your request is reviewed by the data stewards. You’ll receive email updates as it’s processed, and you can modify the same DSA later if additional data is needed.

DSA Provisioning Verification:

  • Even after DSA approval, verify provisioning is complete.
  • Test endpoints in Bruno to confirm that both sandbox and production keys function correctly.

NOTE: All apps that use CAS Single Sign-on must use the PersonsV4 API

Follow the instructions for setting up CAS here.

Step 2: Environment Setup

Before deploying your Mendix app, you’ll need to decide whether to use a free node or a licensed node.

A free node is ideal for testing, demos, or small, low-traffic apps. It’s cost-free but has limitations — the app goes to sleep after an hour of inactivity (taking a minute to restart) and comes with reduced performance and support. A licensed node, on the other hand, is required for production apps with consistent usage, larger data needs, or BYU Single Sign-On (SSO) integration.

Read more about free apps and how to deploy to one here.

If your Mendix app needs to be always available, use BYU Single Sign-On (CAS), or serve a larger audience, you’ll need to deploy it to a licensed node rather than a free one. Licensed nodes provide dedicated servers for Acceptance and Production environments with higher reliability and performance.

To request and set up a licensed node, read the documentation here.

There are two different types of environments on a licensed node: Acceptance and Production.

The Acceptance environment is intended for testing and validation. This is where you deploy your app after development to ensure that new features, bug fixes, and configurations work as expected before going live. You can safely redeploy to this environment as often as needed — it’s meant for internal testing, user feedback, and quality assurance.

The Production environment is your live, end-user environment. This is where your finalized and approved version of the application runs for real users. It should be stable, secure, and only updated after successful testing in Acceptance. Production uses a separate database and application server from Acceptance to keep live data and operations isolated from testing activity.

Each environment has its own application and database servers, both managed by Mendix Cloud. Data does not transfer automatically between environments, but you can export and import data or backups between them when needed. Mendix also performs daily backups for both.

Instructions to deploy to Acceptance.

Instructions to deploy to Production.

Step 3: Request Custom Domain

Use a custom BYU subdomain (e.g., myapp.byu.edu) to give your app a branded, secure URL.
Request the subdomain and SSL certificate (usually through a CSR), upload the certificate to Mendix, link it to your environment, and update your app’s ApplicationRootUrl and CAS settings for Single Sign-On.

Store the certificate files securely for future renewal. It’s also important to coordinate with the Operations team so they are aware of the site and can assist with managing and renewing the domain certificate as needed. Reach out to them via the IT Collaboration - OIT Operations channel on Teams.

Once your custom domain names and site certificates have been obtained and tested, ensure Website Support has updated the metadata for all environments. If Operations pushes back that the certificates don’t need to be live until production, let them know the app will be going to production soon and that the certificates need to be active and configured in Sprintr now.

Instructions to request a custom domain can be found here.

You can configure multiple custom domains on a single Mendix licensed node so users are directed to different landing pages based on the URL they visit.

Read more about configuring multiple domains here.

Step 4: Security, Identity, and Access Configuration

After your environments and custom domain are set up, configure your app’s authentication, encryption, and administrative access to ensure it is secure and production-ready.

App-Specific Accounts Module:

  • Create a module within your Mendix project dedicated to app-specific user accounts and role management.

Encryption Configuration:

  • Configure the Encryption module using secure, randomly generated keys.
  • Store all encryption keys, API keys, SAML secrets, and email credentials in LastPass under the app’s entry. Never store keys in code or documentation.

Initial Hardening in Acceptance:

  • Log in the first time using MxAdmin.
  • Change the default admin password immediately.
  • Check and sync MxModelReflection.
  • Fully configure SAML for Single Sign-On with app-specific user provisioning.

Identity Integration:

  • After configuring SAML, verify that Identity has run the CAS sync script to register your app correctly.

Account Setup:

  • Create sysadmin accounts for development team members only after all previous steps are complete.
  • Create admin or stakeholder accounts in the Acceptance environment for the product manager, testers, and business stakeholders so they can review progress and validate functionality.

Email and Notifications:

  • Request and configure an email server (e.g., AWS SES or SMTP).
  • Add the server settings and credentials to LastPass.
  • Configure the Encryption module first, then the Email module in Mendix.
  • Test sending messages to verify proper configuration.
  • In development and Acceptance, route all notifications to a test inbox and ensure no messages are sent to real users.