Patent Description:
Communities are branded spaces for a company's employees, customers, and partners to connect. Communities are a great vehicle by which a company can share information and collaborate with its employees, customers, and external or ancillary organizations, such as vendors, partnering businesses, or subsidiaries. A company can customize and create communities to meet its business needs, and then transition seamlessly between them. A company can create multiple communities for many different purposes. For example, a company could create a customer support community to reduce support costs by sharing tips and solutions, a channel sales community for partner deal support, a community dedicated to an upcoming event for use by the event's attendees, or a community representing a sub-group of an organization, such as an employee social group or a volunteer club within the organization.

Communities, or community spaces, which are typically provided online in web-based applications, can allow a company to share a subset of features and data from an internal customer relationship management (CRM) system that are applicable to the purpose of the community, in an engaging, branded experience. A community builder within a web app publisher, as described in <CIT> ("Systems, Methods, and Apparatuses for Creating and Reusing Communities Within a Cloud Based Computing Environment"), for example, can be used to design, build, and brand communities using standard or customized app components with point-and-click customization. <CIT> describes creating and reusing communities within a cloud-based environment, such as a database system implementation for the web, utilizing multi-tenant database technologies, client-server technologies, and traditional database technologies, such as on-demand database services. Although prevalent in web applications, such communities have not previously been made available to customers, partners, or vendors via a dedicated, or native, mobile application for use on mobile devices. <CIT> discloses systems and methods that may generate applications for operating platforms. A data source for an application definition may be created, and an object may be mapped to the data source. An application definition may be generated from the data source and object. An operating platform for application publication may be selected from among a plurality of platforms. An application may be generated for the selected operating platform. <CIT> discloses methods and systems for customizing applications in enterprise mobility management systems herein. A client agent software application on a mobile device may be customized to embed or make available enterprise server URLs, a session cookie for authentication, and various other data during the device enrollment process. The customization of the client agent may be based on the device, user, and/or enrollment session. After the device is enrolled in the enterprise system, the embedded data may be accessed by the client agent application to support seamless single-sign-on during first-time use. Additional customized applications based on device, user, and/or enrollment session, may be generated and provided to mobile devices during or after device enrollment. Customized applications may be based on application templates, such as packaged web applications or specific implementations of hosted applications. <CIT> discloses systems and methods for creation of a customized mobile application. In an aspect, the system receives one or more customization inputs from a user; automatically and dynamically retrieves at least one user information attribute from one or more servers that the system is operatively coupled with; verifies the received one or more customization inputs and the dynamically retrieved at least one user information attribute; creates at least one configuration file based on the verified one or more customization inputs and the dynamically retrieved at least one user information attribute; creates at least one web service file for configuration or hosting on a web/application server; and builds the at least one configuration file and the at least one web service file to generate and publish an executable file of the mobile application. <CIT> discloses a computer implemented method and system for creating a mobile application that provides a mobile application development software (MADS) and pre-coded software components (PCSCs) encapsulated in a mobile application creation interface (MACI). The MADS dynamically maps data to be rendered in the mobile application with one or more data sources and launches the MACI. The MADS creates one or more composite software components (CSCs) by combining more than one of distinct software components selected from component sources and/or the PCSCs. The MADS inserts one or more PCSCs and/or CSCs into the MACI. The MADS generates one or more recommendations for adding one or more characteristic objects associated with the mobile application. The MADS creates the mobile application using the inserted PCSCs, the created composite software components, the recommendations, the dynamically mapped data, and/or an adaptively configured application programming interfaces that facilitate backend integration of the mobile application with the user device. <CIT> discloses a framework for building applications herein. In accordance with one aspect, App metadata of an App may be specified by a user. The App metadata includes configuration information of the App. The App metadata and build rules may be input into a pre-build module to generate build scripts for building the App. The build scripts may be based on the App metadata and build rules. The build scripts may be provided to a build module to build the App for deployment. <CIT> discloses a method of producing a personalized software application providing a software code, prompting a user to provide a personalization input, receiving the personalization input, prompting the user to select at least one software module, receiving a selection of the at least one software module, prompting the user to input a plurality of clients, receiving an input of the plurality of clients, and compiling the software code, including the personalization input and the at least one software module, to produce a personalized software application executable on a mobile device.

The accompanying drawings, which are incorporated herein and form part of the specification, illustrate the present embodiments and, together with the description, further serve to explain the principles of the present embodiments and to enable a person skilled in the relevant art(s) to make and use the present embodiments.

The features and advantages of the present embodiments will become more apparent from the Detailed Description set forth below when taken in conjunction with the drawings, in which like reference characters identify corresponding elements throughout.

This disclosure describes methods and user interfaces to provide access to custom communities within a dedicated, or native, mobile application (app) via easy publishing of the mobile app. Having all the features of a community found in a web application, plus more, the native mobile application can create a more responsive community experience than can be achieved by a web application alone.

<FIG> illustrates a diagram <NUM> showing how communities can be based on data and functionality of a CRM system and provided via a cloud-based computing environment, using web and/or mobile applications. CRM data for both web and mobile applications is provided from CRM databases utilizing multi-tenant database technologies, client-server technologies, and traditional database technologies described in <CIT>.

Diagram <NUM> illustrates a CRM system provider <NUM> providing CRM data <NUM>, including access to community cloud storage <NUM>, to CRM system client <NUM>. From the CRM system client <NUM>, a customer community <NUM> is provided access, by Administrator <NUM>, to CRM data <NUM> regarding accounts <NUM>, <NUM>, for example. Also from the CRM system client <NUM>, a partner/vendor community <NUM> is provided access, by Administrator <NUM>, to CRM data <NUM> regarding products <NUM> for use in partner campaigns <NUM>, for example. Communities can be customized by Administrator <NUM> to use the specific branding of the CRM system client <NUM> to increase brand recognition and user trust within the customer community <NUM> and partner/vendor community <NUM>.

