## 7. 06 Consume: Consumer subaccount
To test the subscription to the SaaS solution during the development phase of the multitenant application, a consumer subaccount is created in the global account for development. This allows your consumers to have their own configuration of:
- Trust settings (custom identity provider)
##  Note
If you want to integrate an existing corporate identity provider for authentication/authorization in subaccounts of the global account for development, see Trust and Federation with Identity Providers. To restrict access based on certain criteria, such as the IP address, you need to use the Identity Authentication service. See SAP Cloud Identity Services - Identity Authentication.
- Connectivity via SAP Cloud Connector. See Connectivity in the Cloud Foundry Environment.
- Destinations. See Managing Destinations.
- Subscriptions
##  Note
You can use a booster (see Booster for Landscape Portal [page 1229]) to automatically perform the setup of subaccounts 00 Landscape Portal, 03 Build/Assemble and 04 Build/Test.
## Development Flow
For development and maintenance processes, the steps mentioned below, that are similar to the ones described in Use Case 2: One Development and Correction Codeline in a 5-System Landscape [page 792], are performed.
<!-- image -->
- ABAP system COR and QAS have the same software state, unless a new change is tested and released. This means, transport requests are released in ABAP system DEV only if development is completed and it's planned to import the changes to the production ABAP system.
- Upon cutoff date, development is finished. All development that is released at this time must be tested and be of good quality. From then on, you must fix defects in the COR system and maintain them in parallel in the DEV system. In case of released APIs in the involved software components, API snapshots should be created at this point - in the test system TST as well as development system DEV. This is required for API compatibility checks to function properly. SeeChecking the Compatibility of Released APIs.
- Upon release date, all defects must be fixed. If, during testing in the QAS system, you make the decision that a complete functionality isn't delivered, developers must delete, revert, or disable the functionality in the COR system and release the corresponding transport requests. You can't remove objects from the release branch, e.g. by deselecting transport requests. To revert objects to a previous transported state, use the Compare editor of the Eclipse History view. If you want to withdraw the functionality in the DEV system as well, it's considered a correction and you have to perform double maintenance of corrections into the DEV system. See Double Maintenance of Corrections into Development [page 809].
- Once correction system COR and quality assurance system QAS are used for maintenance development, you can also create API snapshots for the latest release or support package version in these systems.
- Users in ABAP system COR are locked during ongoing development and only unlocked when a correction has to be implemented
- For the consumption as a SaaS solution, instead of importing a release branch into a productive system, software components are installed via add-on delivery packages into multitenancy-enabled production systems AMT provisioned via the ABAP Solution service. See ABAP Solution Service [page 1251].
## Global Account for Production
<!-- image -->