In my previous blog, Can You Add a CRM Field Please, I offered questions to help you engage with your CRM users to validate the need for a field.  Now let's take the next step, field creation! 

From New CRM Field Request to CRM Design

To do this, you'll need to translate the answers to your questions into a plan for CRM design. Below is the list of questions from the last blog, as well as thoughts on how the answers may translate into CRM design requirements.

• What is the business need for this field? You are trying to get the business to fess up regarding if this field is really needed or not. If they can’t answer this question there is not a point in continuing with the other questions. Although there is not a functional equivalent specifically for this question, it is a foundation question that will frame the other questions, their answers and any follow up. Is this part of a new process or an existing process? If it is part of a new process then it might be a sign of additional fields at the least and a new process, more likely, to come. If it is a new process, dig deeper and find out more about the new process and where it fits into existing processes. If it is being added to an existing process, find out how it fit and where it goes. This will indicate possible placement on forms, views, business processes flows, and charts.
  
  
• How has the business been managing this data point before now? This will help you determine if the rest of that process needs to be explored in regard to adding it to CRM. Consider this a reframing of the previous question to both, verify you got the information you needed, and get more of the field's story. If this is an existing process, within CRM or not, this will help determine if the rest of the process needs to be modified. Regardless of if the data is currently stored on paper or a spreadsheet, or even a field in CRM misappropriated to the requestor or another group of users, they are expecting the field to be there in its current state. So changes to it could effect a variety of people and processes. Which means another group may need to be included in the conversation if that field is currently managed by another part of the business. Similar to the above question answers to this question will indicate possible placement on forms, views, business processes flows, and charts.
  
  
• How long will it be used? If this is a onetime thing, is CRM really the right place for it? The answer may still be yes based on things like proximity to other relevant data or the profile of the data (to whom is this important?). It could be that it is a value in a field not an actual new field. For example a group wants to keep track of leads that are coming in for a specific show. That would be better served as a lead source then a whole new field. That way the business can review those leads and their viability against other leads from other sources.
  
  
• Who will use it? The answer to this question has a variety of implications. If only a specific functional group, it could mean modification of just their form if you have multiple forms, or modification of their area of the form if all groups are using the same form. In the same vein, if they have views specific to them it could mean modifying just their views or the views everyone uses. And if modifying the views, or charts everyone uses, will it be disruptive to that group if it is between specific columns? The other groups may not care about this field. And then there's the consideration of security. If only a specific group needs the field does that mean others can't see it (a security consideration) or just do not need to see it (an obfuscate consideration). Security consideration means security roles or field level security needs to be evaluated. Obfuscate means putting it on some forms or views but not all or possibly having it hidden/displayed using business rules and existing data. More on security later.
  
  
• How will the data get added? Are users going to be adding through the user interface (UI)? If so, this means it needs to be on a form somewhere so they can get to it. Will a process in the back ground be auto filling it based on other fields or will it be imported or is it part of an integration? If so, there may need to be field level security or setting it to read only on the form or only adding it to views so users cannot modify it. More on the integration question next.
  
  
• Will this field be integrated with another system? Will the data be created in CRM and pushed to another system or will it be pushed from the other system to CRM? Will it be a one or two way integration meaning can the data be updated just in one system and pushed to the other system or can the data be updated in both systems and that update be pushed between the systems? Which is the system of record? Another way to think of system of record is, if one of the systems got destroyed and this field survived, which system was it in? Go deeper on this one regarding how the integration will work such as, is it batched or real-time as the record is changed? What initiates a record being pushed from one system to the other? Is the whole record over written or just the field that was changed? If a record is changed in both systems at a time close to each other how does the integration manage the change in each of the records?
  
  
• Can every user see, edit, create this data? This is part of the security question I alluded to earlier. If not every user can CRUD (create, read, update, delete) the value in a field then a decision needs to be made regarding the level to which that needs to be managed. If other users can see it but not edit it, but it is not a field of super importance then read only on certain forms or only displaying in views might be enough. But if users can export/import data those measures are not enough for some fields because there may not be security there to prevent them from modifying it and re-importing it. This is the discouragement approach, relying on users that are focused on their own thing. If this is a field only specific users or a group of users can work with, field level security is an option where you can manage create, read, update/delete. But if there are certain values within the field that can be seen or edited, consider creating an entity and manage security through it. Think a lookup to account where the user can only see their own accounts. The user will only be able to choose their own accounts in that lookup. This would be managed through updating security roles the users already have or updating security roles created based on special circumstances such as a power user.
  
  
• Will this data need to be added to any forms, views, or charts? If this question has not already been answered during one of the previous questions, now is your chance! If it needs to be added to forms and there are multiple forms should it be added to all the forms or just some? And where should it be added? If the field is going in between existing fields rather than at the bottom or top of a list of fields then it may mean other fields will be disrupted. An odd thing to consider regarding field placement is whether tabbing to this field from the field before it break the data entry flow to the next field and if it is, how disruptive? Disrupting a user that primarily reads data and rarely enters data is different than disrupting someone whose job is dependent on moving smoothly through the data entry process. If adding to a view does it need to be one, some or all views? Which ones? Does it need to be added just to the entity views where it is being created or does it need to be added to a related entities view? How wide should the column be? Will the view use it for sorting? Between what columns should it go? These would be set within the view itself. If you are using inline editing does this field need to be added to the inline view configuration for those views? These are managed at the entity level. If adding to charts, are you changing or adding to the series (legend entries (series)) or the category (horizontal (category) axis labels)? Or will this be a brand new chart? If brand new, what type of chart? Is it a top or bottom chart meaning does the business only want to see the first x number or the last x number of records displayed in the chart?
  
  
• Is this data something users will use in searches? If so, does it need to be added to the find fields, the view fields or both? Used for entity and global search, every entity has a quick find view and I find it to be one of the most neglected views when making updates to CRM.
  
  
• Are there any data integrity rules? Are there only certain values accepted for this field? If so, option sets or lookups may manage your data. Otherwise business rules could be used if the field is conditionally required or for some format checking. You could also use business rules to display a message if the data is in the wrong format for some cases.
  
  
• Is it required? Is it required conditionally? If the field is required all the time, the requirement level can be set at the field level, if it is required conditionally, business rules and business process flows can but used.
  
  
• Are there only certain values that should be allowed? If there are only a few values allowed and do not require additional security, options sets could work. If you are using a lookup field but only a certain type, a view on that entity can be created and used that displays only those specific values.
  
  
• Is the data in this field related to data in other records in the system? Odds are good you have already asked this question in another way before this. But this is another reframing question. It could mean adding the field to a related entity's view, updating the one to many (1:N) or many to one (N:1) relationship so that when a related record is created from the record where the new field is added, that field will autofill into the related entity record. If it is part of a group of data that is displayed in a quick view on a related entity it may mean updating that quick view.

Please note: This is not meant to be an exhaustive guide but a good foundation to get you thinking and administering. Also I have been mindful to keep Word templates, Excel templates, Dialogs, Workflows, JavaScript, Plugins, SQL Reporting Services, Power BI, Flow, other forms of custom development and the cornucopia of additional solutions out of this list. However these should be items for consideration when adding a field and also for managing that field.

Wow, that is quite a list and that is just skimming the surface! I hope this will help you in your quest to be a good steward of CRM.