Onboarding Apps and Solutions

overview onboarding of an app or solution enables developers to upload aaa permission files for individual apps or all apps within a solution to all tenants or a selected list of tenants in a stack the onboarding process should be repeated whenever there are changes in permissions files associated with apps this ensures the latest permissions for an app are updated within aaa, which is essential for secure usage of apps and solutions tenants there are two types of tenants development type tenant this pertains to tenants that are based out of a sandbox stack or any other development or staging environment developers must upload their permissions file to the development type tenant in order test their app within the development environment production type tenant production type tenants are designed for customer subscription and usage, for example, shared stack has tenants that are of production type developers should onboard their permissions file in production type tenant only after thorough testing of their apps and solutions there are role level restrictions allowing only dev admins and product admins the authority to onboard apps or solutions to production type tenants gating policies gating policies ensure that only valid apps and solutions are onboarded to production tenant environments, preventing issues for end users the key gating policies are state based gating only applications and solutions in a "live" state can be onboarded to production tenants, ensuring work in progress apps or solutions are not propagated to end users additionally, a solution can only be made live if all apps within the solution are live attempting to onboard non live apps/solutions to production tenants will trigger actionable errors to prevent access, warning developers to transition their apps/solutions to live role based gating publishing an app or solution for customer usage is restricted to product admins onboarding apps or solutions and updating permission files are restricted to app owners only this prevents unauthorized access changes by tying permissions to owners ownership based gating only app developers who belong to the app's organization can upload aaa permission files if a non owner attempts to upload an app they don't own, they will not be able to proceed this prevents incompatible permission files from being overwritten and causing app failure these gaiting policies only apply to production type tenants onboarding and use the new onboarding api the legacy api still allows onboarding apps in any state, but it is scheduled for deprecation onboarding flow for apps and solutions (prod type tenants) app onboarding onboarding an app to a prod type tenant involves the following steps app approval use updateappstates to pass your app through all lifecycle states for approval onboard app developers can choose whether to onboard to select tenants using solution/listing details, or simplify the process by onboarding to a whole stack at once the data parameter included in the response should be used to obtain the status check status call getonboardingstatus to confirm that onboarding status has been completed automatic subscription update subscription is updated automatically after onboarding is completed during onboarding, both production and developer tenants' subscriptions are automatically updated to use the latest app version solution onboarding app approval use updateappstates to ensure all your apps which are a part of a solution are live by passing them through all lifecycle states solution approval use updatesolutionstates to ensure your solution’s tech review has been approved onboard solution developers can choose whether to onboard to select tenants using solution/listing details, or simplify the process by onboarding to a whole stack at once both options enable tenant subscriptions upon successful onboarding the data parameter included in the response should be used to obtain the status check status call getonboardingstatus to confirm that onboarding status has been complete automatic subscription update subscription is updated automatically after onboarding is completed during onboarding, both production and developer tenants' subscriptions are automatically updated to use the latest app version bulk/stack onboarding for apps and solutions the onboarding apis supports bulk onboarding of an app or solution to all tenants in stack this feature increases developer efficiency by reducing repetitive tasks of onboarding an app or solution to all tenants in stack using a single api call onboard to all tenants in stack instead of specifying individual tenant ids, developers can provide the stackid ` parameter to onboard an app/solution to all tenants within a particular stack this handles iterating through all tenants automatically benefits easily onboard to many related tenants avoid repeatedly calling api individually per tenant scale to future tenants added to the stack credential type override setting the stackcredentialoverwrite flag to production forces the use of production credentials even when onboarding to developer/staging tenants benefits safely test production style onboarding in staging simulate production permissions and governance pre deployment app and solution onboarding apis developers have the option to choose from two different apis for app and solution onboarding these apis are designed to assist you in onboarding an app or solution to a development or production type tenant additionally, you can use them to onboard your app or solution to a stack of tenants, a list of tenants, or a single tenant when it comes to generating the initialization sequence, you have two options you can use v2 api to automatically generate the init sequence by using the app permissions file you uploaded alternatively, you can use v1 api to manually specify the init sequence we highly recommend using v2 api as it not only saves you time but also helps avoid human errors related to sequencing post /developer/tenants/v2/onboarding use this api to onboard a solution to the provided list of tenants without manually providing the init sequence the api determines the init sequence based on the app permissions file uploaded please note that the api will ignore the manually provided init sequence post /developer/tenants/onboarding use this api to onboard an app or solution when you provide the init sequence manually when performing a get status request, developers can see when the init sequence logs status will be started or completed path parameters true false 237false unhandled content type false unhandled content type false unhandled content type false unhandled content type body parameters true false 177false unhandled content type false unhandled content type false unhandled content type false unhandled content type false unhandled content type false unhandled content type false unhandled content type false unhandled content type example requests the following example request shows onboarding an app onboarding a solution onboarding an app/solution with a stackid onboarding an app to single or list of tenants { "versionid" "appversion 8649e5f3 73f8 4454 a779 7f2e015a9bc9", "tenantids" \[ "tenant1", "tenant2" ] } onboard an solution to a single or list of tenants { "versionid" "solnversion\ f8594a6b 47f4 4a3b 9edf 8b2c641e38af", "tenantids" \[ "tenant1", "tenant2" ] } onboard an app/solution to all tenants within a stack (stackid) app { "versionid" "appversion 8649e5f3 73f8 4454 a779 7f2e015a9bc9", "stackid" "sb1" } solution { "versionid" "solnversion\ f8594a6b 47f4 4a3b 9edf 8b2c641e38af", "stackid" "dlv india" } response on success, the response returns 200 for app onboarding and 202 for solution onboarding