Features available from mobile applications, such as persistent (or push) notifications, that are not available via web applications, can now be available to a community from within a mobile app. Additionally, mobile apps with communities can be built quickly and automatically using a user-friendly graphical user interface (GUI) without an administrator having to write software code for the apps. The mobile app publisher of the CRM system can provide an abstraction layer that can allow CRM system clients to produce and distribute multiple instances of a custom mobile app, for different operating system platforms, through one unified interface, to one or more electronic application storefronts (hereinafter, "app stores"). By way of non-limiting example, a custom mobile app can be created in both iOS and Android app instances, which can be published to the Apple App Store and Google Play app store, respectively, using the same GUI. In this way, communities can be easily provided, discoverable, and accessible via various public and private app stores for better on-demand service to customers. The CRM system client, controller of the community, can also control the mobile apps to better meet and be more responsive to its customers' needs.

For example, an organization, such as a company, can create customized and branded business-to-business (B2B) or business-to-consumer (B2C) mobile apps using a mobile app publisher under a user interface (UI) framework that allows accelerated app creation in a visual development environment, using no code, with the help of standard and custom components. Thus, these mobile apps can be built in very few steps. The general features available from a mobile application under the UI framework are disclosed in concurrently-field <CIT>, entitled "Desktop and Mobile Graphical User Interface Unification. " The company can then distribute the mobile apps to partners and customers via one or more commercial mobile app stores, such as Apple, Inc. 's App Store for iOS apps and/or Google Play for Android apps, by way of non-limiting example. The mobile apps can be made available either publicly or privately from each app store.

Within the features of a mobile app can now be a community dedicated to responding to a specific subset of users or a specific user need. The community can be designed and customized using a Community Builder under the same UI framework under which a mobile app is published, but using separate customization capabilities. The Community Builder allows a company to quickly create and style a custom community to match the company's branding. For more details on the Community Builder, see <CIT>, entitled "Systems, Methods, and Apparatuses for Creating and Reusing Communities within a Cloud Based Computing Environment.

A built community can now be integrated into a mobile app, enjoying the additional capabilities of a mobile app environment, such as persistent notifications, and the additional capabilities of the mobile app publisher, such as additional branding and customization features. The mobile app can access the data of a previously configured and stored community, for example, via access to a "Community Cloud," or cloud-based storage. See <CIT> for details on the configuration and storage of communities in a Community Cloud.

A method for mobile app publishing that can create a responsive community experience is summarized in <FIG>, which illustrates a flowchart <NUM> describing steps of the method, according to some embodiments, that need not be completed in the particular order shown.

Method steps <NUM> and <NUM> comprise setting up the mobile app with a template. A template in a mobile app embodiment may be thought of as master mobile app code used to produce other mobile apps. Use of templates reduce the time and cost associated with creating mobile application instances of CRM system functionality and communities. A template can include a pre-configured format for a custom mobile app for the CRM system in general, for a component of the CRM system, or for an existing community. In step <NUM>, a computing device provides a template for creating a custom mobile app for a user group. In step <NUM>, the computing device provides a GUI that enables selection of the template for creating the custom mobile app for the user group.

Method steps <NUM> through <NUM> represent a summary of a custom mobile app submission flow. There are two phases within the custom mobile app submission flow: (<NUM>) metadata collection, performed when the administrator fills out distribution model data forms to describe the custom app to build and then starts the build process, and (<NUM>) post-submission lifecycle steps that allow the newly created custom app to be packaged, installed, tested in a beta version, and submitted to an app store for review before publishing in the app store.

Method steps <NUM>, <NUM>, and <NUM> represent a summary of the first phase of the custom mobile app submission flow. In step <NUM>, the computing device enables entry, via the GUI, of metadata comprising identification of a specific user community to be served by the custom mobile app. In step <NUM>, the computing device enables selection, via the GUI, of a distribution model for the custom mobile app for the specific user community. In step <NUM>, the computing device enables entry, via the GUI, of additional metadata comprising distribution model parameters and packaging parameters of the custom mobile app. The distribution model parameters include an app store ID, an app store account name, push notification server parameters, and a service account token, for example. The packaging parameters include a custom app name, a custom logo, a unique app icon, an app description, the language for the app text, and selectable colors, for example.

Steps <NUM> and <NUM> represent a summary of the second phase of the custom mobile app submission flow. In step <NUM>, the computing device packages the custom mobile app using the packaging parameters. In step <NUM>, the computing device publishes the app to an app store using the distribution model parameters.

The creating of the custom mobile app is performed automatically by a computing device as a result of GUI operations and entry of the metadata and the additional metadata by the administrator. Some embodiments of the GUI, implemented by a computer-readable device within a computer system, are described below and provide more details of the method.

<FIG> illustrates a branded mobile app on a mobile device <NUM> showing an example of a branded welcome, or home, screen for ABC Co. using data from ABC Co. 's CRM system, according to an example embodiment. In <FIG>, the mobile app screen identifies the client name <NUM>, branded graphics <NUM>, icons on an application launch pad <NUM> for accessing specific types of CRM system data, and messaging <NUM> to the mobile app's user group, according to the client's needs for the user group. Aspects of the branded mobile app, including the look and feel of the interface, the specific features available on the interface, the choice of community to reference and serve, the menus and user actions available on the interface, the data presented, the grouping of the data, the user access to the data, customized use of the data, user notifications, other metadata to drive the app, the app's distribution model, and the app store account configuration, for example, can be controlled by ABC Co. 's app administrator(s).

