Skip to main content

Open a Studio App from a Model-Driven App

Goal​

Put a screen you have drawn into an app, so people can actually open it.

Why this step exists​

The Platform Shell lists apps, not components. A screen that is not in an app is a screen nobody can reach — the same as a table or a dashboard. Placing it is one action, and it is the last one between a drawing and something a user opens.

Prerequisites​

  • A screen you have drawn and saved — see Draw a Studio app.
  • An app, or permission to create one.

Steps​

  1. Open your solution and choose Apps.

  2. Create an app, or select one and press Edit.

  3. In a navigation group, press the screen button (the window glyph) beside the table, dashboard and report buttons. Choose your screen.

    No screen button? There are no screens in this environment yet. Draw one first.

  4. Optionally give it a different label for this app. The name in the rail is your app's language for the thing, not the screen's own — a screen called "Onboarding" can read "Start here" here.

  5. Set the home page to the screen if you want the app to open on it.

  6. Press Save, then open the app from the Shell.

Making it the first thing people see​

A drawn screen is a natural home page: a landing page with a heading, a short explanation and the three things somebody should do first is a better first impression than a grid of rows.

The home page has to be one of the app's own navigation destinations, so place the screen first and then choose it as home. A home page nobody can navigate back to is a screen with no way in once you have clicked away from it.

Several screens inside one navigation entry​

The rail names the app, not one of its screens: opening the entry opens the app at its start screen, and the buttons you drew move between the rest. So an app with six screens is one row in the rail rather than six.

That is deliberate — the screens of an app are pages of one thing, and the rail is for the app's top-level destinations. If two drawn screens genuinely belong side by side in the rail, they are two apps.

Moving inside the app is an ordinary move within the model-driven app: the address changes, the browser's Back returns to the previous screen, and if a command sent the user here, the arrow back to where they came from is still there when they have moved a screen or two.

Moving it to another environment​

A screen travels in its solution, like every other component. Export the solution from the environment you built it in and import it into the next one; the screen, the app that names it and the drawing behind it all arrive together. There is no separate export.

Import the app's solution and the screen's, if they are in different ones — an app whose navigation names a screen that is not there will not save.

Troubleshooting​

  • The screen button is not shown. — no screens exist in this environment. Draw one first.
  • Saving the app says the screen is not defined in this environment. — the screen is in a solution that has not been imported here. Import it, then save the app again.
  • The rail shows the logical name instead of the display name. — the screen was not found, for the same reason as above.
  • The screen opens empty. — nothing in the drawing is tagged as the screen, or the screen frame has nothing inside it. Open the designer and press Preview: you will see the same thing, and can fix it there.
  • Everything is greyed and says the screen could not be opened. — your role has no grant on that screen. Opening a screen is a permission like any other; ask whoever manages your security roles.