This is an accordion element with a series of buttons that open and close related content panels.
What is a low code tool and what can they do for me?
Low code tools are visual application development tools where developers and software development teams can build applications of medium to lower complexity. This can save time, boost productivity, reduce costs, and increase flexibility for certain applications.
For more information about what types of features and development are possible on the low code Betty Blocks platform check out Is Low Code Solutions right for me?.
What is a no code tool and what can they do for me?
No code tools are visual application development tools intended to empower campus administrators (non-IT, business-centric staff) to build single form applications with simple or divergent workflows. This can save time, boost productivity, reduce costs, and increase flexibility for certain business processes.
For more information about what types of features and development are possible on the no code Kuali Build platform check out Is Low Code Solutions right for me?.
Who is the intended audience of low code and no code tools?
There are 2 main audiences for these tools: Those that will automate workflows and create applications, and those constituents and partners that will benefit from using those workflows and applications.
Will we be required to move existing applications to the low code or no code tool?
No. Our intent is to provide tools that folks want to use. This effort will not remove tools already in use.
Must I use the selected low code or no code tool? Can I use a different tool? Will my tool go away?
You do not have to use the selected low code or no code tool. No tools will be removed as part of this initiative. We encourage using campus provided tools (e.g. Betty Blocks, Kuali Build, Qualtrics, Google Forms, etc.) that best fits your need to better assure your applications and data are safe, secure, compliant with policy, and can leverage other campus IT and data infrastructure. Using tools not provided by campus comes with risks where the benefits need to be compared to the risks and potential impacts.
Who will pay for the tool licenses?
The service will be provided as a fully subsidized service from the Division of Information Technology (DoIT).
How are you soliciting input and getting buy-in?
Information about how stakeholders across campus were involved in the selection of the low code tool can be found in the Low code tool selection process document.
Beyond selecting the low code tool, a service advisory board has been formed with representatives from across campus to help ensure the success and utility of this new service campus wide. Additionally, there are several other ways that folks on campus can get involved including our Microsoft Teams channel and in the future our communities of practice.
What will campus support look like for the no code and low code tools?
The Low Code Solutions team will work with the vendors as they maintain the cloud-based platforms. The Low Code Solutions team will use the usual DoIT Outage routes to inform the business and technical leads of outages; see the Conditions of Use.
The Low Code Solutions team will provide integration services and SSO/authentication services for both Kuali Build and Betty Blocks platforms to and from other campus APIs and systems. The application manager/developer/app admin are required to get the appropriate approval to pull in or send data to these systems.
The Low Code Solutions team will provide support and guidance for Kuali Build application administrators, but given the intuitiveness of the platform, it is assumed that those requesting the applications will be able to build them.
The Low Code Solutions team will provide application development services for applications from areas on campus without access to a local low code developer, highly complex applications, and campus-wide or system-wide applications built on the Betty Blocks platform. For developers, the Low Code Solutions team will provide training, support and guidance for Betty Blocks application developers. Note that all applications must first be approved by the Low Code Solutions service team.
How will I get training on the selected tool?
An overview of the training opportunities and how to get started can be found on our training page. Additionally, how-to documentation related to the Low Code Solutions service for the Betty Blocks platform and Kuali Build platform are available in the Low Code Solutions KnowledgeBase.
Will the low code and/or no code tool support sensitive or restricted data (e.g. Student/FERPA, PHI/HIPAA)?
For information about what types of data the low code tool supports please see the terms of service and policies.
How soon can I expect to hear back after I've submitted a request to the Low Code Solutions team?
The service team will help answer questions and requests that come through the customer support form or lcs-support@doit.wisc.edu
Hours of operation: M-F, 8:00 AM – 4:00 PM (excluding holidays)
During these hours urgent requests will be responded to within 1-4 hours and standard requests will be addressed within 2-3 business days with the following caveats:
- Application creation with SSO capabilities may take up to 2 weeks based on team availability and dependencies.
- SSL certificates may take up to 2 weeks. Note that most support for the Betty Blocks platform itself is provided from their Netherlands headquarters.
How will the data that is pulled from campus APIs be governed?
Application managers/developers will need to go through the data approval process according to the API team’s process. After approval, the application manager/developer would obtain the credentials from the API team to pull data from the API for that specific application. See Data usage approval for UW-Madison, UW System and other data sources for more information.
Any reusable block API will not have the credentials saved with that block. When the block is pulled into an application, the approval process mentioned earlier will be required prior to credentials being provided by the appropriate API team.