One common complaint about the API is that it is poorly documented. I found that out myself when I went to use the gift filter object. This is a powerful object that allows you to filter a collection of gifts by its properties. The filter object has very many properties but very few of them are documented. There is one knowledgebase article and one FAQ entry showing how to use it.
Continue reading Filtering on Gifts
One issue that I frequency encounter was raised as a post on the forum for a similar problem:
When you create a gift you need to add a fund, campaign and appeal. The problem is that the values on the gifts are dependant on the user options of the person running the code. When I first encountered this problem I was amazed that this could have been programmed in this way.
Continue reading Adding Gifts Means Thinking User Options
One thing that can make the API confusing is its inconsistencies. Take for example the task of referencing the constituent object’s system id from another data object. The constituent system ID is used uniformally throughout to connect a constituent to its child objects such as, gifts, actions, aliases, solicit codes, etc. The naming convention however is not uniform. The objects have fields which are referenced in the following format:
OBJECTNAME_fld_FIELDNAME
so that an action references the constituent that is tied to it by the following:
oAction.Fields(ACTION_fld_RECORDS_ID)
Continue reading Six ways to name a record