A community mobile app for ABC Co. , based on the example in <FIG>, can specifically serve ABC Co. 's sales department, with sales-specific information and built-in collaboration features. In other embodiments, a unique subset of data and features within the mobile app can be provided to another community of users of an ABC Co. product for troubleshooting help, for example. The community may include customized features, such as a chat function to allow users within the community to tag and discuss attributes of the product and help each other learn and use the product, for example.

<FIG> illustrates a screenshot of a GUI Landing Page <NUM> for creating a branded mobile app, including an option to incorporate a community into a mobile app, according to some embodiments. To start the process, an administrator can click the GUI button "Create New App" <NUM>. Clicking on "Create New App" <NUM> opens a GUI selection box <NUM> (see <FIG>). The GUI Landing Page <NUM> additionally includes a welcome banner <NUM> and a Resource card <NUM> with a listing of resource links. The resource links provide more information to the administrator about creating apps, such as links to videos that demonstrate the capabilities of the mobile app builder, and other informational resources to instruct the administrator how to use the GUI functionality, to define terms, and/or to provide the benefits and/or considerations of certain selections, for example.

<FIG> illustrates a screenshot of the GUI selection box <NUM> for selecting a mobile app template, according to some embodiments. The GUI selection box <NUM> provides the administrator the option to select an app template, using a drop-down box, to create a branded CRM system mobile app <NUM> having a custom name, logo, app icon, and colors, or a branded community mobile app <NUM> having a custom name, logo, app icon, and colors. According to some embodiments, and as shown in <FIG>, the communities template can be a "Lightning Communities" template, for example. A Lightning Community can be built upon a component user interface (UI) framework that provides core components that can be assembled and customized to build dynamic communities with simple drag-and-drop user actions, without the need for programming. Once a template option is selected, a "Next" button <NUM> will become active, allowing the administrator to click it to go to the next step of app creation.

In some embodiments, the GUI selection box <NUM> can include the number of branded CRM mobile apps available <NUM> to be created and the number of branded community mobile apps available <NUM> to be created, information that may depend on the number and types of licenses that a company has purchased for its CRM system, for example. In <FIG>, for example, the GUI selection box <NUM> indicates that the administrator has license to create one (<NUM>) branded CRM mobile app (for example, "Salesforce App Available <NUM>") and five (<NUM>) branded community mobile apps (for example, "Communities App Available <NUM>"). If an administrator has already created the one (<NUM>) branded CRM mobile app allowed by license, the number of branded CRM mobile apps available <NUM> would be displayed as "<NUM>. " If all licenses are used up, both the number of branded CRM mobile apps available <NUM> and the number of branded community apps available <NUM> could be "<NUM>.

<FIG> illustrates a screenshot of a GUI dialog box <NUM> that allows the administrator to enter a community project name, according to some embodiments. As shown in <FIG>, the administrator has entered "HD Community" into a Project Name text box <NUM>. In other embodiments, the administrator can select an existing community from a drop-down selection box. Upon entering or selecting the project name, the administrator can click the "Finish" button <NUM>, which kicks off the Object Manager process to build a custom app.

As previously stated, there are two phases within the custom mobile app submission flow: (<NUM>) metadata collection, performed when the administrator fills out distribution model data forms to describe the custom app to build and then starts the build process, and (<NUM>) post-submission lifecycle steps that allow the newly created custom app to be packaged, installed, tested in a beta version, and submitted to an app store for review before publishing in the app store. Phase <NUM> and Phase <NUM> will be further described in the following paragraphs according to the components and capabilities of the mobile app publisher GUI.

Some descriptions that follow illustrate the mobile app publisher GUI using one of two example environments: (<NUM>) an Android operating system (OS) environment for publishing an Android mobile app to a Google Play app store; or (<NUM>) an iPhone operating system (iOS) environment for publishing an iPhone mobile app to an Apple app store. A person skilled in the relevant arts would recognize that the specifics as they pertain to an Apple or Google Play app store herein are by way of example, and not limitation, and that a similar approach would be used for setting up, building, and publishing an app with other app stores.

<FIG> illustrates a screenshot of an Apps Management GUI <NUM>, including an Object Manager GUI <NUM> for managing the creation of a mobile app, according to some embodiments. Using the Object Manager GUI <NUM>, the administrator can start the creation of a branded community mobile app on a specific mobile platform <NUM>, having, for example, either an iOS <NUM> or an Android <NUM> operating system. The Object Manager GUI <NUM> can track status of the creation of a community mobile app with "App Store Status" <NUM> and "MyApp Build Status" <NUM> for each type of platform build, as applicable.

"App Store Status" <NUM> can indicate whether the app is in one of various development states, including draft, submitted, ready to build, beta, beta in review, beta cancelled, beta approved, live in review, live, live cancelled, archived, and deleted status, for example. The states apply to either draft data, that is, a draft app version that a CRM system client is in the process of preparing, or live data, that is, a completed and published app that is live on the Apple or Google Play app stores.

"MyApp Build Status" <NUM> will provide the administrator's progress within the steps of the lifecycle for building an app. In some embodiments, for example, step (<NUM>) in the app build lifecycle can be "Fill in App Information" <NUM>. Various embodiments may comprise different steps. See, for example, <FIG>, below. The administrator can start an app build by clicking one of the "Start" buttons <NUM>, <NUM> for the selected platform.

In some embodiments of the Apps Management GUI <NUM>, various information resources can be provided as links (not shown) on a Resources card <NUM> to demonstrate, in video format, the capabilities of the app builder, to instruct the administrator how to use the GUI functionality, to define terms, and/or to provide the benefits and/or considerations of certain selections, for example. The provision of resources here can be similar to the provision of resources shown in <FIG>. Provision of resources in multiple places within the GUI structure lends to the ease of use of the mobile app publisher GUI for building custom applications.

