Archer Development Standards (aka Things That Annoy the Admin list)

Hi,

I know that there was a 2015 Charge presentation by Mark Klimesh and Brian Olberz on this topic at least once, but I have developed some additional ones and would love to hear what else you have to add:

• When in doubt about a requirement, please ask during development, rather than assuming what the business wants only to discover the misinterpretation during testing which leads to another cycle
• When there are several options on how to accomplish something, have a long term perspective in terms of the ongoing maintenance involved and try to simplify that as much as possible
• Make sure there are not extra spaces before or after the field name
• Document all changes to the point that when there are errors or warnings during the package installation during migration, none of them should come as a surprise and all of them can be traced back to the list
• Avoid referencing a text field in a DDE as the criteria (if the value changes, the DDE breaks until you go reconnect it to the new value)
• All Objects must have a description (Solutions, Applications, Fields, Subscription Notifications, DDEs, Workspaces, Dashboards, iViews, etc)
• All descriptions should focus on the why even more so than the what
• All new objects added for our company should include <Added forCompanyName> at the beginning of the description
• All OOB objects that are modified for our company should include <Modified OOB> at the beginning of the description plus include any changes to what was there previously
• All notifications should use the our company logo letterhead, not the default RSA one
• Inactive fields should not be searchable
• Inactive field names should be prefixed with a "z"
• All applications should have an active History Log field but by default should not include all fields and should not be limited to a certain number of records or time period. The fields populated should be agreed upon with the business based on their needs plus any fields IT will need to troubleshoot.
• Before creating a new DDE, confirm that there isn't already an existing one (either Active or Inactive) one that serves the same purpose or could be modified slightly to meet the requirements
• Name the DDE Rule by what it's evaluating (not based on the action that they are triggering)
• Name the DDE Action by what it does
• DDEs should not be numbered since sometimes there could be many to many relationship between the Rules and the Actions

a community member, Scott Hagemeyer, will you be so kind to add your list when you find them??