3 Create Your Application Extension

The base application developer (at Oracle) who created your Oracle Cloud Application made certain elements of the app eligible for customization. Those elements can include dynamic components (tables, forms), as well as certain variables, constants, and events. Those items are clearly indicated in the VB Studio UI, so you know what you can extend and what you can’t.

How Do I Create an Application Extension?

There are two easy ways to create a new application extension, or to edit an existing one:

  • Starting in Oracle Cloud Applications, click the Edit Pages in Visual Builder. VB Studio opens the workspace associated with the sandbox you’re using (if you are using one), or creates a workspace for you if you don’t have one. Regardless, you should see your page in the Designer, with the extensible areas outlined in blue, like this:
    Description of designer-page-layout.png follows
    Description of the illustration designer-page-layout.png

    (If you’re new to application extensions, you may want to watch the video to help you get oriented.) When you select an extensible area—either by clicking a region in the middle section, by selecting a component in the Property Inspector on the right, or by selecting a dynamic UI in the left Navigator area—you’ll be placed in the dynamic layout editor, where the real work begins. If there are configurable variables or events exposed in the base application, you'll also see the variables and/or events tabs for viewing the configurable variables and events related to the page.

  • After logging in to Visual Builder Studio, you select the project you want to work in, then click Designer in the left navigator to either select your workspace or create a new one. You should then see something like this:



    At this point you can select an app extension page or a dynamic UI in the left navigator, after which you’ll be placed in the dynamic layout editor. More on that later.

Understand the Designer

Let’s take a look at the Designer so you can understand what it offers. In the header, you have:

Element Description
Project The name of the current project.
Workspace The name of the current workspace. You can click the workspace name to switch to a different workpace in the project.
Git repository The name of the Git repository for the base app, and the name of the repository branch currently associated with your workspace.
Sandbox The name of the current sandbox used in the workspace, if any.
Undo Undo your most recent change.
Redo Redo a change after clicking Undo.
Preview Open a new tab in your browser to preview the current page.
Go to File Search the Git repository by file name.
Menu Open a menu containing the Share, Import and Export actions. You can also open the Settings editor from the menu.

You use the Navigator on the left of the Designer to navigate the artifacts in your app extension. The Application Extensions area in the Navigator contains two types of artifacts:

  • Under Dynamic UIs, the dynamic UI artifacts for each business object resource. Both Accounts and Contacts are examples of business objects used by the Subscription Accounts base Oracle Cloud Application, and their corresponding dynamic UI artifacts are listed in the navigator. When you select a dynamic UI artifact corresponding to a business object, it opens in the dynamic layout editor where you can edit the dynamic layouts that use that business object.
  • Beneath the business objects, the extendable page artifacts are grouped into folders under their flow names. When you select a page, like account-relationship-start, it opens in the Page Designer on the right, where you can click the dynamic component you want to work on to open it in the dynamic layout editor. When a page is open in the Page Designer, the extendable components in the page and configurable variables and events related to the page are listed in the Property Inspector on the right. You can open the editors for dynamic layouts, variables and events from the Property Inspector.

By default, the Application Extensions pane only displays artifacts that you can extend, but you can change that so that all the artifacts are shown, or to show only those which have already been extended. You may see some artifacts that you cannot open or modify because you don’t have permission, or because it does not contain anything that can be extended.

The Designer also lets you work in source code if you prefer. Click the Source View icon to enter this mode:



In the footer you have:

Element Description
Audits Scan the code in your app extension for places containing errors, warnings, info and to-dos. Your code is scanned when you open the Audits pane.
Find in Files Search the code in your app extension for a text string.
Logs View the log of messages written by custom code in your app extension.
Tests View a list of all action chain tests defined in the app extension, and the status of each test.

Customize Dynamic Components

A dynamic component is a UI component, such as a form or a table, that does not render a static set of fields. Instead, it determines at runtime what fields to render, and how they are displayed, based upon the display logic specified in its rule set.

