Item Classes

Item classes are created under the root item class, or within a parent item class, and inherit values based on selections made when defining the item class.

To create and manage item classes, user-defined attributes, and data security, use the Manage Item Classes task in the Setup and Maintenance work area:

• Offering: Product Management

• Functional Area: Items

• Task: Manage Item Classes

You can define item classes in a hierarchy where the child levels indicate the sublevels or types of the parent item class. All items are created within an item class. The item class hierarchy can be used to control processes for some levels of the hierarchy.

You can also use item classes for classification purposes and in some cases, item creation may not be allowed. By optionally setting the Item Creation Allowed attribute to No, item creation in an item class can be prevented. However, a child item class of that item class can be set to allow for item creation.

Note:

• When you create an item class, make sure you specify the API name.
• Avoid creating item classes with names such as Item, ItemCategory, ItemRevision, ItemSupplier, RevisedItemLineApproval, ChangeObjectApproval, Evidence, and Certificate. Or creating similar names for the item class and flexfield attribute groups. Distinct names help ensure that rules run without error.
• There’s no limitation on the number of item classes that can be defined. However, it is recommended that you don’t create more than 1000 item classes and make sure that the maximum depth of the item class hierarchy is 15. Most classifications don’t require more than five levels.
• If you plan to add BPM rules in your workflow approvals for changes and new item requests, it's recommended that you limit the number of item classes to 300.

If you need to create large number of item classes, then:

• Deploy EFFs incrementally as you set up your item classes. Don’t wait till you have set up all the classes to deploy.
• Before creating the lower-level classes, ensure that you have identified and associated the attribute groups and attributes to the higher-level classes. This is because any changes made to the higher-level classes automatically results in the re-deployment of the lower-level classes due to inheritance.

For example, the following figure illustrates the Desktop item class as a child of the Computers item class and both are set to not allow item creation.

The Green Desktop and the Gaming Desktop item classes are children of the Desktop item class and are set to allow item creation. Optionally, you can specify a date on which an item class becomes inactive. The inactive date of a child item class must not be a past date and must be earlier than the inactive date of a parent item class. Also, all children of a parent item class with an inactive date must be made inactive at the same time or earlier.

Note: Product Development doesn't support the versioning of item classes.

When setting up definition steps for a new item request at the item class, you can identify various item details as required, at each step. The definition of the entire entity or just specific attributes can set as required. This ensures that the item information required for a downstream step is defined and available for use.

You can define data security on an item class. All child items and item classes of the item class inherit the data security specified. Consider the following while creating and managing data security for item classes:

• Item classes have a Public check box, which when selected indicates that all items in the item class are public. All new item classes, including its child items and child item classes, are public by default, and don't require data security to be set. To make a child item private, you must deselect the Public check box in the Data Security dialog box.

  Data security is not enabled for public item classes. When editing an item class, on the Security tab, in the Actions section, click Actions: Select and Add, Data Security won't be available in the Basic or Advanced search for any of the predefined attributes except for user-defined attributes.

• Depending on your settings for the Public check box, if a parent item class or a parent root item class is public, all new item classes created within it are public by default. Similarly, item classes created within a private item class or a private root item class are private.

• When a parent item class is made public or private, the child items and child item classes inherit the updated data security setting of the parent.

• Private item classes can't have child item classes that are public.

• Public item classes can have child item classes that are private or public.

• In the case of private items, you can search for and view only the items you have access to.

• For extensible flexfield attribute groups, you must set the data security for public and private item classes. The data security controls which EFF attribute groups are visible to specific users, user groups, or organizations.

• You must set data security at the item class level to restrict access to user-defined attributes, and to values for public and private items.

You can control the creation, view, and update of items by associating a role with the item class and assigning it to a principal or group of users. Security allows a person or a group to have privileges to an item of an item class in each organization. This role is inherited. Therefore, if you have the privilege in a parent item class, you will automatically have the same privilege in the child item classes.