In some embodiments, the Resources card can be auto-expanded wherever the Resources card resides, such as on the GUI Landing Page <NUM> of the custom mobile app publisher GUI, as shown in <FIG>. In other embodiments, the Resources card can be collapsed as a default mode so as not to distract from the information on the main or active pages of the custom mobile app publisher GUI, as shown in <FIG>. In alternative embodiments, the functionality of a Resources card <NUM>, <NUM> can be replaced or supplemented by the functionality of a help icon <NUM>, <NUM> in a Help Tray <NUM>, <NUM> of the current GUI screen.

<FIG> illustrates a screenshot <NUM> of the App Build Status GUI <NUM> within the Object Manager GUI <NUM>, showing the steps involved in setting up a branded mobile app, according to some embodiments. Build step (<NUM>) is "Fill in App Information" <NUM>; build step (<NUM>) is "Request a CRM System Managed Package" <NUM>; build step (<NUM>) is "Install the CRM System Managed Package" <NUM>; build step (<NUM>) is "Request a Beta Version of Your App" <NUM>; and build step (<NUM>) is "Submit App for Review or Make Changes" <NUM>, for example. As the administrator completes each step, the steps are marked complete by a green checkmark in place of the step number, as shown for build step (<NUM>) "Fill in App Information" <NUM>. In some embodiments, build step (<NUM>) "Fill in App Information" <NUM> can be automatically marked as complete once an administrator submits metadata to define the app to be created. In these embodiments, an administrator can have the ability to edit the metadata as necessary.

In other embodiments, build step (<NUM>) is not necessary to list, and could be eliminated from an app builder, if an administrator is not allowed to edit metadata after it is submitted or at any point during the lifecycle of the app creation, for example. As shown in <FIG>, once the steps are completed, the created "app will be available in the <OS name> App Store" <NUM>. If build step (<NUM>) is not necessary or not used in the app creation process, the lifecycle can start at build step (<NUM>), "Request a CRM System Managed Package" <NUM>.

Regardless whether build step (<NUM>) is listed within the steps of setting up a branded mobile app, app creation is driven by initial metadata that an administrator enters into the app builder to set up a distribution model for the mobile app. A distribution model defines at least what entity has rights to publish the app, what entity has access to manage and maintain the app, where the app is published, and the credentials for accessing the administrator privileges, for example.

In some embodiments, an administrator can have privileges to, for example, select a distribution model for the custom mobile app, view the required configuration instructions for setting up a delegated account in an iOS or Android environment, input additional metadata required for each distribution model, and change the distribution model during an out-of-band update. An out-of-band update represents a change to the distribution model, such as by a CRM system client, when the distribution model is already instituted and in use to govern an existing "live" published app.

<FIG> illustrates a screenshot <NUM> of distribution model selection GUI components that displays after an administrator starts an app build by clicking one of the "Start" buttons <NUM>, <NUM> for the selected platform (see <FIG>), according to some embodiments. When the administrator clicks on "Select App Distribution Model" <NUM> under the App Distribution <NUM> GUI component, a distribution model picker <NUM> pops up, as shown in <FIG>. In some embodiments, and as shown in this example, four (<NUM>) distribution models are available to be selected for the Android operating system: Managed Public <NUM>, Managed Private <NUM>, Delegated Public <NUM>, and Delegated Private <NUM>. For the iOS, two (<NUM>) distribution models are available: Managed Private and Delegated Public.

In a Managed Public <NUM> distribution model, the app can be published under the CRM provider's developer account, and the CRM system client (the owner of the app) does not need to maintain its own app store developer accounts (for the Android operating system, for example). The app can be available to install on a public app store, such as the Google Play app store, for example.

In a Managed Private <NUM> distribution model, like Managed Public <NUM>, the app can be published under the CRM provider's developer account, and the CRM system client (the owner of the app) does not need to maintain its own app store developer accounts (for iOS and/or Android, for example). However, the app will not be available on a public app store, such as Apple App Store or Google Play app store, but can be installed on a private app store.

In a Delegated Public <NUM> distribution model, the app can be published under the CRM system client's developer account, and the CRM provider can be granted minimum access to control one app. The app can be available to install on a public app store, such as Apple App Store and Google Play app store, for example.

In a Delegated Private <NUM> distribution model, like Delegated Public <NUM>, the app can be published under the CRM system client's developer account, and the CRM provider can be granted minimum access to control one app. However, the app will not be available on a public app store, such as Google Play, but can be installed on a private app store.

Depending on the distribution model selected, various different metadata must be collected from the CRM system client to complete the setup of a custom branded mobile app. Some, but not all, of the configuration data included in the distribution models and configured with the GUI components described herein, will be described. A person of ordinary skill in the art would understand that configuration data collection may be similarly performed for many of the data items, and where different, a person of ordinary skill in the art would understand the differences. A person of ordinary skill in the art would also understand that, depending on the configuration of the desired distribution model, different combinations of configuration data may be collected using core or unique GUI components arranged similarly or differently on a GUI screen. See, for example, <FIG>, which illustrates a table <NUM> comprising examples of the combinations of metadata that the CRM system client can enter in an App Distribution GUI, according to some embodiments. These metadata are used to configure, for example, a custom mobile app distribution model for an Android <NUM> mobile device or an iOS <NUM> mobile device.

