Question

Documenting our custom fields

  • 19 May 2023
  • 2 replies
  • 175 views
R
Rank
Badge +2

Hey everyone,

I have been tasked with documenting our customizations and configurations and I am hoping the community can help with something.

 

I am starting with our custom fields.  The idea is to hand a document over to the business and have them tell us if the field is still needed/used. In order for the business to make that decision, they will need to know every instance of use of that custom field.  I am trying to track down any and everything that has a dependency on the custom field.  We want to ensure that we do not break anything the business is still relying on by getting rid of the custom field.

Basically, anything “downstream” of the custom field that is dependent on the existence of the custom field.   For example:

  • Events/Event Actions that use the custom field
  • Lobby Data Sources 
  • Database packages, stored procedures, functions, etc.
  • All types of reports
    • Operational Reports
    • Quick Reports
    • Crystal Reports
    • etc.
  • Custom Menus
  • Custom Pages and Tabs
  • Other custom fields 
    • Read Only fields that use the first custom field in its select statement or expression
    • etc.  
  • Custom Views 
  • Custom Tables
  • Migration Jobs
  • External File Templates
  • IAL’s 
  • Again, anything that may be using the custom field (I’m sure I left something off the list)

 

Does anyone have ideas about the best way to go about gathering this type of information?  Has anyone done something similar to this in the past, and if so, any pointers or suggestions you would be willing to share?  

I would really appreciate any ideas, strategies, best practices that may help!

**I’m really hoping there is a standard way to do this and I just don’t know about it**

 

Thanks

Royston

2 replies

B
Rank
Userlevel 5
Badge +15

HI @Royston.McKaig 

I have been tasked with something similar, but I’ve been on the developer side of this. The best way I’ve found when going about this, has sadly been to document everything while it’s being developed. This doesn’t help you but we haven’t found an easy way to approach this issue either. IFS Cloud lets you see the custom attributes and entities you’ve created and configured, configured/custom projections, the workflows and database tasks you’ve created, and even the page modifications you’ve made, but other those, there is no easy solution to see this. 

I believe IFS Cloud should incorporate more “application configuration packages” type of items to their platform so environment cloning, updating, etc can be done seamlessly. Application configuration packages allow for certain items to be added and tied together into a package, that can be downloaded and uploaded to another platform, allowing for easy migrations of configurations.

 

Thanks,
Bryan

B
Rank
Userlevel 6
Badge +11

I have had similar battles since I joined my company after IFS had gone live and there were significant config made without documentation. 
 

Going forward, it’s all documented and kept together in application config packages.

 

What I have done is used a pl/sql query to find any API that references each custom field, also extracting event actions and quick reports where the fields are used. I then put them into a package and document.

There’s also a community post out there that really helped me where any quick report or event action it’s writing to a log so I can see what is and what is not being used 

Reply


Terms & ConditionsCookie settings