If you received inactive project deletion emails on 4/30/25, you can ignore them. The projects named in those emails will NOT be deleted on 7/30/25. Some type of inactive project deletion will be implemented later this year, but you'll receive further communications before any deletions are scheduled.
@@ -20,6 +20,8 @@ A sub-org is functionally equivalent to a parent org, except some aspects are in
For example, a sub-org inherits licenses and connectors from the parent org.
Parent org secure agent groups can also be shared to sub-orgs.
Integrations can be monitored from the parent org to all sub-orgs, allowing the ability to get operational information for all environments in a single view.
A sub-org can not contain a sub-org. A sub-org can be created from within a parent org, or an existing org can be linked to a parent org to convert it into a sub-org.
### User Group
...
...
@@ -50,12 +52,15 @@ See the [Best Practices](./best-practices.md) for more information.
This may be a drawback for some applications that need more development environments (e.g. dev, QA, staging).
Objects can be named or organized to indicate a specific environment (e.g. "dev-mapping", "dev-project"), but having multiple development environments represented in a single org is not recommended.
### Use a Sub-Org
### Use a Separate Org with Sub-Orgs
This option involves creating a new parent org with sub-orgs contained within it.
The parent org would represent the production environment, with each sub-org representing a non-production environment.
For example, you might have a sub-org for dev, a sub-org for test, and then the parent org for production.
This option involves creating sub-orgs that only your team/department can access.
Unlike using the shared org, using a sub-org has extra financial costs.
Unlike using the shared org, using this multi-org approach has extra financial costs. Depending on your needs, the Integration Platform Team might be able to help cover the extra cost. Please [contact us](mailto:doit-integration-platform@office365.wisc.edu) if this is something you would like to explore.
Here are cases when using a sub-org would be recommended:
Here are cases when using this multi-org approach would be recommended:
- More than one non-prod environment is needed, since the shared org approach only provides one test and one prod environment.
- Many integrations are being built, requiring many objects. As a general rule, if you have over 30 projects or connections, this would be better managed in a separate sub-org.
\ No newline at end of file
- Many integrations are being built, requiring many objects. As a general rule, if you have over 30 projects or connections, this would be better managed by having your own org rather than using the shared org.