<FIG> illustrates a screenshot <NUM> of the App Distribution GUI <NUM>, according to some embodiments. <FIG> shows an example of a data entry sub-section <NUM> for keying in required metadata for the Managed Private <NUM> distribution model. This App Distribution GUI <NUM> appears, for example, when the distribution model has been selected from the Managed Private <NUM> GUI button shown in <FIG> and the administrator has clicked the "Done" button <NUM>. When the user is done entering distribution model metadata, clicking the "Submit" button <NUM> takes the user to the next GUI screen. In various embodiments, the App Distribution GUI <NUM> may have different data entry methods for entering distribution model metadata, as would be apparent to a person of ordinary skill in the art.

<FIG> illustrates a screenshot <NUM> of the App Distribution GUI <NUM>, showing a drop-down account picker <NUM> for setting up a private configuration in the Private Configuration GUI component <NUM>, according to some embodiments. The Private Configuration GUI component <NUM> can be used to select an existing Managed Google Play ID, for example, or to add a new managed Google Play ID, when the distribution model has been selected as Managed Private <NUM>. If a managed Google Play ID already exists, it will appear in the drop-down account picker <NUM> for potential selection. If no managed Google Play ID already exists, or if a new managed Google Play ID is needed or desired, the administrator can select "Add Managed Google Play ID" <NUM> and click the "Submit" button <NUM>, bringing up the GUI component shown in <FIG>.

<FIG> illustrates a pop-up dialog box <NUM> for entering a first set of a name <NUM> and an ID <NUM> of a desired new managed app store ID, according to some embodiments. <FIG> shows one example for a Google Play app store in an Android OS environment. Once the administrator adds this information and clicks the "Save" button <NUM>, the administrator will be returned to the App Distribution GUI <NUM> and the Managed Google Play name and ID previously entered will appear in the account picker <NUM>, as shown in <FIG> illustrates the screenshot of <FIG> with the name and ID of the newly added managed Google Play ID, according to the example. Here, the example name is "JentonTest" and the example ID is "45EID.

In some embodiments, the account picker <NUM> for private distribution models is a combination box with a multi-selection, multi-select picker. When multiple items are in the picker, the list is alphabetized by name, according to some embodiments, or alphabetized by ID, in other embodiments. If there is already a first account selected, and the administrator adds a second account, the new second account becomes selected along with the first account. This is illustrated by <FIG> and <FIG>. A person of ordinary skill in the art would understand that there are various other types of GUI components that could be used to collect this metadata from an administrator. In some embodiments, a data table GUI component, for example, can be used in place of the multi-select account picker <NUM>, for example.

<FIG> further extends the examples of <FIG> and <FIG>. In <FIG>, a second managed Google Play ID name <NUM> and ID <NUM> set is entered in the pop-up dialog box <NUM> (here, they are "Kellog's Cornflakes" and "1234ABC," respectively, for example). <FIG> illustrates the screenshot of <FIG> with the first and second name and ID sets of managed Google Play ID information that have been selected concurrently for a Private Configuration, according to the example. In <FIG>, both "JentonTest - 45EID" and "Kellog's Cornflakes - 1234ABC" appear in the multi-select account picker <NUM>, for example.

<FIG> illustrates a screenshot <NUM> of the App Distribution GUI <NUM>, showing data entry and selection GUI components when the distribution model has been selected as Delegated Public <NUM>, according to some embodiments. For the Delegated Configuration <NUM>, the administrator can select or add (if a selection is not already available in the account picker <NUM> drop-down menu) a publisher account for the applicable app store, which for <FIG> is Google Play for Android, for example. Similarly to the GUI actions shown in <FIG> and <FIG>, if publisher account information does not already exist, or if the administrator desires to add new publisher account information, by selecting "Add a new Account" <NUM>, a dialog box <NUM> (shown in <FIG>) will pop up to allow the administrator to enter a new publisher account ID. In contrast to the embodiment for a Private Configuration as shown in and described for <FIG>, the Delegated Configuration <NUM> has an account picker that allows for a single select picklist for a Google Play publisher account. A publisher account is required in a delegated distribution model because, as previously described, apps can be published under the CRM system client's developer account.

<FIG> also illustrates GUI components for entry of information for push notification setup <NUM>. A push notification, which is a message that pops up on a mobile device from an app to alert an app user, can be sent by the app at any time, and app users do not have to have the app in use to receive the notifications. Push notifications are not available from web apps, which makes a published mobile app desirable for this functionality. Push notifications can provide an app user a status of a sale event or a reminder to take an action, for example. By speaking directly to a user when an alert is most timely, push notifications can allow a CRM system client to be better connected to a customer, vendor, or partner. In the Delegated Public <NUM> configuration, for example, an administrator can set up a custom branded mobile app with a Server Key <NUM>, a Legacy Server Key <NUM>, and a Sender ID <NUM>, to allow for push notifications to come from the app server through the app to the app user.

In the App Distribution GUI <NUM>, a link to configuration instructions <NUM> for configuring the Delegated Public app, and a link to push notification setup instructions <NUM>, are available to provide administrator help resources during the process of app creation. Various other embodiments can incorporate help links and instructional messages from within the GUI pages during the distribution model setup steps and other steps, as would be apparent to a person of ordinary skill in the art. For example, to assist the administrator further, parameters for entry into a GUI component can be defined at an informational link, accessed by an informational icon <NUM>.

