In the Platform Console, click the Module ID of the OrderDiscussionModule to go to the module editor. If it is not already selected, click the Custom Objects tab. Next, click the Manage Designs button. In the Designs section, click the Edit button at the right upper corner to enter the editing mode. Then click the Add button that shows up below. Enter the following values in the dialog box.
Design Name = DiscussionThread It is recommended that you use Pascal casing for the design name, where the first letter in the name and the first letter of each subsequent concatenated word are capitalized. The Platform Console will parse this name according to the casing and display the resulting string "Discussion Thread" in the UI where it is necessary (e.g. navigation menus, permission settings, etc.), so make sure the design name is concise but sufficiently descriptive. |
Description = Discussion Thread Design or any descriptive text you prefer.The description field is only used for you or other developers to understand the nature or purpose of the custom object inside the module. It is not used anywhere else in the user interface. We are using a short description here, but you can make it as detailed as you want. |
Design Type = Primary |
The dialog box should look like this after you fill it out:
![]() |
When you are done, click Add & Close. The new DiscussionThread object should show up in the Designs section. Now the name of the DiscussionThread object becomes a hyperlink.

Click the hyperlink to open the DiscussionThread object in the custom object designer and view its details. As of this moment, it is rather empty, because we haven't entered any details for the object. Select Save and the Global Type field will be populated.
Now let's create the fields for this object, starting with the ID field subject. At the top right of the designer page, click Edit, and then scroll down to the Standard Fields section and select the Add button at the top right of the section.
![]() |
Enter the following values in the dialog box.
Field Name = subject It is recommended to use camel casing for the field name. The first letter of the name is lowercase and the first letter of each subsequent concatenated word is capitalized. The Platform Console will parse this name according to the casing and display the resulting string in the UI where it is necessary. For example, a field name "firstName" will be parsed into "First Name" for UI display. |
Data Type = Text Since this field will be used as a natural identifier (which will be explained below), it needs to be of data type Text. A custom object's natural identifier must always be of type Text. |
Indexed = yes Only fields that are indexed can be queried (i.e. the field must be indexed in order to use it in the WHERE clause of a query). This is an important detail to remember when creating fields. |
Summary Field = yes By checking this option, we are making this field display as a column in the custom object's list screen. Fields should only be marked as summary fields if they are helpful to an end user when trying to locate a particular instance of your custom object. Marking too many fields as summary clutters the list screen and actually makes it more difficult for end users to locate the record they are looking for. |
Position = 5 This determines the order in which fields will render on the UI. The field with the lowest position number (i.e. closest to zero) will render in the first column in the first row. The next will render in the second column of the first row. For each new field, increment this number by 5 or 10, so it will be easier to insert a new field between existing fields at a later time. |
Tab Index = 5 This determines the order in which end users will cycle through the field list when hitting the tab key. It is customary to set the tab index to the same value as the position. |
Text Area Rows = 2 This determines the number of rows in the textbox for this field if the Data Type is Text. If left blank, the default behavior is to display a textbox of one row. |
Max Length = 500 If the Data Type is Text, this is the number of characters that the database will store in that field. When Max Length is left blank, it will default to 200 characters. Note: If a user enters a greater number of characters than the max length specified, the value will be truncated, so it is important to set this value if more than 200 characters are expected. |
Render On Screen = Normal Fields can be rendered as Normal (meaning they can be edited), Read Only or Hidden (meaning they aren't seen by the end user, but can be accessed within scripts and by the REST API). |
Description = Subject or any descriptive text you prefer. The description field is only used for you or other developers to understand the nature or purpose of the field inside the custom object. It is not used anywhere else in the UI. |
After you ADD & CLOSE the dialog box, click Save at the top right. If you select it and click the Edit button, it should look like this:
![]() |
When you are done, click Add Another. The new subject field is now listed in the Standard Field section, and the form is reset to blank so you can enter another standard field. Let's enter the discussionThreadId field of the DiscussionThread object as follows:
Field Name = discussionThreadId |
Data Type = Text |
Indexed = yes |
Summary Field = yes |
Position = 10 |
Tab Index = 10 |
Render On Screen = Normal |
Description = Discussion Thread ID |
When you are done, click Add Another. Let's now enter the status field:
Field Name = status |
Data Type = Text |
Indexed = yes |
Summary Field = yes |
Position = 20 |
Render On Screen = Read Only Because status is not a user-entry field but populated automatically by a workflow (which will be discussed in a later tutorial), it should be read-only in the UI. |
Description = Status of the workflow |
When you are done, click Add Another. Let's now enter the createdBy and createdOn fields:
Field Name = createdBy |
Data Type = Text |
Indexed = yes |
Summary Field = yes |
Position = 30 |
Render On Screen = Read Only Because createdBy is not a user-entry field but populated automatically by scripting (which will be discussed in a later tutorial), it should be read-only in the UI. |
Description = Person who started the thread |
Field Name = createdOn |
Data Type = Date The createdOn field will store a date (with no time component). The Infor Nexus Platform uses the ISO date format YYYY-MM-DD (e.g. 2015-01-08 for January 8, 2015). |
Indexed = yes |
Summary Field = yes |
Position = 40 |
Render On Screen = Read Only Because createdOn will also be populated by scripting, it should be read-only in the UI. |
Description = Date when the thread was started |
When you are done, click Add & Close. All of the new fields you just entered should show up in the Standard Fields section.
This is probably a good time to hit the Save button on the top right to be sure that your changes so far are saved.
Now that we have entered all of the fields for the DiscussionThread object, there are a few more pieces of information required to complete the design. Enter the following values:
Natural Identifier = subject A natural identifier is a field that can be used, by an end user, to visually identify a record. It has three requirements. It must be: 1.) a standard field, 2.) of data type Text 3.) that is indexed. The Natural Identifier drop-down list includes all the standard fields from the current primary design. The designation of a natural identifier is required for a primary design. For our DiscussionThread design, we will use the subject field as the natural identifier.Note: A natural identifier is not the same as a numeric auto-incrementing ID field in a relational database. In the Get Started With API tutorials, you will see how the Platform Console automatically generates a unique numeric ID, or uid, for each instance of custom object. You do not need to create or manage a numeric ID field on your own. |
Schema Version = 3.1 The Schema Version identifies which version of the AppXpress API will be used by scripts uploaded to this custom object. Only version 3.1 should be used for scripting unless you have been otherwise directed. |
Visibility Mode = Transaction The Visibility Mode determines the scope in which an object can be accessed. Transaction means that an object is visible to all parties involved in a transaction, which is an appropriate setting for our discussion thread design. We will discuss the Visibility Mode in more details as we go along. |
Anchor To = Order This field determines to which native object in the Infor Nexus transaction the module will be related to. A primary-design custom object can be anchored/related to the following native objects: Order, Invoice, Packing List, Goods Dispatch, or Contract. In our PO discussion module, each discussion thread is related to a purchase order, so we are choosing Order in this drop-down list. |
Anchor Cardinality = List There are two types of cardinality: Single Value and List. Single Value means there is a one-to-one relation between the Infor Nexus native object and primary-design custom object, while List indicates a one-to-many relation. Because a purchase order can have multiple discussion threads, we need to select List. |
Click Save at the right upper corner of the screen to save the design. Before we move on, we would like to validate this object to make sure all of the requirements are met. Click the Validate button and make sure there are no validation errors. Note that pressing the Validate button will validate the whole module, so errors could have been detected elsewhere in the module. The error message should indicate this, so if you receive an error please read the error message completely.
Now we have completed the DiscussionThread object design, and are ready to move on to the DiscussionPost object design. Towards the top of the page, underneath the "OrderDiscussionModule" name, there is a breadcrumb that says "Designs > Discussion Thread". Click the Designs link inside the breadcrumb to go back to the Designs page.
Add an Embedded Design Custom Object