Application Launcher

Area	AgilOne JIRA	Description of functionality after the fix
Actions	AGO-9078	In Actions we are now exposing the recently created phone validity flags for primary, secondary, and mobile phones within the United States and Canada. For clients that exclusively do business in the US and Canada you can utilize these flags to understand whether a customer’s phone number is valid or invalid and perform text marketing phone calls appropriately.
Metrics: Cube Reports	AGO-10638	Filter conditions in Cube Reports were not being honored under certain conditions when dimensions were moved from Rows/Columns area to Filters area. We’ve fixed this bug to always honor all filter conditions correctly.
Metrics: Cube Reports	AGO-10863	We experienced a bug where the “Connect from Excel” button was not downloading an Excel file as expected. We’ve fixed it as part of the release.
Metrics: Fiscal Calendar	AGO-10561	We have updated our fiscal calendar processes to be more configurable. For an additional fee we can now configure a second fiscal calendar alongside the original fiscal calendar. Such a configuration should undertaken only after very careful consideration because two fiscal calendars can be confusing to the user and lead to a bloat of options within AgilOne.
Platform	AGO-10576	AgilOne has made it easier to configure changes to the many default buckets, or ranges, that are grouped in AgilOne’s nightly refresh process. For example, the default buckets for days since last transaction are: ‘Less than 1 month’, ‘1 to 3 months’, ‘4 to 6 months’, ‘7 to 12 months’, ‘13 to 24 months’, and ‘More than 24 months’. Configuring this bucket to be unique for a client’s specific needs was achieveable before, but is now much easier to accomplish. Any attribute that ends with ‘group’ is performing bucketing that should be configurable.
Platform: DQE	AGO-9961	AgilOne is now making our master customer primary keys (MasterCustomerIDs) semi-persistent by calculating them directionally. AgilOne will now choose the earliest ingested child customer primary key (CustomerID or SourceCustomerNumber) as the default MasterCustomerID. MasterCustomerIDs are only semi-persistent because master customers can break apart, or separate, if additional information is ingested about a child customer that causes a breakout scenario. Additionally, by default we are now limiting the size of a master customer to 5,000 child customers, in order to avoid performance bottlenecks that can block data processing. During AgilOne’s de-duplication process, if a master customer exceeds 5,000 child customers we are no longer de-duplicating the >5,000th customer into the master customer. Such large master customers are extremely unlikely in the real world, but are generally caused by upstream data issues. When these very large master customers exist the can cause performance bottlenecks within AgilOne that prevent the nightly refresh from succeeding.

1811 Release - 2018-04-10