<FIG> illustrates a GUI component for entering identifying information for a new app store publisher account, according to some embodiments. <FIG> includes a pop-up dialog box <NUM> for entering a name <NUM> and a Google Play Publisher ID <NUM> of the desired new Google Play publisher account, for a Delegated Public <NUM> distribution model, according to some embodiments. Additionally, the administrator must upload a service account key file <NUM>, which, in some embodiments, must be a valid JavaScript Object Notation (JSON) file (with file extension. JSON) with a key named "type" that is set to "service_account," for example. Other embodiments may use a different data interchange file format, according to one of various applicable standards as known to a person of skill in the relevant arts, for transmitting the data objects associated with the publisher account. The "Save" button <NUM> can remain inactive (unaffected by a user click) until all object fields are completed and validations are successful. All object fields having been validated by the CRM system, the "Save" button can become active, indicated by a bolded, colored button.

<FIG> illustrates the successfully filled pop-up dialog box of <FIG>, according to some embodiments. For example, <FIG> includes a filled pop-up dialog box <NUM>, with "account1" entered as the name <NUM> of the Google Play Publisher Account, and "account1(@email. com" entered as the Google Play Publisher ID <NUM>. JSON file "file3234. json" has been uploaded as the Service Account Key File <NUM>. The "Save" button <NUM> is thus active.

<FIG> illustrates the App Store Configuration GUI <NUM> for specifying the custom mobile app packaging and configuration details, according to some embodiments. The packaging and configuration details include an app store on which to publish the custom mobile app, other product details, and the publishing constraints of the mobile app, for example, according to some embodiments. Under product details <NUM>, an administrator can enter the app store default language <NUM> in which the app is published, shown in <FIG>, for example, as English. The administrator can specify the app store name <NUM> of the app store to which to publish, for example, the Apple App Store for iOS mobile devices or Google Play for Android mobile devices.

The administrator can also specify identifying information for the mobile app that will be listed or displayed in the app store to help users find it, such as app name <NUM>, app store keywords <NUM>, an app store subtitle <NUM>, app store promotional text <NUM>, and an app store description <NUM> to describe the purpose and functionality of the mobile app to potential users, for example. The administrator can set up help links for users by entering an app store support URL <NUM>, an app store marketing URL <NUM>, and an app help URL <NUM>, for example.

In some embodiments, the administrator can also limit the countries and domains in which the mobile app can be downloaded. For example, in setting country availability <NUM>, the administrator can make an app available in all countries <NUM> (as a default) or available in certain specified countries by editing a country list using the "Edit" button <NUM>. The administrator can also specify the authorized domains <NUM> in which the mobile app can be accessed by adding a specific domain to the authorized list (using the "Add Domain" button <NUM>).

The administrator can also specify beta tester information <NUM> with the first name <NUM>, last name <NUM>, and email address <NUM> of the person responsible for the beta testing of the app, for example. Visual settings, such as the app header color <NUM> and other color and formatting schemes, for example, can also be specified.

If an administrator desires to change any of the app store packaging or configuration settings after a beta version of the mobile app is tested or after the mobile app is published, the administrator can click the "Make Changes" button <NUM> in the App Build Status GUI <NUM> at build step (<NUM>). In some embodiments, once the mobile app is published, the administrator would have to start over with a blank app store configuration GUI form. In other embodiments, the administrator can call up the app store settings for the selected mobile app and make changes directly to the existing settings within the populated App Store Configuration GUI <NUM> form.

On-demand customer branding changes can be made via out-of-band modifications to an app by the CRM system client administrator, in addition to app changes made via regular app updates by the CRM system provider. An administrator may also change a distribution model of a published app. However, changing distribution models in an out-of-band update may require a significant amount of work for an administrator. This is because, for example, if an administrator moves a mobile app from public to private distribution, the administrator may have to migrate the app's users from the existing app to a new one. The administrator may also need to provide more metadata based on the distribution model change. Various example scenarios are supported by the CRM system. <FIG> illustrates a table <NUM> showing the different administrative requirements for changing distribution models in an out-of-band update of a custom mobile app in an Android environment, for example. <FIG> illustrates a table <NUM> showing the different administrative requirements for changing distribution models in an out-of-band update of a custom mobile app in an iOS environment, for example.

For out-of-band changes to a distribution model of a custom branded mobile app (with or without communities), in some embodiments, metadata can be lost when a new app is created for the change. In such cases, a GUI component can offer warnings regarding administrator impact and request confirmations from the administrator before making a distribution model change that can cause metadata from the current mobile app to be lost. This may require an administrator to reenter metadata from the beginning of an app configuration process.

Other embodiments can preserve a clone of the app and its metadata so that an administrator does not have to start over from the beginning of the app configuration process. Some embodiments can copy all the metadata from the old app configuration into the new app configuration, saving the administrator time and preventing potential error in preserving desired aspects of the old configuration. A person of ordinary skill in the art would understand that metadata can be saved for a new app creation in addition to an app modification, in various situations and embodiments. Regardless of the complexity of the administrator's intended change(s), the method, system, and apparatus can enable on-demand modifications to the distribution model parameters or the packaging parameters for automatic creation of an updated or new custom mobile app.

The post-metadata submission lifecycle for a custom mobile app under the disclosed UI framework includes specifying packaging details and app installation details, provision and management of a beta version of the mobile app for testing, and submission of the accepted mobile app to a private or public app store for review and publishing. Further details of the UI framework are disclosed in concurrently-field <CIT>, entitled "Desktop and Mobile Graphical User Interface Unification," and <CIT>, entitled "Systems, Methods, and Apparatuses for Creating and Reusing Communities Within a Cloud Based Computing Environment," which disclose, for example, the "Lightning Component" UI framework.