When you want to modify how a dynamic component looks and behaves, you configure its rule set. By default, a dynamic component in your cloud application renders the fields defined out of the box in the rule set's built-in default layout. You can change what's displayed in the component by configuring the rule set with your own custom layouts and display logic.

You have two main objectives when customizing a dynamic component: one, to configure the fields the way you want them in a layout, and two, to define the display logic that determines which layout is applied to the component at runtime, based on the viewer’s current circumstances. In most cases you define the logic first, then configure the layouts that will be used in your logic. You can edit the layout to define the fields that appear and how they are ordered and grouped.

Determine What's Displayed at Runtime

You control what’s displayed at runtime on a page through the use of display logic, which you configure using the rule set editor. Suppose you want to configure a dynamic table so that certain columns are hidden and others are added when the user viewing the page is in Canada. You’d then create a rule that checks for the user’s location and, if the user is indeed in Canada, apply the layout you’ve created that contains the desired columns. All non-Canadians would see the page with the default layout applied.

You can have more than one rule for a given component, and the order in which they appear in the rule set editor is important. At runtime, Visual Builder Studio runs through the rules from top to bottom. When it finds a rule where the condition is met—in this case, the user is in California—the associated layout is applied to the page and no other rules are tested. Keep this in mind as you’re working with the rule set editor.

When you select a business object in the Application Extensions pane, you’ll see a separate tab for each dynamic component that uses that business object. For example, suppose there’s both a dynamic table and a dynamic form bound to the Contacts business object. When you open Contacts, for each component you’ll see one tab containing the component's rule set, allowing you to control the data that’s displayed in each independently.

To set the display logic for a component:

  1. After you have selected a dynamic component to extend, click Open Rule Set Editor in the Property Inspector.

    The Property Inspector also tells you the REST endpoint of the business object associated with this component (contacts), as well as the name of the dynamic component's rule set (ContactsListUsage).



    The rule set contains one or more built-in default rules governing the display for the base app and it cannot be modified, but you can create new rules or make copies of a built-in rule to use as the basis for your own rules.

  2. In the rule set editor, click Duplicate Rule and give it a name, preferably something meaningful. For example, to create a layout that displays only when the user is in Canada, you might call the rule inCanada.


    If you want to also create a copy of the layout to use as a starting point, make sure that check box is selected in the Duplicate Rule dialog box.

  3. Click Click to add condtion, select an Attribute and Operator from the dropdown lists, and enter a Value to create a condition. Click Done.

    You can add more conditions and group conditions if you want to use more attributes to make the rule more precise. For example, you may want to use a layout that displays an extra column if the user is in Canada AND has the manager role. You would then create a rule with two conditions, and select Match All to require that both conditions are true.



    If you select Match Any, then the rule would be true if any of the condtions in the rule are true.

  4. In the return field, select the layout you want to apply when the rule is true.

    If you created a copy of a layout when you created the rule, it is selected by default in the return field. You can use the same layout with multiple rules.

  5. Click Rule to add another rule.
  6. Use the Move Up and Move Down buttons to make sure you have the rules in the order you want them evaluated.


    The order and precision of your rules is important. The rules are evaluated from the top down, so the first rule where all the conditions are met will determine the layout that is used.

Create a Dynamic Layout

A layout defines the fields that are displayed in a dynamic component at runtime. You can create multiple layouts for a single component, and the layout that is used is determined by the rules in the rule set. For example, you might have one layout that shows certain fields in a dynamic form when the user is a manager, and another layout for non-managers. At runtime, the rules associated with the component are evaluated in the order they appear to see if the conditions set in that rule are met. If the condition is true—say, the current user is a manager—then the layout you selected for that rule is applied to the component and the user will see the fields he needs in the form. Non-managers will see a different layout.

