Default Tenant in AgileApps

Overview

The default tenant creation process is not visible to the end-user and is created when you start the AgileApps application server for the first time post installation. Default tenant is made available for any fresh installations or when you perform an upgrade to the version 10.11 or later.

Note: AgileApps allows LDAP configuration in default Tenant even if the subdomain is disabled in Service configuration section. Also, a user can login to default tenant, if that user is present in LDAP directory.

When you perform an upgrade using the upgrade utility, you are provided with an option to use any of the existing tenants as the default tenant. However, if you do not select the option to use any existing tenant as the default tenant, the system creates a default tenant and the tenant ID is automatically updated into the AgileApps ISV settings.

Note: All functionalities related to an administrator user is available for the default tenant as well. Also, the default tenant capability is currently available for on-premise installations only.

Credentials for Default Tenant

Open the AgileApps application login page by accessing the URL from any supported web browser. An example of the login URL is https://yourdomain.com/networking/servicedesk/index.jsp where yourdomain is the name of your domain. Use the following credentials to access the default tenant:

• User Name and Password: Use the credentials you typed into the Software AG installer.

Note: Currently, the default tenant can create a maximum of 10,000 users. However, this value can be modified based on the user requirement.

Tenant Capabilities

Create Objects Custom Access Criteria Manage Sites Multiple Languages Overwrite Previous Package Install Package from File Single Sign-On Sandboxes Collision Warnings for All Objects Session Management

Create Application Developer Tools Mass Deployment of Packages to Tenants Object Inheritance Publish Package Synchronous Rollup Summary Fields Mobile Access Record Level Visibility

Default Tenant Capabilities

This table summarizes the default settings for new tenants in On-Premise installations. (Settings that are off by default tend to be features that are used less frequently and also introduce a significant performance overhead.)

Option	Default		Notes
	On-Premise	Cloud
Create Application	On	NA
Create Objects	On	NA
Collision Warnings for All Objects	On	NA
Concurrent Sessions Limit	off	NA	Adds overhead.
Custom Access Criteria	On	NA
Developer Tools	On	NA
Install Package from File	On	NA
Manage Sites	On	NA
Mass Deployment of Packages to Tenants	On	NA	Usually needed only in a Service Provider tenant.
Mobile Access	On	NA
Multiple Languages	On	NA
Object Inheritance	On	NA
Overwrite Previous Package	On	NA	Often needed by application development tenant.
Publish Package	On	NA
Record Level Visibility	On	NA	Rarely needed. Adds performance overhead and takes up space in the User Interface.
Synchronous Rollup Summary Fields	On	NA	Adds performance overhead.
Sandboxes	On	NA	Creates additional tenants, which increases costs.
Single Sign-On	On	NA
Delete User	On	NA	Enable this option to add the delete user functionality for a tenant. This configuration is available only if you have enabled User Configuration options for deleting a user in the Configure Service Settings page.

Execution Limits

Maximum number of Rollup Summary Fields

The maximum number of Rollup Summary Fields allowed in the platform. (Each carries out operations in the background to keep the value up-to-date across the database, increasing the load on the system.)

Max. Job Count

The maximum number of scheduled jobs that can be executed per day. (This value only affects legacy customers enrolled in old billing plans. It is ignored for newer customers for whom Block Pricing is in force.)

Rest API bulk operation max limit

The maximum number of records that can be in included in one call to the REST API:bulk record Resource. Default is 25.

Active

Determines whether the tenancy is active. Unchecking this box prevents that tenant's users from logging in.

Java Code Governors

Apply governors in Java code?

Turns tenant-level Governance ON or OFF. The default is ON.

• If unchecked, tenant has effectively unlimited use of Java resources. (Protections against runaway code are still in place, but the ceiling is very high.)
• These governors apply to each execution request--a request for platform execution resources that begins when tenant code executes (Java code in a Data Policy, Java code in a JSP page, or JavaScript code in an HTML page), and ends when that code terminates.

Apply custom limits for tenant

Used to set individual limits for the tenant. The default is OFF. When off, global settings are used. When on, values can be specified for:

• Tenant level string size - The total size of all strings allocated in the Java heap space during an execution request.
• Tenant level statement count - The maximum number of Java code statements that can be run during an execution request.
• Tenant level CPU time - The maximum number of CPU milliseconds that can be consumed during an execution request.

Learn more: Governors on Java Code