Optionally, you can identify an access group to be available to users in this organization. As a user or other requestor belonging to this organization signs on, RuleSets and versions in the application rules of that access group are added to the user's RuleSet list.
|Defined by|| Select |
|Access Group Name|| Optional. Displayed when |
Mark one access group as the initial default by selecting a radio button. This access group is used for an operator signing on in specific, unusual situations: when the operator signing on meets both of these conditions:
(If these conditions are not met, the access group you identify here has no effect.)
DetailsYou can identify the controller or Chief Financial Officer of your organization and a default calendar for business day calculations.
|CFO/Controller||Optional. Enter the operator ID of the Chief Financial Officer or Controller for your organization, if you plan to route email, assignments, or directed Web access messages to this person in your application.|
|Default calendar name|| Optional. You can identify a calendar name, the first key part of a Calendar
data instance, for business day calculations involving this organization. |
At runtime, when evaluating a calculation involving dates, system uses the first date in a calculation and this key to locate a calendar instance ( Data-Admin-Calendar class) that identifies holidays and work days. (That may be a different calendar data instance than the one selected based on the current date.)
|Top level class name|| Optional. Identify a top-level class that applies to all operators in this
When an operator belonging to this organization uses App Studio, this class is the default top-level class. When you create an organization in App Studio, the system uses the Organization Name value to create the top-level class and enters the name here. See top-level class. Your applications can include classes that inherit — by pattern inheritance — from this class, to indicate they are used only by this organization. Using directed inheritance, your classes can inherit rules from the Work- base class, Data- base class, or other classes. However, some applications support more than one organization, and the system does not require that classes you create be derived from an organization Top Level Class.
|Default RuleSet|| Optional. Identify a RuleSet that applies to all operators in this
organization. (For an organization data instance created during installation, this
field is completed automatically.) Enter the RuleSet that contains the top-level
class entered in the previous field. |
The ruleset version created by the New Application wizard identifies your own organizational ruleset as a prerequisite to the ruleset version it creates.
The Localization wizard and Field Value inspector also use this optional value. These tools derive a target language-specific ruleset from the developer's organizational ruleset.
The value in this field does not affect a user's RuleSet list. To make the rules in this RuleSet available to all operators in the organization, include this RuleSet and a version in the access group identified on the Access tab.
If blank, the requestors that are associated with this organization do not have an organizational ruleset.
RuleSetsFor Organization data instances with
an Explicit RuleSet list. This approach is deprecated for new development.
|RuleSet Name|| Deprecated. Displayed when |
ResultsTo review your RuleSet list:
- From Dev Studio, click the down arrow next to your name to access the Operator menu, and then select Profile.
- From a WorkManager portal, click the Dashboard bar, and then click the link containing your name at the top of the navigation panel.