To create a new layout:

  1. Open the rule set you want to edit.
  2. Click New in the Layouts column of the rule set and type a name for the new layout, or click Duplicate in an existing layout to use it as a starting point.


    Each rule set contains a default layout that is seeded for you. You can't edit the default layout, but you can duplicate it and use it as the basis for a new layout. The default layout is always used in the last rule of the display logic tree.

  3. Click the new layout to open the field selector.
  4. In the Fields column, select the checkbox for the fields you want to add to the layout, or drag fields from the Fields column directly onto the drop target in the component column.
  5. Edit a field's properties, for example, if it is read-only, by clicking the field in the component column and editing the properties in the Property Inspector.
  6. Use the Property Inspector to set properties and create expressions that control the behavior of each field in the component, such as if it is a read-only field, as well as some display properties. For example, the default value for the Show Field property is Always, but you can change that so a certain field is displayed only when certain conditions are met.
  7. Change the order that fields are displayed in the component by dragging fields into a different position within the component column.
  8. Click Done.
After a layout is created you can include it in a display logic rule, as described in Determine What's Displayed at Runtime. You can use the same layout in multiple rules.

Define Conditions in a Dynamic Layout

You use expressions to define conditions for rule sets and the display properties for fields and components in dynamic layouts.

Visual Builder has a condition builder to help you create the conditions in your dynamic layout by allowing you to quickly select the Attributes, Operators and Values in the expression, and to easily create complex expressions. For example, you might create a rule in a rule set that looks like this:



This rule has two conditions, and if both are met then the isEmailLayout layout is used. The conditions you see in the condition builder represent an expression in the dynamic component's layout-x.json file. If you open the rule set in Code view you can see the expression, which for this rule will look similar to this:

"isEmailRule": {
      "description": "My email rule",
      "type": "crmRestApiLatestAccountsDescribe",
      "expression": "{{ $context.record.NoteTxt.includes('available') && $context.user.email.includes('example.com') ? 'isEmailLayout' : null }}"
    }

When you create a conditon you select an Attribute in the condition builder's dropdown list. You can select fields retrieved from the business object (for example, record.NoteTxt) or variables that are determined by the app extension's context (for example, user.useremail). In addition to business object fields, two kinds of app extension context ($context) variables are available in Visual Builder: user and responsive. Values for the user variables are determined by the current user, and the responsive variables are determined by the current device used by the app extension.

The following user variables are added by Visual Builder to the $context available in layout expressions:

  • $context.user.userId
  • $context.user.longId
  • $context.user.fullName
  • $context.user.email
  • $context.user.isAdmin
  • $context.user.isAuthenticated

The following responsive variables are added by Visual Builder to the $context available in layout expressions:

  • $context.responsive.smUp
  • $context.responsive.mdUp
  • $context.responsive.lgUp
  • $context.responsive.xlUp
  • $context.responsive.smOnly
  • $context.responsive.mdOnly
  • $context.responsive.lgOnly

The responsive variables are wrapped with an accessor, so parentheses are not used in expressions (for example, $context.responsive.mdUp === true ?).

Add and Group Fields in Form Layouts

When creating a form layout in the dynamic layout editor, you can create groups of fields so that the fields are displayed together in a layout, and so you can treat them as a single entity. For example, you can create an address group that contains the fields (for example, name, address, city, state, country and post code) that you want to be displayed as a group in your layout. You can then apply conditions to the group that control when the group is displayed. A group also makes it easy to add several fields to a different layout in one step, rather than adding them individually.

You can define properties for a group (for example, to add a group label) and to individual fields in a group (for example, to specify column spans for fields to create complex form layouts.)

