Records can be created in various ways. You can add a new record to your application or copy an existing one. You can specialize existing rules by creating a copy in a specific ruleset, against a different class or (in some cases) with a set of circumstance definitions. You can copy data instances but they do not support specialization because they are not versioned.
Based on your use case, you use the Create, Save As, or Specialization form to create the record. The number of fields and available options varies by record type. Start by familiarizing yourself with the generic layout of these forms and their common fields:
This information identifies the key parts and options that apply to the record type that you are creating.
Create a new class rule by selecting Class from the SysAdmin category.
Review standard and existing classes before creating new ones, as your application might only need new properties, not a new class. Many tools and wizards such as the Application Explorer and the Connector and Metadata wizard create classes automatically.
A class rule has a single key part, its name:
Field |
Description |
| Class Name |
Enter the name of a new class. Choose each new class name carefully. As a best practice, make any top-level class you create — a class with @baseclass as its immediate parent — abstract. Class names can contain up to 64 characters (letters, numbers, or hyphens) and must contain at least two characters. However, limit the length of the class name to 56 characters, because the system creates a History- class by prefixing "History-" to the class name. Use a hyphen between segments to show the relationship to superior classes. Follow the hyphen with a letter for the first character in each segment. Class names must be unique system-wide. By convention, an initial prefix or portion of your class name matches a top-level class for the organization, which helps assure this uniqueness. You cannot create a class derived from the Code- or System- base classes. These base classes are restricted. Except in unusual situations, do not create a class derived from the History- base class. Such classes are created automatically. As a best practice, do not choose a name that matches or starts with the name of an existing class group, unless the class you are creating is to belong to that class group. This is allowed, but results in a warning message. The following are not valid as names for new classes:
As a best practice to help assure unique class names, identify an organization in the first segment of a class name. In the second segment identify a division; lower portions can identify more specific purposes. This convention does not limit how such classes can inherit rules, through directed inheritance. For example, MYCO-HR-APPLICATION can be derived from Work-, and MYCO-HR-JOBTITLES can be derived from Data-. |
The Add to ruleset field is required but not part of the key. Select a ruleset name to be associated with this class. This ruleset value is used only by the Archive tools and the Application Explorer tool.
You cannot add a class rule to a shared ruleset.
In a development system that is connected to the PegaRULES database with an account with the appropriate capabilities, creating a new class derived from the Work-, Data-, Assign-, or History- base class in some cases automatically creates a new database table. See Platform generated schema changes.
New classes needed in your application are often derived from the Work-, Data-, or Embed- base classes.
The system does not use rule resolution or rule availability to find instances of the Rule-Obj-Class rule type. Choose class names that are unique system-wide, across all applications.
As soon as you save it, a new class is available immediately to all users and all applications. The system applies access control restrictions to the properties, activities, HTML, and so on that apply to the class (if any), but not for the class definition rule itself.
So although the new class is accessible to other developers, they cannot use its facilities until you update access groups, Access of Role to Object rules and other security rules.
The Availability value for class rules is always Yes.