Aras Fundamentals: Creating a Workflow
This post will cover the basics of Workflows, an organizational tool of businesses everywhere. We’ll go over creating a Workflow map, adding steps to it, and assigning it to an item. At the end, we’ll talk a little about creating tasks for the Workflow we’ve created. Once you finish, you’ll know how to make Workflows for your own organization, and will be able to customize to your heart’s content. To follow along, you’ll want to be an Administrator in Aras Innovator. The screenshots in this post were taken on Aras Innovator Version 12 Service Pack 10, and while the steps should be similar if you’re on Version 12 you may notice small differences in what you see if you’re using a different service pack. Create A Workflow Map Lets start by creating a new Workflow. This will feel familiar to anyone who has been following our Aras Fundamentals series, as a Workflow is just another item. (Welcome to Aras Innovator, where just about everything is an item if you try hard and believe in yourself!) Follow the steps below: Open the table of contents, and look under Administration. Click on Workflow Map. Click on Create New Workflow Map. You’ll see a form open up. It has three main parts- a visualization of your map, some details about your map like Name and Description, and the relationships your Workflow Map has. Under “Name” type a name for your Workflow map. We’re going to call it Purchase Order for example. Under “Process Owner” you need to select an identity. Here, we’re going to use the Administrator identity. Click Save, up above. Assigning a Map to an ItemType On its own, a Workflow map isn’t going to be usable. It sits there, disconnected from your processes. To fix that, lets connect it to an ItemType. Here, we assume you’ve followed along with the Fundamentals series and have a Purchase Order ItemType to connect to, but you can use another ItemType in your instance if you prefer. To assign your new Workflow to an ItemType, follow the steps below: Open the table of contents, and look under Administration. Click on ItemTypes. Search for the ItemType you want to connect to. We’re going to search for the Purchase Order ItemType, but again, you might be using something different. Open your ItemType. Click Edit to open the ItemType for editing. The relationship tabs should be at the bottom of the form. Look for the Workflows tab. Click the Add Workflow Maps button. You’ll be presented with a search grid. Search for your Workflow map by the name you gave it earlier, for example “Purchase Order” Select it, then hit OK. On the right of the new row, you’ll see a checkbox labeled Default. Check this box to make this the default map for that ItemType. Save and close your ItemType! Activities and Paths Now we have our foundations laid. The Workflow exists, and is assigned to the ItemType. An item of that type can move through the Workflow map, stopping at the various stages it hits on its journey of improvement and additions. Of course, right now our map has only one step, which is probably not worth making a whole Workflow for. Lets get to the part we’ve been waiting for, adding new activities and paths! Some definitions: In Aras Innovator, an activity is what generates assignments and tasks. Think of an activity as a place where your Workflow says “someone needs to do something here.” An activity path, on the other hand, connects Workflow activities. If there are multiple possible next steps, the multiple paths are forks in the road, and someone is going to need to decide where to go next. Both are added from the Workflow form, so go open your Workflow back up again. To add an Activity: Make sure the Workflow is open for editing by hitting the edit button if it is shown. Right click on blank space on the Workflow canvas- the upper part of the form- and select “Add Activity” from the context menu. Enter a name for the activity below. In this example, we’ll call our first activity “Review Order” Repeat steps 2 and 3 as many times as needed, for each activity you want to create. To add an Activity Path: Make sure the Workflow is open for editing by hitting the edit button if it is shown. Right click on the activity you want to start from, and select “Add Path” from the context menu. You’ll now see a small arrow trailing after your mouse. Left click on the activity you want to transition to. The arrow will now snap to that activity node. Repeat steps 2 and 3 as many times as needed, for each activity path you want to create. Keep in mind while working with the Workflow map that you can always left click an Activity or Activity Path to change its name or other details, and that you can freely click and drag activities around the map. Don't try this on a highway map. We got very lost the time we did. Conclusions and Congratulations Today you’ve learned the basics of Workflow maps. You’ve made a new Workflow, assigned it to the ItemType it fits with, and added some activities and activity paths. You might have even edited or rearranged the activities and activity paths, making it visually clearer what is going on in your process. There are countless customizations you can make, both to your process and to how it’s represented in Aras Innovator, and hopefully as Aras Innovator becomes more integral into how your organization functions you’ll find ways to improve your process that are only possible with Aras. From methods which fire as an item reaches a new stage of your Workflow to voting weights to get input from key decisionmakers, the Workflow Maps are a powerful tool to making Aras Innovator work for you.Aras Fundamentals: Customizing Relationships with the RelationshipType
When a Relationship is defined on an ItemType, two new Items are created: a Relationship ItemType and a RelationshipType. In a previous blog post, we went over how to create a new Relationship for an ItemType and some basic aspects of configuring the Relationship, most of which took place on the Relationship ItemType. This Aras Fundamentals blog will expand our ability to customize a Relationship by adjusting settings on the RelationshipType Item. We’ll be working with the Purchase Order ItemType from previous Fundamentals posts, too. First, we’ll set a minimum number of Part relationships required for a new Purchase Order to be saved. Then we’ll discuss how to hide the Relationship Tab in the Item Editor, and why we’d want to do that. Finally, we’ll customize what a Relationship Tab displays based on who is using the Relationship View. Minimum and Maximum Occurrences Let’s open up the Purchase Order Part RelationshipType for editing (not the ItemType!), which can be found under Administration > RelationshipTypes > Search RelationshipTypes. When a new Purchase Order is created, we want at least one Part to be attached to it before it can be saved. To ensure that this happens, we’ll set the Minimum Occurrences (in the Related group box) to 1. Now, save and unlock the Item and we’re done! We can test this out by creating a new Purchase Order and trying to save the Item without adding a related Part; an error dialog will be shown to us indicating what the problem is. This method also works if we want to set a maximum number of entries of a RelationshipType, just enter the maximum value in the Max Occurs field. Both occurrence checks can be used simultaneously, just be sure that the minimum is less than the maximum. Additionally, if we wanted to remove any occurrence checks, we would leave the field blank (rather than enter in a value of 0). Hiding the Relationship Tab Next, let’s go over the “Hide in All” option for the RelationshipType (In the Source group). Checking this option will hide the tab for this ItemType on the Relationship Grid of the parent Item. This is useful for any Relationships that are set and used behind the scenes, but that end users don't need to see. Customizing the Relationship View Sometimes, when we have a Relationship, the standard grid layout isn’t the best way to show the information for that Relationship. Or possibly we want to have different Views depending on what User is looking at the parent Item. Building a custom view from the ground up is beyond the scope of this blog, so we’ll use two existing RelationshipTypes as examples: Project Tree on the Project ItemType and Part Multilevel BOM on the Part ItemType. Let’s take a look at the Project Tree RelationshipType first. The Project Tree’s Relationship View is set for the World Identity, so all users will see the Relationship View. The Start Page value is set to an HTML file so when the Project Plan Tab is opened, a custom HTML page is loaded instead of the standard relationship grid, as shown below. The Relationship View for Part Multilevel BOM has the Start Page pointing to the Tree Grid View main page. In order for this page to display the Part Item’s data correctly, we also need to pass in Parameters such as the ID of the Tree Grid View and a start condition with the source ID of the Part Item. When we open the BOM Structure Tab on a Part that’s an Assembly, we can see the entire bill of materials in an expandable list. Conclusions and Congratulations Today, we dug deeper into the ways we can customize our Relationships in Aras Innovator, with a focus on the RelationshipType. We started simple, with setting minimum and maximum limits on the number of related Items. Then we discussed hiding a Relationship Tab, and when it would be useful to do so. Finally, we showed two examples of changing what’s shown in the Relationship Tab using the Relationship View. Thanks for reading this Aras Fundamentals blog! There are more in the series that help explain different concepts and ItemTypes within Aras Innovator. Or visit the Forums to ask and find answers to specific questions.Aras Fundamentals: Advanced Properties
This post will cover some of the more complex but no less useful ways you can use Properties in Aras Innovator. We’ll go over Foreign properties, some Property Settings such as Item Behavior and Default Search, and even Property Events. In this article, we assume you already have an ItemType such as the Purchase Orders ItemType from the Aras Fundamentals series article to build on. To follow along, you’ll want to be an administrator in Aras Innovator. The screenshots in this post were taken on Aras Innovator Version 12 Service Pack 2, and while the steps should be similar if you’re on Version 12 you may notice small differences in what you see if you’re using a different service pack. Foreign Properties The simplest way to think of a foreign property is that it lets you reference another item, making a relationship between the two. The Foreign Property value, which isn't set directly, stores the property name of the other item. You might use a Foreign Property for example if you wanted to reference the address of the customer associated with a Purchase Order. Last time, we made an Item property to reference Customer: if you need to revisit how to do that, take a look at this article. To use foreign properties of Customer, use the following steps: From the Properties tab of the Purchase Order ItemType, click the Add Row button. First, we need the basics for a property. Enter “_customer_address” for the name, and “Customer Address” for the label. We need the name for the system, and the label so it’s clear to users what this represents. Select “Foreign” for the Data Type. Click on Data Source. In the dialogue, look for _customer, and click the expand icon. Double-click on Address. Click Save. If you look at the Foreign Property value of _customer_address, you’ll see it just says “address.” While it gets set by what you use for Data Source, this is a quick way to look at what property of that other item your new property is using as a reference. Columns The Item Behavior column is only useful where the property is on versionable items. When the Item Behavior is set to Float, it will always reference the latest version of the item. Once set, there’s little need to change this, but it can be important to be sure which generation of something you’re working with. On a similar note to tracking version, the Track History checkbox can be checked to ensure that changes in the property are recorded in the history of the item. It only applies to the properties with this checked, meaning that your history can record some properties and not others. A Default Search can be used to set up, in advance, a search that a user can run as soon as they open up an item for searching. While the user can override this search, it’s useful if there’s one main search that you know most users will go into that ItemType looking for. For example, perhaps you want your users to prioritize purchase orders with prices above a certain threshold; in that case one could arrange for Purchase Orders to default to searching for things with a price above 100. From the Properties tab of the Purchase Order ItemType, look for the _price property. In the Default Search column, type “>100” to specify that the search should return only things with a price above 100. Click save. Now, if you find Purchase Orders in the table of contents and open a new search, you should see that there’s already some criteria in the Price column. This can be combined with Autosearch for very convenient searching, or simply used to pre-fill some suggested searches. Unfortunately, searching for "the best item" doesn't turn up results in most environments. Next update maybe! Property Events Properties can have methods tied to them, triggering when certain events take place. This allows you to build up complex functionality from the methods you have available, and even simple methods can be exceptionally convenient. To set up a property event, follow the following steps: From the Properties tab of the Purchase Order ItemType, right click on the property you’d like to make an event for. From the menu that results, click Properties, and then click Open. A new tab will open for that specific property. Below, you should see the Event tab. You’ll need to click Edit to open up the property for changes, but once you’ve done that you can click the select icon to see a dialogue where you can search for the method you want. Select it, then click OK. In the resulting new row, you’ll see an Event column. If you click the cell, then click the dropdown icon, you’ll see the list of events to choose from. What kinds of things can property events be useful for? OnEditStart is an event that begins as soon as you begin to change the property. A method here that might be useful would be one that set a related property, for instance if you had one property for whether a purchase order had multiple associated delivery dates then beginning to edit the field for the second date could alter the first property without needing to manually do it. OnEditFinish will activate when someone is done editing and clicks away, and here it can sometimes be useful to bring up a confirmation message in the case where the information would be both unusual to change and very important to get right. There’s also the OnEdit event, should you have need of that. The OnChangeCell event can be used to create an autosave, saving the form whenever you changed away from the property. OnSearchDialog will activate as a search dialogue starts up. One clever use of this event is, when searching Identities, to set the search only to return and display identities that represent user accounts instead of say, a group like Administrators. The OnGetValue event can be used to interact with the results of a search, for instance removing some category prefix from the name of items. Conclusions and Congratulations In this post, you’ve learned how to make use of advanced item properties such as foreign properties. You’ve set up a default search for our Purchase Orders, and learned about the various events a property can have. We haven’t covered all of the columns, but remember that if you’re ever curious about their usage Just Ask Innovator is always available. If you have more questions, feel free to get in touch in the comments below! Where can these tools be best used in your organization? Is there a search common enough to make the Default Search, or a property event you could set up to make things more efficient? In Aras Innovator, sometimes helpful changes are only a few clicks away.
Aras Fundamentals: Creating a Custom Permission
Permissions play a big role in how administrators handle authorization for their users’ access privileges. This includes what items can be updated, deleted, accessed, discovered, etc. In this blog post we will be building from the Aras Fundamentals: Creating an ItemType post in which we created a custom Purchase Order ItemType. Let’s say we want to create a custom Permission called Purchase Order Managers for users who should be able to create, get, update, and discover Purchase Orders. In our example we will add two individuals, Mike Miller and Aaron Lee, to our new Permission. We also want to allow all employees to be able to read, get and discover these items but not be able to edit them. Innovator admin should also get all privileges managers receive including the ability to change access. Creating our New Permission Before we create our new Permission make sure you are logged in as Innovator Admin. Once that is set go to the TOC > Administration > Permissions and choose Create New Permission. Give it the name of Purchase Order Managers. In the relationships tab click the select icon which will prompt the search grid. Quick note: the main distinction between "get" and "can discover" is that the latter restricts one to only being able to view a list of Items while the prior allows one to open an item from search in a read only view. Next search and select the following identities by clicking the select button : Mike Miller Check the following boxes: Get, Update, Delete, Can Discover, and Show Permissions Warning Aaron Lee Check the following boxes: Get, Update, Delete, Can Discover, and Show Permissions Warning All Employees Check the following boxes: Get, Can Discover, and Show Permissions Warning Innovator Admin Check all the boxes except for Show Permissions Warning Please note that these identities, such as Mike Miller and Aaron Lee are within my database. Feel free to choose whichever users you would like for this example. However, be sure to include Innovator Admin and All Employees. The new Permissions should look like this: Adding our Changes to the Custom ItemType Next be sure to remove the world identity set from the previous blog post. We can do this by going to the TOC > Administration > ItemTypes. Another quick note: the difference between "World" and "All Employees" is world includes any user within the system. This includes all admins such as ES admin, while the latter is only for individuals in your organization (the only admin in this identity is Innovator Admin). Now in the search look for the Purchase Order ItemType we created previously. In the relationships section click on the Permissions tab: Search and select Purchase Order Team in the grid by clicking the select button Select World and hit the delete button to remove Also make sure to select Is Default Validating our Changes Now let’s confirm the permissions are set correctly by creating a new Purchase Order. Go to the TOC then scroll down and right click on our new ItemType and select Create New Purchase Order. We’ll call this “Purchase Order 1” and give it a price of “20”. Now log out and sign back in as Mike Miller and go back to the TOC > Purchase Orders > Search Purchase Orders. Click the search and open up Purchase Order 1. Since Mike Miller has update privileges, we can select the edit button and change the price to 30. We can take this a step further and test to make sure the All Employ identity truly does not have the same update access. This means they should only be able to read, get, and discover. Log out Mike Miller and sign back in as Terry Adams who is part of the All Employees identity. Go back to the Purchase Order we created and try to make an edit; you should receive the following error: In Conclusion You just saw how to create a new permission and assign it to different users within your organization accordingly. Following along with our blog series we have learned how to not only create a custom ItemType, but now how to add a custom Permission! This ensures that Employees can only create new Purchase Orders but in order to delete an existing Order this must be managed by either a manager or a system administrator.Aras Fundamentals: Adding Detailed Properties
This post will cover the common varieties of Properties that an ItemType can have, each of which has useful applications in Aras Innovator. We assume that you already have an ItemType such as the Purchase Orders ItemType from this article and that we need to extend the capabilities of our Purchase Order ItemType. We’ll give step by step instructions for adding a property, specifying the data type of that property, and the uses of advanced data types such as filtered lists. To follow along, you’ll need to be an administrator on your Aras Innovator instance. The screenshots and specific steps in this post were made using Aras Innovator Version 12 Service Pack 2. While the steps should be similar if you’re on Version 12 ,you may notice small changes if you're using a different service pack. Adding a Property We'll be adding a number of properties in this article. Each time, there will be some variation in which Data Type we choose, and which optional columns we make use of, but the basic flow will remain the same. First, we need to make sure we've opened up our ItemType. Open the Table of Contents -> Administration, and there you'll find ItemTypes. Left click on that. Click Search ItemTypes and type the name of the ItemType you want to modify in the Name column. For the rest of this example, we’ll use the Purchase Order ItemType, but you can use whatever ItemType you’ve made. Hitting Enter or clicking Search will run the search. Open your item in the results table either by double clicking or by right clicking and choosing Open. We can leave Now that the Purchase Orders are open, we need to edit them. Click the Edit button and in the Properties tab. click the Add Row button at the top left of the tab. A new row appears, and we can enter information for our new property. Each new property we add, we’ll come back here and click the Add Row button. Now that we know the basics, lets get in to the details. Common Data Types When making our Purchase Order ItemType we made two properties, _price and _name. We specified Names, Labels, and Data Types for both, and _name had a Length. What does all that mean? Name is how a property is identified from Aras Innovator’s perspective Label is a more human recognizable term that will be used in views and menus. Data Type is used to determine what kind of information will be stored here, and we’ll spend a portion of this article going over the different types and their use cases. Length specifies the maximum number of characters that a property with the Data Type String can contain. Some values, like Length and Precision, are only used for certain data types. A description of all such columns can be found in the Just Ask Innovator documentation. A brief digression on Data Types: String and Text can both be used for information like the sentence “String and Text can both be used for information like this sentence” so what’s the difference? String limit is defined by Length. (A character is a symbol, like the letter “a” or the digit “1” for example.) Text has a much, much larger maximum, but also takes up more space and is slower. Similarly, Integer, Decimal, and Float are all used to store numbers, but they have some important distinctions. Integers store whole numbers like “5” or “451” Decimals can have decimal places to some specified level of precision via the Precision column. Floats provide vast range of possible values without needing to specify to what decimal place it will store, but often cause rounding issues. Dates have the specific use of storing, well, a date! For the moment, the last datatype to mention is the Boolean, which simply stores a true or a false. Booleans are often used for check-boxes; checked, or unchecked. We’ll get into List, Filtered Lists, Sequences, and Items later. First, lets use some of the Data Types above! First, let's take a quick look at the Name property from the last article. Things that we want to keep from before: We can see we gave it the name "_name" which is the internal way to refer to that property. We also see we gave it the label "Name" which is how it will be displayed to the user. The Data Type should be a string, because we want to store a short bit of text. Things we want to add: We want to make sure that we never repeat a name, so we check Unique to ensure that each Purchase Order needs to have a different value here. Every Purchase Order needs a name, so we mark Required, which means that a Purchase Order will not be able to be created without having this property filled in. Lastly, go to the Keyed Name Order column. This is used sometimes to display information from system messages, and can make use of multiple columns. Put a 1 here. We have also decided that each Purchase Order should have an phone number associated with it. Most of the time a Purchase Order will have the same number associated with it, that of our purchasing department, but not always. We do want to validate that whatever is entered, it conforms to the structure of a phone number. Let's make a new property for that! Give the property the name "_phone" and the label "Phone Number". Set the Default Value column to that of our fictitious purchasing department, which is "978-555-0101" in this example. Default Value is used to prefill what information will be in a field, so by putting our number there, we make it easy for someone quickly creating a Purchase Order to leave the default there and focus on the novel information. Set the Pattern column to a regular expression matching phone numbers Pattern accepts a regular expression which it will ensure values entered into the property adhere to, so for phone number "d{3}-d{3}-d{4}" will do. A proper explanation of regular expressions could be an entire blog post or more- but fortunately, a blog post on that already exists. Within Aras Innovator, the Pattern column is ideal for validating that the right kind of information has been entered. Advanced Data Types In our example, Purchase Orders sometimes have a particular customer associated with them. We could save half a dozen details about the customer, but there’s an easier way. Something to remember whenever you’re working with Aras Innovator is that almost everything is an item. As such, it’s no surprise that sometimes the most useful thing for a property to store is an item! Make a new property, named "_customer" and labeled "Customer" Give it the DataType of Item. "Customer" is a standard ItemType, and so for Data Source we can open the search dialog by clicking and look up Customer. Select it and click OK. Now all the relevant information about the Customer related to a Purchase Order can be referenced with a single property. What if we need to let users pick from some constrained set of options? Every Purchase Order is made from some country, but if we let users type in any country they like then we’ll wind up with “USA”, “U.S.”, “The United States”, and “America” if we’re lucky. (If we’re unlucky, someone will type “Anreica” and not realize it.) Lists are an existing ItemType, ideally suited to providing dropdown lists for users to select from. Create a new Property named "_country" Give it the label “Country of Origin” Give it the Data Type of "List". Set the Data Source. There's a standard list in Aras Innovator called "Countries" that we can use. Remember that you can combine these, using multiple columns to get the functionality you want. For example, we can the Default Value as Canada, assuming that most purchase orders will be from there. That will pre-fill the field with Canada but still allow a user to change it. It would be nice to have more specific location information than just the country. One powerful technique is combining a List with a Filter List. There's a standard list called States that's configured as a filter list, and contains both U.S.A. states and Canadian provinces. Create a new property named "_province" Give it the Label “Provinces” Give it the Data Type Filter "List". Set the Data Source to your list, in this case the "States" list. Set the Pattern as the property we want to filter on, in this case "_country" By setting the Data Source to the States list, if the country is set to Canada then the user will be able to select from any of the Canadian provinces. If they had picked the United States they would instead be presented with the various states, and the "State"s list can be expanded for any other countries we need to support. You can also change the name of the States list to be Provinces. Like Lists, Sequences are Data Types that reference specific items, with specific behaviors around them. One typical use of a sequence is to provide quick unique values, for example sequential item numbers. Here, lets give our Purchase Order one! Create a new property named "_ponumber" property, labeled PO Number Give it a Data Type of Sequence Give it a Data Source of a sequence you've created. Be sure not to mark this as Required- sequences populate themselves after an item is saved! Go over to the Keyed Name Order we mentioned back when adjusting the name property. Set this to "2" so that system messages will use both the name and the PO number. Conclusions and Congratulations Today, we added a lot of functionality to our Purchase Order Item Type via the power of properties. Purchase Orders now have a lot more information in them, and the same tools we've discussed can be used for even more utility! We also briefly went over some of the various Data Types like Strings or Lists, as well as many of the columns a property can make use of such as Required and Pattern. An Item Type can be as simple or as complex as needed, so next time you're adding a property keep your options in mind. Does this property need to be unique? Does that property need need validation that you can accomplish with Pattern? If you have more questions about this, please do comment below and let us know! Some questions can be answered with a quick comment, and some might be fertile ground for future articles!Aras Fundamentals: Adding Relationships to ItemTypes
In this Fundamentals article, we’ll go over how to add a Relationship to custom or default ItemTypes in Aras Innovator. In a previous Aras Fundamentals blog post, we created an ItemType called Purchase Order. And today we’ll be expanding on that ItemType by adding two new Relationships to it. For our Purchase Orders, we want to be able to add a list of Parts associated with the Purchase Order and add comments to the Purchase Order along the way. The first use case requires adding a Relationship to an ItemType, and in the second case we will add a Null Relationship. What does a Relationship do and why would we want to relate one Item to another, anyways? A Relationship is an Item that connects two Items. Because it’s separated from the source and related Items, it has its own properties, rules and actions – all of which can be customized independently. An Item could link to the most recent version of the related Item or the related Item’s version at the time when the Relationship was made. The specifics of customizing a Relationship’s functionality are beyond the scope of this article, so for now we’ll focus on creating basic Relationships. Adding a Relationship Let’s start by adding a Part List to the Purchase Order. The Purchase Order is going to be used to keep track of the Parts requested by one of our customers, so we need some way to store which Parts have been requested. The easiest way to do this is to add a Relationship pointing to Parts by following the steps below: In the ItemType search grid, search for the Name of the Purchase Order. Open the Purchase Order ItemType and click ‘Edit’. Navigate to the RelationshipTypes tab (next to the Properties tab). Click on the ‘Select Item’ button to define a new RelationshipType. In the search dialog, search for and select the ‘Part’ ItemType by its name. Fill out the table row for the new RelationshipType. Start by specifying the tab order, we’ll put 10 – though this only matters if we have more than one Relationship. In the Name column, enter ‘Purchase Order Part’. A typical naming convention for RelationshipTypes is to use the source and related ItemTypes’ names. Enter 'Part List' in the Tab Label field. This will be the name of the tab that the user sees when editing the source item. Save and Unclaim the Purchase Order ItemType by clicking on ‘Done’. For each RelationshipType that is created, a Relationship ItemType of the same name will be automatically made. We can add properties and behavior to this ItemType to change the characteristics of the Relationship, as needed. For this Relationship, we don’t need to add or change anything, so let’s continue onwards. Adding a Null Relationship Now let’s look at adding a Null Relationship to our Purchase Order ItemType. In a Null Relationship, the RelationshipType has a source ItemType, but no related ItemType. This RelationshipType structure is useful when we need to track items that pertain only to the source item and won’t be reused. For example, we want to add a way to attach comments to our Purchase Orders. The steps to create a new Null Relationship are: While editing the ItemType, navigate to the RelationshipType tab. Click on the ‘Add Row’ button to get a new blank row. Note that the far-left column has the ‘Null Relationship’ icon. Fill out the table row. Start by specifying the tab order as 20. This will make the Comments tab come after the Part List tab. Enter ‘Purchase Order Comments’ as the name for the RelationshipType. A good naming convention is to use the source ItemType’s name and a descriptive name of the new Relationship. Enter the Tab Label, we’ll set this to ‘Comments’. The name column stays blank for a Null Relationship. Save and Unclaim the ItemType by clicking ‘Done’. We want this Relationship to record comments, so we need to add a property to the Relationship to hold that information. Here are the steps to add a comments property to the ‘Purchase Order Comments’ Relationship ItemType: In the ItemType search grid, search for ‘Purchase Order Comments’, which was just created when we saved the parent ItemType. Open the Relationship ItemType and click on the ‘Edit’ button. Optionally, we can add singular and plural labels to make the table title clearer. In the Properties tab, click the ‘Add Row’ button. Name the property ‘_comment’. The underscore isn’t necessary, but it’s an easy way to distinguish system-made properties from ones we’ve added. Change the Label to something more readable, like ‘Comment’. This will be the table header in the Relationship’s tab. Select Text for the Data Type of the property. The comment will be sequence of text without a set length, so the best option here is Text. That way, users can write as much as they need to without being constrained by a character limit. Make the property visible to the user, by ensuring the boxes under ‘Hidden’ and ‘Hidden2’ are unchecked. Optionally, set the default Width of the column to a value like 200 so more of the comment can be read in the table. Save and Unclaim the ItemType by clicking ‘Done’. Default Structure View Let’s test out our new RelationshipType by opening a Purchase Order for edit. And … hm, we can’t see the Relationship tabs. Oh, of course, we forgot to enable the view for the Purchase Order ItemType. That’s an easy fix; we just need to enable the source ItemType to show Relationship tabs when an Item is opened. To do this, we’ll open the Purchase Order ItemType for editing, click on the Default Structure View drop down menu and select ‘Tabs On’. We can then save the changes. Here’s a list of the Structure View options and what they mean: ‘Tabs On’ will display all relationship tabs if there are any associated with the ItemType. ‘Tabs Off’ is the Aras Innovator default and hides the Relationship tabs from the accordion section of the Item. ‘Tabs Min’ adds the relationship tabs to the accordion section but defaults it to closed. ‘Tabs Max’ is currently the same as ‘Tabs On’ but may change functionality in the future. Now that we can see the Relationships for this ItemType, we can test the new RelationshipTypes by adding them to a Purchase Order Item. Open a Purchase Order Item for editing. Add a Part Relationship Item by clicking on the ‘Parts List’ tab. I have a premade Part to use, so we’ll click the ‘Select Items’ button and search for the Part, highlight it by clicking on it, and hit ‘OK’ to add the Relationship. If you're following along and don't have a premade Part, you can click the 'Create Item' button to add a new Part on the fly. Add a Null Relationship Item by clicking on the ‘Comments’ tab. Click on ‘Add Row’ and fill out the values with our comment. We’re done adding Relationships to this Item, so we can Save and Unclaim the Purchase Order by clicking 'Done'. In Conclusion That’s all we need to do to add Relationships to ItemTypes. We also learned when to use standard Relationships versus Null Relationships. The series of Aras Fundamentals blog posts should help with mastering essential techniques for developing in the Aras Innovator system.