To create a group of fields in a form layout:

  1. Open a form layout containing fields you want to group together, or create a new form layout and add the fields you want the group to contain.

    You can use buttons in the toolbar to duplicate the current layout (Duplicate layout button), to copy selected fields in your current layout to another layout (Copy selected fields to another layout button), and to copy fields from another layout into the current one (Copy fields from another layout).

  2. In the layout diagram, select the fields that you want to group together.

    To select multiple fields, hold the CMD key (on macOS) or Ctrl key (on Windows) when you click a field.

  3. Click Group Fields in the Property Inspector, or Group selected fields (Group selected fields) in the toolbar.

    The selected fields are grouped under a new folder in the layout diagram.



  4. Type a name for the new group by naming the folder in the layout diagram. Click Save to save the group name.
  5. In the Property Inspector, set the properties for the group and fields in the group, for example, conditions that determine when the group is displayed in a layout. The default setting is to always display the group.

After a group is created, you can still use the handles for fields to drag them into and out of a group.

Design Your Pages

When you select a page artifact in the Navigator it opens in the Page Designer, where you can see how the page looks when different layouts are used, and edit the properties of page components. When nothing is selected on the page, the Property Inspector on the right lists the page's dynamic components, as well as other editable items such as constants and variables used in the page. Editable components are outlined on the page, and when you select a component on the page or in the Property Inspector its properties are listed in the Property Inspector. You can edit some component properties directly in the Property Inspector, but for others like dynamic components you'll need to click the link in the Property Inspector to open a dedicated editor.

In this example where the Leads Table component is selected in the page, the Property Inspector shows that the component uses the simpleTable rule set and that the active layout is determined by the display logic.



Preview Different Dynamic Layouts

When you want to see how different dynamic layouts look in your page, the Layout Preview in the Property Inspector lets you switch between the different component layouts in your rule set. The display logic rules in a component's rule set apply when you are looking at a page in the Page Designer. For example, if you created a layout that only managers can see, you won't see it in the Page Designer because you don't meet the conditions in the rule. You use the Layout Preview dropdown list in the Property Inspector to override the display logic and select one of the component's layouts.

To preview a dynamic component layout:

  1. When the page is open in the Page Designer, select the dynamic component you want to check on the page.

    When a dynamic component is selected, the Layout Preview dropdown list contains the layouts defined in the component's rule set.

  2. Select a layout in the Layout Preview dropdown list.

    The Layout Preview displays the name of the active layout.



    In this image, the Property Inspector shows that the Page Designer shows the component's CommercialOrgTableLayout. Some display conditions that you have added to fields might be ignored, however. You can click Configure Layout to open the layout in the dynamic layout editor.

  3. Click Reset to return to the default "Resolved by display logic" option.

Store Property Values with Variables and Constants

Variables and constants store values that are used to define how pages are displayed, and may also be used for page actions. For example, the color of a page heading can be stored in a variable, so when creating your app extension you can edit the variable to set the color. The base application developer or a team member might have already specified some variables and constants that you can extend, but you might also want to add others.

Variables and constants are both used to store values and might be read-only or writeable by the app extension, but there are some differences.

  • Variables are typically used to store values used within a page's UI or an action chain, for example, an input text or a total. Variables are commonly used to store values when performing an action in the page like adding items to an order, but they can also be used to store property values like a text color or font size.
  • Constants are typically defined in the base app, and their values don't change after they are set by the app extension. For example, the base app might define a heading that uses the constant itemDetailHeading for setting the heading text. Your app extension can write a value to the constant, and that value will be used to set the heading text every time itemDetailHeading is used in the app extension.

    Constants that can be extended by your app extension are listed in the Property Inspector. Extensions that supply the same value for a constant will override previous extensions that are lower down in the dependency chain.

The Page Designer has a Variables editor where you can view, create and edit variables and constants. Special characters (period, colon, dash and space) can be used in the field names for variables by enclosing it in bracket notation. For example, an object variable that contains a field called 'child.field' will need to be referenced as $variables.objVar['child.field'].

Change Constant Values in the Property Inspector

If the base app or your app extension use constants that can be extended by your app extension, you can see and modify the values stored in them in the Property Inspector.

For example, the base app might use a constant to store a font size or text for a heading in your app extension. The base app will specify a default value, but it might allow your app extension to overwrite the default value used for the heading and set your own font size or text. Your value will be used instead of the default when your app extension is published.

