Canvas - Requesting and Approving a Custom Application
All production applications used for UWM business must meet applicable UW and UWM policies. This applies to custom-built applications, vendor products, open-source software, and no-cost tools. Development method, price, and hosting location do not exempt an application from review or compliance.
This article explains the request and approval process, followed by the requirements a custom Canvas application must meet. The Center for Advancing Student Learning (CASL) reviews the business need, looks for approved alternatives, and coordinates any necessary external-tool request with UW Administration.
Request and approval process
Contact CASL
Use the CASL Contact Us page to explain your technical need, the benefit to UWM, and your proposed scope, hosting, and data safeguards. The application requirements below describe the information needed for review.
Already contacted CASL for help? You do not need to submit another request. A CASL team member will follow up with you to ask any outstanding questions and gather any additional information needed.
Discuss the application and alternatives
The CASL discussion includes a review of the application itself, its business need, technical scope, hosting, and proposed safeguards. Be prepared to demonstrate the application or walk through its proposed behavior, architecture, data flows, and LTI implementation. CASL will make every effort to meet the need through existing Canvas functionality, an approved external tool, or a different supported workflow before pursuing a custom application. If an alternative meets the need, CASL will provide that option.
During this discussion, CASL will collect the application documentation and inventory of API calls described under Application requirements.
CASL submits an External Tool Request when needed
If a custom application is the only way to meet the business need and the request is sufficiently defined, CASL will file an External Tool Request with UW Administration. UW Administration refers to this process as an external application integration request.
The UW DLE External Application Requests page describes the vetting process and lists integration approval statuses. The UW DLE KnowledgeBase provides systemwide documentation, including the DLE change-request process. CASL will coordinate submission and follow-up for the UWM request. Submission does not guarantee approval or an implementation date.
Complete institutional review and required sign-offs
UW Administration reviews the external-tool request. CASL coordinates follow-up questions and the applicable security, accessibility, privacy, procurement, and policy reviews with the requester and responsible offices.
If UW Administration requires an Acceptance of Risk, CASL will seek sign-off from UWM's Chief Information Officer (CIO) and/or the Provost, as appropriate. CASL will coordinate any additional review, documentation, or authorization required by the applicable UW risk-management procedures. The requester cannot accept institutional risk on UWM's behalf.
Implement after approval
If UW Administration approves the application, with or without an Acceptance of Risk as required, CASL will work with the requester to implement the approved integration. Any required risk sign-offs, procurement reviews, and other approval conditions must be completed before deployment or use with university data.
Implementation planning will establish the approved configuration and permissions, testing and accessibility checks, hosting and maintenance responsibilities, support contacts, and deployment schedule. Implement the approved LTI 1.3 integration and OAuth 2.0 configuration before production use.
Application requirements
These requirements guide preparation, review, and operation of the application. A request must meet the scope and hosting prerequisites before it can proceed to external-tool review.
Define the scope, hosting, ownership, and safeguards
Provide the following information to CASL:
- Technical need and defined scope: the problem to solve, required functions, intended users, affected courses or units, and what the application will and will not do. Describe the Canvas information it needs to read or change and the proposed integration method, if known.
- Benefit to UWM: how the application supports your teaching, learning, research, administrative work, or other business with UWM; who benefits; and why existing capabilities do not meet the need.
- Hosting: where the application and its data will run and be stored, the hosting provider or institutional service, the responsible technical owner, and how the hosting arrangement will be maintained and funded.
- Data protection: what information the application collects, why it is needed, who can access it, where it is stored or sent, how it is protected, and how long it is retained. Describe authentication, authorization, credential storage, encryption, security updates, monitoring, backups, incident response, and eventual data disposal as applicable.
- Ownership and operation: the requesting unit, business owner, developer or vendor, maintenance and support contacts, accessibility approach, anticipated costs, and desired implementation date.
A request will not proceed without a defined scope and an identified hosting arrangement. An idea for an application, by itself, is not sufficient for external-tool review. Hosting must also satisfy the applicable security and data-protection requirements; having hosting does not establish that it is approved.
Use LTI 1.3 with OAuth 2.0
All production applications connected to Canvas must use LTI 1.3 with OAuth 2.0. No exceptions are permitted. This requirement applies to custom-built and vendor-provided applications. Personal access tokens and legacy LTI integrations are not acceptable substitutes.
The proposed integration must document its LTI 1.3 configuration, OAuth authorization, requested permissions, and management of application credentials. See Instructure's OAuth 2.0 guidance for LTI Advantage services and OAuth 2.0 endpoint documentation for implementation requirements.
Provide the API calls used by the LTI implementation
The requester must provide an inventory of all API calls the application makes as part of its LTI implementation. CASL will collect and review this inventory with the application documentation. For each call, identify:
- The API or LTI service, HTTP method, and endpoint or route.
- The business purpose and the action the call performs.
- The OAuth scopes and permissions required, including the access needed by the application.
- The information sent and returned, including any student or course data, and any records created, changed, or deleted.
- What triggers the call and its expected frequency or volume.
Provide sanitized request/response examples or test traces showing the calls actually made by the implementation when available. Do not include access tokens, client secrets, private keys, or identifiable student information. Keep the inventory aligned with the application submitted for review; disclose additional or changed calls before implementing them so CASL can determine whether further review is required.
Meet policy, procurement, and risk conditions
Every production application must meet all applicable UW and UWM policies, associated standards and procedures, legal obligations, and Canvas integration requirements. The same compliance obligations apply to a custom application and an existing vendor product. The review considers the application, its hosting environment, its access to Canvas, and the entire lifecycle of the data it collects. The policy references below identify the principal requirements; reviewers will determine any additional requirements based on the application's scope, data, and hosting.
Risk acceptance must follow SYS 1039 and its risk-acceptance procedure, SYS 1039.B. An Acceptance of Risk documents a specific, authorized decision about identified risk; it is not blanket permission to disregard policy or law. Any conditions, expiration dates, and recurring reviews remain part of the approval. An Acceptance of Risk cannot waive the LTI 1.3 and OAuth 2.0 requirement.
External-tool approval does not replace procurement or contract review. Complete the applicable UWM IT procurement process, including any required security, accessibility, privacy, and agreement reviews. UWM's project-purchase review can apply even when a product has no cost. UW Administration's DLE approval does not grant purchasing or contracting authority.
Maintain the approved scope and safeguards
The application must continue to operate within its approved scope and safeguards. Contact CASL before materially changing its functions, hosting, data access, or intended audience so the need for renewed review can be determined.
Policies, standards, and required practices
Use the official policy text and its linked standards and procedures when preparing the request. Applicability depends on the application and the data involved; approval conditions may impose additional controls.
Applications must also satisfy applicable Instructure Canvas API Policy and Canvas LTI Advantage authentication requirements. Additional obligations may apply to research, health, payment, or other specially protected data; identify these uses in the initial request so the appropriate reviewers can be involved.
For the current policy collections, consult UW Policies, the UWM Policy Library, and UWM IT Policies. Contact CASL with questions about starting or advancing a request.