Skip to main content

 

 

 

 

Template:OutSystems/Documentation_KB/Breadcrumb_New_Layout

 

 

Template:OutSystems/OSLanguageSwitcher

 

 

 

OutSystems

Publishing and testing your app

Once you are comfortable with the workflow you developed, you can test your app by publishing it into your development environment, directly from the Workflow Builder. This means that in the background, OutSystems creates the app that follows all the steps you defined in the Workflow Builder. Once you publish your app, you can test it and change it. Each change requires publishing before you test the new changes.

To publish your app, open it in Workflow Builder, and click on the 1 Publish button on top of the screen.

1-publish button

Note: publishing your app for the first time requires a few minutes.

On the publishing process, Workflow Builder creates sample users, based on the groups of users you defined while designing the workflow, for you to test your app.

Testing with sample users

Once the publishing finishes in the development environment, the Workflow Builder allows you to test your app. Click on the Open in browser button to open your app login page.

open in browser button

The login page contains the sample users for you to test the app from the perspective of each one of them.

logging in using sample users

Note that sample users only exist in your development environment, and are never created in other environments. This means that once your IT team deploys your app to Production, the end users don’t see the sample users in the login page of the app and need to log in using credentials, as in any other app.

App screens

Out of the box, OutSystems generates a Reactive Web app that behaves according to the steps you defined in the Workflow Builder.

Using the example of the expenses approval, the generated app has the following screens:

Request screen - a screen that allows requesters to fulfill and submit expenses using the form you defined in the Workflow Builder.

Request screen example

Requests list - a screen that allows managers, the ones that deal with the requests, to move them forward through the designed process. This screen allows users with the manager role, and belonging to the right user group, to see all the requests that are in the stage that follows. Managers have two view options:

  • My tasks - screen view that shows all the tasks assigned to a specific group of managers (a group to which the logged-in user belongs to).

    My tasks screen

    Within the My Tasks screen view, managers see the tasks organized per the following buckets:

    • To do - shows all requests assigned to a group of users:

      • where none of them picked up the task. In this case, the task is waiting for someone to deal with it.

      • tasks picked up by a manager, where the status changes to Assigned to me. Only the manager that picked up that task can perform actions on it.

    • Done - once a manager takes action on a request, and solves it or forwards it to the following step, the request changes to Done.

    • All - list of all the tasks assigned to the active user group of managers.

  • Requests - screen view that shows all the active requests. A request can have one or more tasks, and so this view can help you to understand the overall progress of a specific request.

    Requests screen

    Within the Requests screen view - displays the requests, organized per the following buckets:

    • Active - lists all requests assigned to a group of active users, meaning that the request didn't follow all the required steps of the workflow yet. This might mean that there are pending tasks from other user groups.

    • Closed - lists all the requests that reached the end of the process. The active user group acted upon one task of that request, at least.

    • All - lists all the requests related to the active user group that are active or closed.

    • Request Detail - a screen where a manager can check all the details of a request. This screen shows:

    • Request Number - unique identifier of the request. This identifier is unique per app. Currently, this is a global incremental number, that you can not reset or change.

    • Requester - the requester username.

    • Request date - date of the request submission.

    • Assigned to - username of the manager that picked up the request.

    • Form - all the field forms submitted by the requester.

    • Notes - area for managers to share notes with each other, to improve communication and collaboration while solving a request.

    • Timeline - section that allows managers to track all the actions that occurred while solving the request.

App actions - My Apps screen

On the My Apps screen, each app has a menu with the options described below.

App actions on the My Apps screen

  • Open in browser - you can “Open in browser” apps that were successfully published, and test their latest published version. If you made any changes and didn't republish the app, those aren't reflected.

  • Convert to edit in Service Studio - you can decide to convert an app to Service Studio if you want to evolve it using advanced Reactive Web development not available in Workflow Builder Studio. This means that from this point on, your app is available for further development in Service Studio like any other OutSystems app. Once you perform this action, you are no longer able to use the Workflow Builder to edit it.

  • Delete - the delete action allows you to delete an app. You need to be the owner of that app to be able to delete it.

To learn about your app lifecycle information, open App lifecycle management.