If you open the Variables editor in the Page Designer you can see a list of all the constants used in your app extension, and if your app extension is allowed to overwrite the constant's default value. Constants are badged when they are defined in the base application.

To overwrite the default value of a constant:

  1. Open your extension page in the Page Designer.
  2. In the page's Property Inspector, locate the constants used in the page in the Constants section and click the component's name.


    The Constants section displays the name of each constant and the component it's used for. For each constant, you can click the component name to open its properties in the Property Inspector. In this image of the Property Inspector you can see that two constants (detailHeading and headerFontSize) are used in the page. The constant detailHeading is used to store a property of the Heading component.

    Alternatively, if you know a component uses an editable constant you can click the component on the page to open its properties in the Property Inspector.

  3. In the Property Inspector, type the value in the text field.


    The text field contains the constant's default value. A component might use more than one constant to define its properties.

Edit Variables and Constants in the Variables Editor

To edit a variable or constant in the editor:
  1. Select the component in the Page Designer.
    The Property Inspector lists the attributes of the selected component that can be customized using variables or constants.
  2. Select the attribute defined by a variable or constant.
  3. Click Show in Variables to open the Variables editor.

In the Variables editor, you can edit the properties of variables that are defined in the app extension. You can also right-click a variable in the list and choose Go to Code in the menu to open the JSON file where the variable is defined.

Define the Behavior of Components with Action Chains

The behavior of the components in your app extension are determined by action chains, a sequence of actions triggered directly by another action chain or by an event listener. An action chain might be a short sequence of a few actions, but it could contain many actions as well as logic for determining what happens in the sequence. For example, when you click a button on a page, what happens next is determined by an action chain that might contain actions such as assigning data to a variable, sending data to a database and navigating to another page.

Action chains can be defined in your app extension and in the base app. You can't edit action chains defined in the base app, but you can create and edit action chains in your app extension in the Action Chain editor. For details on how to create and use action chains, see Work with Actions and Action Chains in Building Web and Mobile Applications with Visual Builder Studio.

Though you can't edit the action chains defined in the base app, the base app might define custom events and event listeners that you can use to trigger them from action chains in your app extension. The base app might also define events that you can use to start action chains in your app extension.

Use Events and Event Listeners to Start Action Chains

When an event occurs in a page, if an event listener is "listening" for the event it can start one or more action chains when the event occurs.

There are various types of pre-defined events that you can apply to a component, and the type of event is usually determined by the type of component. For example, ojAction is a type of component event triggered when a button is clicked, so you would typically apply it to a button component. An event listener listens to that button for the ojAction event, and starts an action chain (or multiple action chains) when the event occurs. Each component event will usually have a corresponding component event listener. You can add an action chain to more than one event listener, so you might have a SaveData action chain that can be started by two different event listeners listening for two different events. For more, see Start an Action Chain with an Event in Building Web and Mobile Applications with Visual Builder Studio.

In addition to using the pre-defined component events, you can define your own custom events. Unlike component events, custom events are not applied to a component but are triggered by the Fire Custom Event action in an action chain. There are a few types of custom events, and typically you would use one when you want to trigger some notification, for example, to display a popup window with a message, or when you want to transform some data. Like component events, you use custom event listeners to listen for custom events.

The base app might define some custom events that are designated as Triggerable and/or Listenable, indicating that you can use them to start action chains. In the Events editor you can see which custom events are defined in the base app, and if they are listenable or triggerable. You can also see the event's behavior type that defines how the event listeners will be called.

Description of designer-custom-events.png follows
Description of the illustration designer-custom-events.png

You can't change the designation of custom events defined in the base app, but you can use them to start action chains defined in the base app or in your app extension.

Event Designation Description
Triggerable

Triggerable events are used to start action chains defined in the base app. If an event is designated as Triggerable, you can call the event from an action chain in your app extension using the Fire Custom Event action.

