Is there an existing feature request for this?
Describe the Feature
Currently the recurly__account_overview and recurly__account_daily_overview end models include all accounts within the Recurly implementation. However, it has come to our attention that a number of Recurly customers only care about the accounts with a subscription, which is ~1/4 of the entire account population. This is likely a common pattern with companies with a free-tier plan.
As such, a proposed feature would be to add a filter to the above mentioned models that filter out any accounts that are not tied to an active subscription. In order to do this, we will need to apply a join between the account_history and the subscription_history models before rolling up into the final end models to then filter out any non-matches. This would likely be best fascilitated within an intermediate model that could possibly have a recurly__using_active_accounts (or something of the sort) variable that will allow users to leverage the filter or the default behavior of the package.
Describe alternatives you've considered
No alternatives at the moment. Customers may apply the join and filter after the package has run, but this still requires the models to run and incur costs they otherwise would wish to not have to take on.
Are you interested in contributing this feature?
Anything else?
This was originally raised within Issue #
Is there an existing feature request for this?
Describe the Feature
Currently the
recurly__account_overviewandrecurly__account_daily_overviewend models include all accounts within the Recurly implementation. However, it has come to our attention that a number of Recurly customers only care about the accounts with a subscription, which is ~1/4 of the entire account population. This is likely a common pattern with companies with a free-tier plan.As such, a proposed feature would be to add a filter to the above mentioned models that filter out any accounts that are not tied to an active subscription. In order to do this, we will need to apply a join between the
account_historyand thesubscription_historymodels before rolling up into the final end models to then filter out any non-matches. This would likely be best fascilitated within an intermediate model that could possibly have arecurly__using_active_accounts(or something of the sort) variable that will allow users to leverage the filter or the default behavior of the package.Describe alternatives you've considered
No alternatives at the moment. Customers may apply the join and filter after the package has run, but this still requires the models to run and incur costs they otherwise would wish to not have to take on.
Are you interested in contributing this feature?
Anything else?
This was originally raised within Issue #