The lifecycle from the standpoint of administrator action is driven through the mobile app publisher GUI as illustrated by the examples of <FIG>, showing the steps involved in setting up and building a branded mobile app, according to some embodiments. The Phase <NUM> steps according to <FIG> are: build step (<NUM>) - "Request a CRM System Managed Package" <NUM>; build step (<NUM>) - "Install the CRM System Managed Package" <NUM>; build step (<NUM>) - "Request a Beta Version of Your App" <NUM>; and build step (<NUM>) - "Submit App for Review or Make Changes" <NUM>, for example. The administrator must complete the steps in order by clicking on the appropriate activation button, as shown: "Request Package" <NUM>, "Install Package" <NUM>, "Request Beta" <NUM>, and "Make Changes" <NUM> or "Submit App" <NUM>. The activation buttons <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> for the respective step will be grayed out and not active until the previous step is complete.

<FIG> illustrate the pop-up informational boxes that the CRM system can send through the mobile app publisher GUI to lead the administrator through the final build steps of the live mobile app, according to some embodiments. As the administrator completes each step, the CRM system, through the mobile app publisher GUI, can throw a respective pop-up box to indicate the status of the activation of the related step. As the CRM system completes each requested step, the CRM system can send an email to the administrator to indicate that the deliverable for that step is ready. The following paragraphs illustrate examples of this GUI and system behavior, for each build step in the mobile app build process of <FIG>.

In build step (<NUM>) of <FIG>, "Request a CRM System Managed Package" <NUM>, an administrator's packaging specifications, regarding how the custom mobile app will be visually packaged, are implemented into a custom mobile app build. The build can implement a previously-specified custom name for the mobile app, such as a community identification, a logo previously uploaded for the mobile app design, an icon previously uploaded for the mobile app that can appear on the main mobile device screen or in an icon tray on the mobile device, and a previously-chosen color scheme for the mobile app, for example, as may have been entered in the App Store Configuration GUI <NUM>. Once the administrator is satisfied with the mobile app configuration, the administrator can click the "Request Package" button <NUM>. The CRM system, through the mobile app publisher GUI, can then throw a pop-up box <NUM> to indicate that the system is generating a managed package, as shown by the example in <FIG>. When the CRM system managed package is ready, the CRM system can send the administrator an email indicating that the managed package is ready. The email can further direct the administrator to build step (<NUM>) of <FIG> to install the managed package and can also direct the administrator to help resources.

In build step (<NUM>) of <FIG>, "Install the CRM System Managed Package" <NUM>, the administrator can kick off the installation of the custom mobile app once the managed package is ready. The administrator can then click the now-active "Install Package" button <NUM>. The CRM system, through the mobile app publisher GUI, can then throw a pop-up box <NUM> to provide instructions to the administrator to install the managed package, as shown by the example in <FIG>.

In build step (<NUM>) of <FIG>, "Request a Beta Version of Your App" <NUM>, the administrator can request a beta version of the new mobile app for testing before the mobile app is published in final form in an app store. Once the installation of the managed package is complete, the administrator can then click the now-active "Request Beta" button <NUM>. The CRM system, through the mobile app publisher GUI, can then throw a pop-up box <NUM> to indicate that CRM system is generating the beta version of the mobile app, as shown by the example in <FIG>. When the beta version of the mobile app is ready, the CRM system can send the administrator (and an identified beta tester, if desired) an email indicating that the mobile app is in beta version status and ready to test.

In build step (<NUM>) of <FIG>, "Submit App for Review or Make Changes" <NUM>, an administrator can submit a mobile app to an app store for review and subsequent publishing, according to some embodiments. The CRM system, through the mobile app publisher GUI, can throw a pop-up box <NUM> to indicate that it is time for the administrator to submit the mobile app for review, as shown by the example in <FIG>. At this stage, the administrator must confirm that the managed package has been installed in each licensed organization for which the mobile app is needed. This can be accomplished, for example, using a formal checkbox <NUM> that must be checked before a "Submit App" button <NUM> can become active.

Once managed package installation is confirmed, the administrator can click the "Submit App" button <NUM> from the pop-up box <NUM> in <FIG>, or later click the "Submit App" button <NUM> from the App Build Status GUI <NUM> in <FIG>. Once either "Submit App" button <NUM> or button <NUM> is clicked, the CRM system, through the mobile app publisher GUI, can then throw a pop-up box <NUM> to indicate that the mobile app is being reviewed, as shown by the example in <FIG>. Once the mobile app is reviewed and ready to download, the CRM system can send the administrator an email indicating that the mobile app is live and available to download and install from the applicable app store. If choosing to make changes, the administrator can return back to the App Store Configuration GUI <NUM> by first clicking the "Make Changes" button <NUM> from the App Build Status GUI <NUM>.

Various embodiments may be implemented using one or more well-known computer systems, such as computer system <NUM> shown in <FIG>. One or more computer systems <NUM> may be used, for example, to implement any of the embodiments discussed herein, as well as combinations and sub-combinations thereof.

Computer system <NUM> may include one or more processors (also called central processing units, or CPUs), such as a processor <NUM>. Processor <NUM> may be connected to a communication infrastructure or bus <NUM>.

Computer system <NUM> may also include user input/output device(s) <NUM>, such as monitors, keyboards, pointing devices, etc., which may communicate with communication infrastructure <NUM> through user input/output interface(s) <NUM>.

One or more of processors <NUM> may be a graphics processing unit (GPU). In an embodiment, a GPU may be a processor that is a specialized electronic circuit designed to process mathematically intensive applications. The GPU may have a parallel structure that is efficient for parallel processing of large blocks of data, such as mathematically intensive data common to computer graphics applications, images, videos, etc..

Computer system <NUM> may also include a main (or primary) memory <NUM>, such as random access memory (RAM). Main memory <NUM> may include one or more levels of cache. Main memory <NUM> may have stored therein control logic (i.e., computer software) and/or data.