For example, the base app might define an action chain that opens a popup window, and define a custom event (for example, openPopup) and event listener to trigger the action chain. If the custom event is Triggerable, you can call the event from your app extension. So if you want to use that action chain when a user selects a specific option, you can add the Fire Custom Event action to the action chain in your app extension that is triggered when the option is selected. In the Actions editor, you would choose the openPopup event when you configure the Fire Custom Event action.

Listenable

Listenable events are used to start action chains defined in your app extension. If an event in the base app is designated as Listenable, you can add an event listener to your app extension and configure it to trigger your action chain when the listenable event occurs.

For example, you can use listenable events to:

  • execute an app extension action chain asynchronously or synchronously

  • cancel an event in the app extension action chain

  • transform a return value that is passed between the layers of event listeners

Event Behavior Types for Calling Event Listeners

Each event has a Behavior type that defines how the event listeners will be called in relation to each other, whether the result for the listener is available, and what form the result would take. This is used for listeners defined in base apps as well as extensions, and is not specific to events defined in the "interface". The behavior does not define the order in which the listeners are called.

The behavior determines whether the listener is called serially or in parallel, that is, whether the Action that raised the event waits for a listener resolution, and what the "result" of the listener invocation looks like. So in this case, "serially" means:

  • all event listener chains for a single event listener (in a container) are called sequentially, in a declared order. This means that a listener action chain is not called until any previous actions chain has finished (and resolved, it returns a Promise)
  • the event listeners for the next container's listeners are not called until the listener action chains for any previous container's event listeners have finished (and resolved, it returns a Promise)

An event will have one of the following behavior types.

Type Description
Notify

Parallel - The event is triggered but the application does not wait for the extension to process it.

Chain results are not available to the Action (or helper) that fired the event (because the listeners are called without waiting). This is the default behavior.

NotifyAndWait

Serial - Each action chain listener must complete (and resolve any returned Promise, if any), before another event listener action chain is called.

Chain results are not available to the Action (or helper) that fired the event.

CheckForCancel

Serial - Each action chain listener must complete (and resolve any returned Promise, if any), before another event listener action chain is called.

If any of the listeners Chains returns a "success" (*?!? or new result type?) with a payload of { "stopPropagation": true }, the application will stop calling event listeners. When calling listeners defined in both extensions and the base application, the listeners in the "closest" extension are called first. In other words, extensions of extensions are called before extensions of the base. This allows higher-precedent extensions to cancel listening, before the lower-precedent extensions (or base) receive the event.

Chain results are not available to the Action (or helper) that fired the event.

Transform

Serial - Each action chain listener must complete (and resolve any returned Promise, if any), before another event listener action chain is called.

The "eventListener" will have access to a new context variable, $previous, which is a peer of "$event". This will be the result of the previous listener invocation's chain result, or undefined for the first invocation. The "eventListener" for a "transform" event can also have a "returnType" declaration, analogous to the "payloadType", but corresponding to the $previous value. If the event declaration has a "returnType", $previous should match the type, otherwise, it will be coerced to the type.

When calling listeners defined in both extensions and the base app, the listeners in the "closest" extension are called first. In other words, extensions of extensions are called before extensions of the base app. (This convention matches the order of the "cancel" behavior). The final result, "returnType", when all the listeners have been called, will be returned as the result of the fireCustomEventAction that initially raised the event.

If the application wishes to use the "transform" mode, the convention it should follow is:

  • For any listeners for an event with a "transform" behavior that reference more than one Chain, the Chains are called in array order.
  • All listeners for an event with a "transform" behavior should pass the $previous as an argument to their Chain (and this will typically be wired by the design-time).
  • All listeners for an event with a "transform" behavior should define a "returnType", which matches the "returnType" for the event declaration.
  • The Chain variable argument that corresponds to $previous should have an argument that matches the "returnType" of the event, and the Chain should also have a "returnType" that matches the listeners "returnType" (note that "payloadType" and "returnType" cannot currently reference defined Types, because of restrictions on types used in the "interface" section).
  • The Chain should have a "returnType" defined, that matches the "returnType" of the event (this is currently not used by runtime.).

The parameters for the listener, and the inputs for the Chain, to provide $previous can be added by the design-time, just as it provides the $event.

Here is an example:

"events": {
   "myTransformEvent": {
      "payloadType": {
         "foo": "string"
      },
      "returnType": {
         "bar": "number",
      },
     "behavior": "transform"
   }
}
"eventListeners": {
  "myTransformEvent": {
     "chains": [{
       "chainId": "myTransformChain",
       "parameters": {
          "myPrevious": "{{ $previous }}",
          "myEvent": "{{ $event }}
       }
     }]
},
"chains": {
   "myTransformChain" : {
     "variables": {
        "myEvent": {
          "type": {
             "foo": "string"
          }
        },
        "myPrevious": {
           "type": " {
             "bar": "string"
           }
        }
     },
     "actions": { ... },
     "returnType": {
        "bar": "string"
      }
   },
   "fireIt": {
      "root": "fire",
      "actions": {
         "fire": {
            "module": "vb/action/builtin/fireCustomEventAction",
            "parameters": {
              "name": "{{ $chain.variables.name }}",
              "payload": "who cares?"
            },
            "outcomes": {
              "success": "getResult",
            }
         },
         "getResult": {
            "module": "....",
            "parameters": {
              "name": "{{ $chain.results.fire.result }}",
            }
         }
      }
   }
}

Preview Your Application

Before committing your changes to the branch, you can use the application preview to see how your pages look and behave in a browser.

The application preview shows you how the pages are displayed based on the changes you've made to the app extension in your workspace. It is a working version of your application that you can use to test the behavior of your app extension. In the preview you can check the rule sets, layouts, the navigation between pages, and what happens when you add and edit data. While the data in the preview comes from your Cloud Application, you can freely make changes in the preview because the data is only stored in the test environment used for the preview and is not saved to the Cloud Application's data storage.

When you use Preview to view your application, you'll see the pages as they look based on your user role. This means that if the application has any rule sets that evaluate the user's role, this will affect what data you see in the pages, and you can't switch between layouts determined by rule sets.

To preview your application:

  1. Open a page in your application.
  2. Click Preview in the toolbar to open the application preview in your browser.

You can't share an application preview URL with your team members. If you want team members to see your changes, you'll need to commit the changes to a branch and then use the Share action to get a URL you can share.

Share Your Application Extension

Application previews can only be seen by you in your workspace, but by using the Share action you can allow team members to also see your changes to the application extension. The Share action generates a URL for the application extension that you can share with your team members.

If you made changes to the app extension that involved changes to the data model, when you share the URL you might need to also share the name of the sandbox so your team members can check the changes in the app extension using the correct data model. The URL of the application extension you are sharing might not be the same as the URL you see when you are previewing the application extension in the Designer.

To share your edited application extension:

  1. Open your workspace in the Designer.
  2. If you are using a sandbox, confirm that your current sandbox is the one you want to share.
  3. Open the User Menu and click Share.
  4. Click Copy to copy the generated URL for the application extension.

    If you are using a sandbox, you will need to share the URL and the name of the sandbox with your team members.

  5. Click Share.
  6. Send an email with the generated URL, and include the name of the sandbox if one was used.

Export Your Workspace as an Archive

When you want to share the files in your app extension, for example, with a team member, you can export your workspace as an archive. Importing the archive in the Create Workspace wizard creates a new workspace with a Git repository containing the files in the archive.

When you export an app extension, the exported archive contains the files in your workspace's branch of the app extension's Git repository.

To export an app extension as an archive:

  1. Open the Designer page in VB Studio.
  2. Locate the workspace that you want to export and select Export Application Extension in the workspace's options menu.