Secondary memory <NUM> may include, for example, a hard disk drive <NUM> or a removable storage device or drive <NUM>. Removable storage drive <NUM> may be a floppy disk drive, a magnetic tape drive, a compact disk drive, an optical storage device, tape backup device, or any other storage device/drive.

Removable storage unit <NUM> may include a computer usable or readable storage device having stored thereon computer software (control logic) or data. Removable storage unit <NUM> may be a floppy disk, magnetic tape, compact disk, DVD, optical storage disk, or any other computer data storage device. Removable storage drive <NUM> may read from or write to removable storage unit <NUM>.

Secondary memory <NUM> may include other means, devices, components, instrumentalities, or other approaches for allowing computer programs or other instructions or data to be accessed by computer system <NUM>. Such means, devices, components, instrumentalities, or other approaches may include, for example, a removable storage unit <NUM> and an interface <NUM>. Examples of the removable storage unit <NUM> and the interface <NUM> may include a program cartridge and cartridge interface (such as that found in video game devices), a removable memory chip (such as an EPROM or PROM) and associated socket, a memory stick and USB port, a memory card and associated memory card slot, or any other removable storage unit and associated interface.

Computer system <NUM> may further include a communications or network interface <NUM>. Communications interface <NUM> may enable computer system <NUM> to communicate and interact with any combination of external devices, external networks, external entities, etc. (individually and collectively referenced by reference number <NUM>). For example, communications interface <NUM> may allow computer system <NUM> to communicate with external or remote devices <NUM> over communications path <NUM>, which may be wired or wireless (or a combination thereof), and which may include any combination of LANs, WANs, the Internet, etc. Control logic or data may be transmitted to and from computer system <NUM> via communications path <NUM>.

Computer system <NUM> may also be any of a personal digital assistant (PDA), desktop workstation, laptop or notebook computer, netbook, tablet, smart phone, smart watch or other wearable, appliance, part of the Internet-of-Things, or embedded system, to name a few non-limiting examples, or any combination thereof.

Computer system <NUM> may be a client or server, accessing or hosting any applications or data through any delivery paradigm, including but not limited to remote or distributed cloud computing solutions; local or on-premises software ("on-premise" cloud-based solutions); "as a service" models (e.g., content as a service (CaaS), digital content as a service (DCaaS), software as a service (SaaS), managed software as a service (MSaaS), platform as a service (PaaS), desktop as a service (DaaS), framework as a service (FaaS), backend as a service (BaaS), mobile backend as a service (MBaaS), infrastructure as a service (IaaS), etc.); or a hybrid model including any combination of the foregoing examples or other services or delivery paradigms.

Any applicable data structures, file formats, and schemas in computer system <NUM> may be derived from standards including but not limited to JavaScript Object Notation (JSON), Extensible Markup Language (XML), Yet Another Markup Language (YAML), Extensible Hypertext Markup Language (XHTML), Wireless Markup Language (WML), MessagePack, XML User Interface Language (XUL), or any other functionally similar representations alone or in combination. Alternatively, proprietary data structures, formats or schemas may be used, either exclusively or in combination with known or open standards.

In some embodiments, a tangible, non-transitory apparatus or article of manufacture comprising a tangible, non-transitory computer useable or readable medium having control logic (software) stored thereon may also be referred to herein as a computer program product or program storage device. This includes, but is not limited to, computer system <NUM>, main memory <NUM>, secondary memory <NUM>, and removable storage units <NUM> and <NUM>, as well as tangible articles of manufacture embodying any combination of the foregoing. Such control logic, when executed by one or more data processing devices (such as computer system <NUM>), may cause such data processing devices to operate as described herein.

Based on the teachings contained in this disclosure, it will be apparent to persons skilled in the relevant art(s) how to make and use embodiments of this disclosure using data processing devices, computer systems, or computer architectures other than that shown in <FIG>.

It is to be appreciated that the Detailed Description section, and not any other section, is intended to be used to interpret the claims. Other sections can set forth one or more but not all exemplary embodiments as contemplated by the inventor(s), and thus, are not intended to limit this disclosure or the appended claims in any way.

References herein to "one embodiment," "an embodiment," "an exemplary embodiment," or similar phrases, indicate that the embodiment described can include a particular feature, structure, or characteristic, but every embodiment cannot necessarily include the particular feature, structure, or characteristic.

Claim 1:
A method, comprising:
providing (<NUM>), by a publishing software, a graphical user interface, GUI (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>), that enables selection of a template for creating a custom mobile device (<NUM>) application, app, for a customer relationship management, CRM, client, wherein the template provides a pre-configured format to pre-configure the custom mobile device app;
receiving, by the publishing software, from entry via the GUI (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>), metadata comprising an identification of a specific user community to be served by the custom mobile device app;
detecting, by the publishing software, a selection of a selected distribution model from a list of distribution models for an electronic application storefront, app store, via the GUI for the custom mobile device app and the specific user community, wherein the list of distribution models define at least what entity has rights to publish the custom mobile device app, what entity has access to manage and maintain the app, and the app store to which the app is published;
displaying, by the publishing software and in response to detecting the selection of the selected distribution model, a first set of input fields or a second set of input fields respectively based on a determination that a first distribution model or a second distribution model has been selected for the app store, wherein the second set of input fields and the first set of input fields are not identical and wherein the second distribution model is different from the first distribution model;
collecting, by the publishing software, configuration information defined by the selected distribution model via the first set of input fields or the second set of input fields;
creating, by the publishing software, the custom mobile device app based on at least the metadata and the configuration information; and
publishing (<NUM>), by the publishing software, the custom mobile device app to the app store based on at least the selected distribution model, wherein the custom mobile device app is accessible from the app store for installation on a mobile device according to the selected distribution model.