# Add Balance To Member
Source: https://docs.fieloloyalty.com/api-reference/add-balance-to-member
/api-reference/Loyalty-App-Open-API-Spec_Swagger.yaml patch /dx/api/application/v2/objects/STE6TG95YWx0eV9fTWVtYmVyXzY4OWUxMTk1ZjY4MTRmMDBhNjg5MjJlZA/actions/AddBalance
# Add Reward Stock
Source: https://docs.fieloloyalty.com/api-reference/add-reward-stock
/api-reference/Loyalty-App-Open-API-Spec_Swagger.yaml patch /dx/api/application/v2/objects/STE6TG95YWx0eV9fUmV3YXJkXzY4OWRmMWM0ZjY4MTRmMDBhNjg5MjI1Ng/actions/AddRewardStock
# Create Member
Source: https://docs.fieloloyalty.com/api-reference/create-member
/api-reference/Loyalty-App-Open-API-Spec_Swagger.yaml post /Member/dx/api/application/v2/objects
# Create Product
Source: https://docs.fieloloyalty.com/api-reference/create-product
/api-reference/Loyalty-App-Open-API-Spec_Swagger.yaml post /Product/dx/api/application/v2/objects
# Create Redemption
Source: https://docs.fieloloyalty.com/api-reference/create-redemption
/api-reference/Loyalty-App-Open-API-Spec_Swagger.yaml post /Redemption/dx/api/application/v2/objects
# Create Reward
Source: https://docs.fieloloyalty.com/api-reference/create-reward
/api-reference/Loyalty-App-Open-API-Spec_Swagger.yaml post /Reward/dx/api/application/v2/objects
# Create Sale
Source: https://docs.fieloloyalty.com/api-reference/create-sale
/api-reference/Loyalty-App-Open-API-Spec_Swagger.yaml post /Sale/dx/api/application/v2/objects
# Create Segment
Source: https://docs.fieloloyalty.com/api-reference/create-segment
/api-reference/Loyalty-App-Open-API-Spec_Swagger.yaml post /Segment/dx/api/application/v2/objects
# Create Store
Source: https://docs.fieloloyalty.com/api-reference/create-store
/api-reference/Loyalty-App-Open-API-Spec_Swagger.yaml post /Store/dx/api/application/v2/objects
# Delete Product
Source: https://docs.fieloloyalty.com/api-reference/delete-product
/api-reference/Loyalty-App-Open-API-Spec_Swagger.yaml patch /dx/api/application/v2/objects/STE6TG95YWx0eV9fUHJvZHVjdF82ODlkZTM4MWY2ODE0ZjAwYTY4OTIyMmY/actions/DeleteObject
# Delete Reward
Source: https://docs.fieloloyalty.com/api-reference/delete-reward
/api-reference/Loyalty-App-Open-API-Spec_Swagger.yaml patch /dx/api/application/v2/objects/STE6TG95YWx0eV9fU3RvcmVfNjg2N2UyNDFjOGJmZDE3ZGQ3ZDQ2NDBj/actions/DeleteObject
# Delete Store
Source: https://docs.fieloloyalty.com/api-reference/delete-store
/api-reference/Loyalty-App-Open-API-Spec_Swagger.yaml patch /dx/api/application/v2/objects/STE6TG95YWx0eV9fU3RvcmVfNjg5ZGUzMTdmNjgxNGYwMGE2ODkyMjFj/actions/DeleteObject
# Get Ledger Entries Between Dates
Source: https://docs.fieloloyalty.com/api-reference/get-ledger-entries-between-dates
/api-reference/Loyalty-App-Open-API-Spec_Swagger.yaml post /dx/api/application/v2/data_views/LedgerEntriesBetweenDates
# Get Member By ExternalID
Source: https://docs.fieloloyalty.com/api-reference/get-member-by-externalid
/api-reference/Loyalty-App-Open-API-Spec_Swagger.yaml post /dx/api/application/v2/data_views/MemberByExternalID
# Get Product by Product Code
Source: https://docs.fieloloyalty.com/api-reference/get-product-by-product-code
/api-reference/Loyalty-App-Open-API-Spec_Swagger.yaml post /dx/api/application/v2/data_views/GetProductByBusinessKeys
# Get Program List
Source: https://docs.fieloloyalty.com/api-reference/get-program-list
/api-reference/Loyalty-App-Open-API-Spec_Swagger.yaml post /dx/api/application/v2/data_views/ProgramList
# Get RedemptionItem by Voucher Code
Source: https://docs.fieloloyalty.com/api-reference/get-redemptionitem-by-voucher-code
/api-reference/Loyalty-App-Open-API-Spec_Swagger.yaml post /dx/api/application/v2/data_views/RedemptionItemsByVoucherCode
# Get Reward By ExternalID
Source: https://docs.fieloloyalty.com/api-reference/get-reward-by-externalid
/api-reference/Loyalty-App-Open-API-Spec_Swagger.yaml post /dx/api/application/v2/data_views/GetRewardByBusinessKeys
# Get Store by Store Code
Source: https://docs.fieloloyalty.com/api-reference/get-store-by-store-code
/api-reference/Loyalty-App-Open-API-Spec_Swagger.yaml post /dx/api/application/v2/data_views/GetStoreByBusinessKeys
# Lock Voucher Code
Source: https://docs.fieloloyalty.com/api-reference/lock-voucher-code
/api-reference/Loyalty-App-Open-API-Spec_Swagger.yaml patch /dx/api/application/v2/objects/STE6TG95YWx0eV9fUmVkZW1wdGlvbkl0ZW1DYXNlXzY4OWUxNzMwZjY4MTRmMDBhNjg5MjM1MA/actions/Lock
# Mark Segment Active
Source: https://docs.fieloloyalty.com/api-reference/mark-segment-active
/api-reference/Loyalty-App-Open-API-Spec_Swagger.yaml patch /dx/api/application/v2/objects/STE6TG95YWx0eV9fU2VnbWVudENhc2VfNjg5ZTExZTkxZGQzOTQyZjgxMTYzNjY3/actions/MarkAsActive
# Mark Segment Inactive
Source: https://docs.fieloloyalty.com/api-reference/mark-segment-inactive
/api-reference/Loyalty-App-Open-API-Spec_Swagger.yaml patch /dx/api/application/v2/objects/STE6TG95YWx0eV9fU2VnbWVudENhc2VfNjg5ZTExZTkxZGQzOTQyZjgxMTYzNjY3/actions/MarkAsInactive
# Update Product
Source: https://docs.fieloloyalty.com/api-reference/update-product
/api-reference/Loyalty-App-Open-API-Spec_Swagger.yaml patch /dx/api/application/v2/objects/STE6TG95YWx0eV9fUHJvZHVjdF82ODlkZTM4MWY2ODE0ZjAwYTY4OTIyMmY/actions/Edit
# Update Store
Source: https://docs.fieloloyalty.com/api-reference/update-store
/api-reference/Loyalty-App-Open-API-Spec_Swagger.yaml patch /dx/api/application/v2/objects/STE6TG95YWx0eV9fU3RvcmVfNjg5ZGUzMTdmNjgxNGYwMGE2ODkyMjFj/actions/Edit
# Use Voucher Code
Source: https://docs.fieloloyalty.com/api-reference/use-voucher-code
/api-reference/Loyalty-App-Open-API-Spec_Swagger.yaml patch /dx/api/application/v2/objects/STE6TG95YWx0eV9fUmVkZW1wdGlvbkl0ZW1DYXNlXzY4OWUxNzMwZjY4MTRmMDBhNjg5MjM1MA/actions/Use
# Badges
Source: https://docs.fieloloyalty.com/build/badges
Coming soon
Badges are recognition rewards that show off members' wins or accomplishments in a visual way. They can be given through incentive rules or administratively. They can be granted on a lifetime basis or for a defined period of time.
### Add a Badge
A badge has a name, description, and image URL. Badge images typically have a 1:1 ratio and a transparent background.
### Give a Badge via Incentive Rule
A badge can be given as an incentive reward. The badge expiration policy is defined on the incentive rule.
If a badgeholder earns a badge again, the badge expiration date is extended to reflect the expiration policy on the most recent earn date. If this would result in an earlier expiration date on an existing badge holding (such as due to a rule change), no change is made.
### Give a Badge Administratively
Admins can grant a badge manually and set its expiration date for that particular badge holding.
### Target Incentives to Badgeholders
You can set incentive eligibility based on members' badge holdings.
# Caps
Source: https://docs.fieloloyalty.com/build/caps
A cap defines a periodic limit to the number of times a member can be rewarded for a certain kind of activity in the program. When a member exceeds a cap, the member's status changes to *Resolved-BlockAccruals*, meaning he or she is blocked from further accruals.
### Add a Cap
To configure a cap, navigate to the Caps page and select **Create Cap**. In addition to a name and description, caps have the following attributes:
* *Suspension Mode (hours)*: **Temporary** means that, when a member is blocked due to exceeding a cap, the suspension will be automatically lifted after a defined number of hours, while **Indefinite** means that the member's suspension will need to be removed administratively.
* *Suspension Time*: When the suspension mode is temporary, this is the amount of time (in hours) that the member will be blocked.
* *Limit*: Required. The number of activities a member can perform inside the measurement period before being blocked.
* *Measurement Period (hours)*: The rolling period inside which the limit will be measured. For example, if the value is `5`, members will be blocked if they exceed the limit by the number of scoped activities they've performed within the last 5 hours. If the measurement period is blank, the limit applies over the lifetime of the program.
### Define a Scope
Once a cap has been created, you can set its scope. The scope defines the kind of activities that will fall under a given cap. Caps are scoped by [Data Set](/build/datasets).
You can select one or more data sets, or choose *All Data* if the cap will be applied across all activities inside the program. When you're ready, be sure to confirm your selection by clicking "Submit".
### Whitelist
There may be a handful of members you wish to exclude from your cap. If this is the case, you can add them to the whitelist now or at any time in the future. Continue by selecting "Submit".
### Activate a Cap
Once you've set the policies, defined a scope and, optionally, added members to the whitelist, you can go ahead and activate your cap.
From the three-dot menu, choose "Mark cap as active".
### Statuses
Caps can be in one of three statuses:
* *Open-Draft*: The cap is in the process of being built. It needs to be activated before it will start to be enforced.
* *Open-Active*: The cap has been activated and its policies will be enforced.
* *Resolved-Inactive*: The cap has been deactivated and its policies will not be enforced.
# Data Sets
Source: https://docs.fieloloyalty.com/build/datasets
A data set defines a structured flow of data that will be tracked and incentivized upon. Fielo Loyalty comes with two data sets out of the box:
* *Sale*: Represents a sale that has been finalized by a member. It can contain one or more sale items.
* *Event*: Represents an event that is based on a calendar occurrence (e.g. birthday, program anniversary) or received from an external system (e.g. spin-and-win result).
### Criteria
You can refine what data from your data set is eligible to be incentivized by adding criteria. When doing so, only data that passes through this filter will be processed against your program's incentive rules.
To add or modify a data set's criteria, access the three-dot menu from the details pane and select **Edit Criteria**. From there, you can add one or more criteria to filter based on the available attributes of the object type. You can also specify whether *All criteria must match* or *Any criterion can match*.
### Statuses
Data sets can be in one of two statuses:
* *Open-Active*: Input data related to this data set will be processed.
* *Resolved-Inactive*: Input data related to this data set will not be processed.
# Event Schedules
Source: https://docs.fieloloyalty.com/build/event-schedules
Event Schedules create Events on or before key dates on members' profiles, such as birthdays and program anniversaries. This enables you to configure incentive rules that reward members around such commemorative dates.
## Add an Event Schedule
To configure an event schedule, navigate to the Event Schedules page and select **+**. In addition to a name and description, event schedules have the following attributes:
* *Type*: **Anniversary** means that events will be generated on or before members' program anniversary (*Join Date Time* field). **Birthday** means that events will be generated on or before members' birthday (*Date of Birth* field).
* *Offset (in days)*: The number of days ahead of the commemorative date that events should be generated. To have events created on the day of, enter `0`.
## Schedule Event Creation
By default, events are created daily at 3:00 AM GMT.
To change the run time or frequency, click on your initials on the top right and choose *Administration*. On the left navigation, under Configurations, select *Application Configuration*.
Click on **Daily Event Creation**. In the three-dot menu near the top right of the page, choose *Override*. (If someone has already done this before, there's no need to override again.)
Make the desired changes and save.
If event creation is scheduled for more than once per day, incentive rules may reward members multiple times for the same commemorative date. Typically, this is only desirable when testing.
In production, schedule this job to run, at most, once daily.
# Incentives
Source: https://docs.fieloloyalty.com/build/incentives-config
Incentives contain the rules that define how members get rewarded for participation in your program. They can be open-ended or timebound. They can be for all members or only a subset of members. They can reward outcomes, like sales or tier upgrades, or on a time schedule, like birthdays or program anniversaries. Rewards can take the form of virtual currency, like points, or instant rewards, like catalog items or vouchers.
## Configure an Incentive with AI
You can brainstorm and create an incentive by chatting with Fielo AI. On the right side of the Incentives page, simply start a conversation around your incentive idea.
The agent will ask for any missing information and confirm all details before creating your incentive. Once your incentive is created, you'll need to review it and then activate it.
## Configure an Incentive Manually
To start building an incentive, navigate to the Incentives page and select **Create Incentive**. In addition to a name and description, incentives include the following attributes:
* *Program*: Only members of this program will be rewarded through the incentive.
* *Start Date Time*: If the incentive is timeboxed, this is the start date and time. For open-ended incentives, this will be blank.
* *End Date Time*: If the incentive is timeboxed, this is the end date and time. For open-ended incentives, this will be blank.
* *Segments*: The segment(s) that will be eligible to be rewarded through the incentive. If the incentive is for all members, leave this empty. If you select multiple segments, any member who is in at least one of them will be eligible.
### Add a Rule
With your incentive created, you can now add a rule. To do so, click on the **+** icon above the *Incentive Rules* list.
In addition to a name and description, rules include the following attributes:
* *Source Data*: The data set corresponding to the behavior you want to incentivize, such as Sale or Event.
* *Criteria*: The criteria that the member's behavior must meet in order for it to apply to the rule. Criteria are built upon attributes available on your source data. For example, if your rule only applies to sales over \$50, the criterion will look something like `Net Amount greater than 50`.
* *Criteria Logical Expression*: Determines whether **All criteria must match** for the rule to be applied, or **Any criterion can match**.
* *Type*: **No Competition** rules always reward qualifying members, whilst **Best Option** rules only give a currency to a qualifying member if no other Best Option rule applies which would give the member more of that same currency. In the event two rules would give the member the same amount of currency, the one with the more generous expiration policy prevails. Instant rewards are always given regardless of rule type. If left unselected, "No Competition" is assumed.
### Specify a Reward
Finally, you can specify what the rule will reward to qualifying members. No Competition rules can give currency and instant rewards, while Best Option rules can only give currency.
Currency rewards require the following:
* *Conversion Mode*: **Fixed Value** means the amount given will be the same for all members, while **Multiplier** means the amount given will be a multiple of a numeric attribute of the incentivized activity and **Divisor** means the amount given will be a quotient.
* *Conversion Value*: If "Fixed Value" is selected, this is the amount of points to be given. If "Multiplier" is selected, this is the amount by which the Source Value Field will be multiplied in order to calculate the member's reward. If "Divisor" is selected, this is the amount by which the Source Value Field will be divided in order to calculate the member's reward.
* *Source Value Field*: If "Multiplier" or "Divisor" is selected, this is the attribute that will be multiplied or divided by in order to calculate the member's reward. The attribute must be a numeric field from the source data.
* *Expiration Mode*: Currency can be set to expire in a number of **Hours**, **Days** or **Months** from the moment it was earned, on a **Specific Date**, or annually on a **Recurring Date** (e.g. every year on 1st Jan). It can also be set for **No Expiration**.
* *Units Until Expiration*: If "Hours", "Days" or "Months" is selected, this is the number of hours, days or months members will have to use the currency they earn through this rule.
* *Expiration Date Time*: If "Specific Date" or "Recurring Date" is selected, this is the date (either specific or annual) that the currency given through this rule will expire.
* *Expiration Resolution*: **Full Day** means that, on the last day their currency is valid, members will have the entire day to use it, whilst **Exact TIme** means the currency will expire at the same time of day as it was earned.
Instant rewards require the following:
* *Reward Mode*: **Fixed Value** means the reward given will be the same for all members, while **Specified by Field** means the reward will be indicated by an attribute of the incentivized activity.
* *Reward*: If "Fixed Value" is selected, this is the catalog reward that will be granted.
* *Source Reward Field*: If "Specified by Field" is selected, this is the attribute that will indicate the catalog reward to be granted.
## Activate an Incentive
Once your rules are ready, you can activate your incentive from its detail page. Review the pending step(s) and click **Submit**.
For each incentive rule, there is a deployment process that needs to complete before it can become *Open-Active*. You can check the process' status on the Deployments page. Even when the deployment has finished, it may still take a few more minutes for the status of the incentive rule to reflect this.
Whenever you make a change to the criteria of an incentive rule, a new deployment will be initiated.
For incentives with a start date/time in the future, be assured that even in *Open-Active* status, your incentive rules will only begin granting rewards at the defined start date/time.
## Statuses
Incentives can be in one of three statuses:
* *New*: The incentive was created via AI and requires review prior to activation.
* *Pending-Define Incentive Rules*: The incentive is in the process of being built. It needs to be activated before the rules will begin processing.
* *Open-Active*: The incentive has been activated and its rules will process (within the timebox, if one is defined).
* *Resolved-Inactive*: The incentive has been deactivated and its rules will not process.
Incentive Rules can be in one of three statuses:
* *New*: The rule was created via AI and requires review prior to activation.
* *Pending-Deploy*: The rule is undergoing deployment.
* *Open-Active*: The rule is active and will process if its incentive is active and inside the timebox (if any).
* *Resolved-Inactive*: The rule has been deactivated and will not process.
# Member Experiences
Source: https://docs.fieloloyalty.com/build/member-experiences
Through the [Fielo Loyalty API](/api-reference), it's easy to surface loyalty data on the touchpoints your members already use to interact with your brand. Take a look at this example of a member experience embedded into a mobile app.
### Overview and Available Incentives
Members see their current balance(s), tier and the incentives available to them based on their segments.
When selecting an incentive, members can check out what they'll earn and any eligibility details.
### Profile and Tiers
Members can verify and update their profile info, as well as view their tier status, benefits and learn how to upgrade.
### Rewards Catalog
Members view their available balances and browse reward options in the catalog.
Upon selecting a reward, they can see its price and description and add it to their cart.
Once the desired items are added, members proceed to checkout.
After completing checkout, an order confirmation is displayed.
Members can then view the details of their redemptions at any time on the My Redemptions page, accessible from the catalog.
# Gamification
Source: https://docs.fieloloyalty.com/build/multistep-incentives
Coming soon
Incentive rules can reward members for meeting a defined threshold, typically over multiple activities, within a stipulated period. Example use cases include:
* Make 5 purchases in a calendar week
* Make purchases totalling \$100 and over within 2 days
* Make a purchase and respond to a survey
### Measure: Number of Activities
Measure the number of times a member performed an activity, such as a purchase (sale), and reward the member if that threshold has been met inside the stipulated period.
### Measure: Sum of an Activity Attribute
Measure the sum of an attribute of activities members perform, such as the total amounts of purchases (sales), and reward a member if that threshold has been met inside the stipulated period.
### Period: All Time
Members will be rewarded if they meet the threshold inside the incentive period.
### Period: Calendar Period
Members will be rewarded if they meet the threshold inside a calendar period. At the end of each calendar period, progress towards the threshold is reset. The calendar periods available are:
* Day
* Week
* Month
* Quarter
* Year
Once a member is rewarded in a calendar period, his or her progress is no longer tracked inside that calendar period and the member is not eligible to earn again until the next calendar period.
### Period: Rolling Period
Members will be rewarded if they meet the threshold inside a specified last number of days. Every time a member performs an activity, the lookback period is analyzed to determine if rewarding is required.
A member can earn multiple times, but when a member is rewarded, his or her progress is reset to 0.
### Multirule Reward
Reward members only after they've met the thresholds of multiple rules. Any combination of rules is valid, as long as they’re part of the same incentive.
Multirule rewards can be applied in addition to or in lieu of rewards from individual incentive rules. You can also limit the number of times a member can earn a multirule reward.
# Products
Source: https://docs.fieloloyalty.com/build/products
A product is something that can be referenced as a line item, or sale item, on a sale or presale. If you plan to build incentives that target specific sale items, you must register corresponding products.
### Attributes
To add a product, navigate to the Products page and select **Create Product**. In addition to a name and description, products have the following attributes:
* *Product Code*: This is how a product will be identified on a sale item. It must be unique.
* *Brand*: Identifies the brand of a product for targeting in rules. It is optional.
* *Category*: Identifies the product category for targeting in rules. It is optional.
* *Incentivizable*: When enabled, the value of this product as a sale item on a sale counts towards that sale's *Incentivizble Amount*.
### Status
The status of a product is always *Open-Active*. Products no longer in use can be deleted.
# Programs
Source: https://docs.fieloloyalty.com/build/programs
A program encapsulates a community of members that you want to influence, as well as how you target and reward them. You can run multiple programs in parallel. Programs can be organized by:
* Type (e.g. points, benefits, etc.)
* Geography
* Brand
* Any other classification that makes sense for your organization
To use Fielo, you must have at least one a program.
### Program Agent
Fielo AI can help you understand how your program is performing, which incentives are doing better than others, explore ideas on how to improve your program, and more. To start a chat, click on the purple ✨ icon on the right side of a program detail page.
### Visualization
You can access a visual summary of the incentives that are active in your program. To do so, navigate to the **Incentive Details** tab.
There, you'll find a diagram showing each of your active incentives (blue), the rules inside them (green), and the rewards they give (yellow).
### Review Digest Recommendations (Coming Soon)
If you've enabled the AI Weekly Digest, you may receive suggestions around new ways to segment and incentivize your membership base.
You can review those suggestions on your program page. On the **Review Recommendations** table, you can get details on each recommendation and approve or reject it.
You can also chat with Fielo AI about your recommendations. It can tell you why those recommendations were made, as well as explore what other alternatives might exist.
Any recommendations that haven't been reviewed by the time your next digest is sent will be automatically withdrawn.
### Settings
To create a program, navigate to the Programs page and select **Create Program**. In addition to a name and description, programs have the following settings:
* *Time Zone*: The time zone that will be applied to input data during rules processing, in order to determine whether the incentivizable activity occurred inside an incentive's timebox. It will also be used to when marking ledger entries and redemption items as expired. It accepts the cannonical identifiers as described by the [tz database](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones) standard. If blank, UTC (GMT) will be assumed.
* *Redemption Ceiling Tiebreaker*: If using [Redemption Ceiling Rules](/build/redemption-ceiling-rules), this determines whether, when multiple rules apply, which rule will prevail. **Lowest Wins** means the lowest ceiling will be returned, while **Highest Wins** means the highest ceiling will be returned.
* *Currencies*: The currencies selected will be usable in the program. Members will not be able to accrue any unselected currencies.
* *Enable Registration Event on Member Activation*: When enabled, an event of type `Registration` will be created whenever a member first enters "Open-Active" status. This enables you to provide a welcome reward to new members through an incentive rule.
### Statuses
Programs can be in one of two statuses:
* *Open-Active*: The program's rules will be processed against input data related to its members.
* *Resolved-Inactive*: The program's rules will not be processed.
# Redemption Ceiling Rules
Source: https://docs.fieloloyalty.com/build/redemption-ceiling-rules
Redemption ceiling rules define how much currency a member can apply to a future purchase, or [Presale](/run/presales), such as in cashback programs. Only one rule can prevail on a presale.
### Tiebreaker
When multiple redemption ceiling rules apply to a single presale, the tiebreaker determines which rule will take precedence. **Lowest Wins** means the rule with the lowest ceiling will apply, while **Highest Wins** means the rule with the highest ceiling will apply.
You can set a tiebreaker on each of your [Programs](/build/programs).
### Add a Rule
To add a redemption ceiling rule, navigate to the Redemption Ceiling Rules page and select **Create Redemption Ceiling Rule**. In addition to a name and description, incentives include the following attributes:
* *Program*: Only members of this program will be rewarded through the incentive.
* *Ceiling Amount*: The maximum amount of currency applicable to presales scoped to this rule.
### Set Criteria
Next, add criteria to specify which presales should fall under the rule:
* *Criteria*: The criteria that the presale must meet in order for this rule to apply. Criteria are built upon presale attributes. For example, if your rule only applies to presales over \$50, the criterion will look something like `Net Amount greater than 50`.
* *Criteria Logical Expression*: Determines whether **All criteria must match** for the rule to apply, or **Any criterion can match**.
When your criteria are ready, click **Submit**.
There is a deployment process that needs to complete before the rule officially becomes *Open-Active*. You can check its status on the Deployments page. Even when the deployment has finished, it may still take several more minutes for the status of your rule to reflect this.
### Statuses
Redemption Ceiling Rules can be in one of three statuses:
* *Pending-Deploy*: The rule is undergoing deployment.
* *Open-Active*: The rule will be applied to scoped presales.
* *Resolved-Inactive*: The rule has been deactivated and will not be applied.
# Rewards
Source: https://docs.fieloloyalty.com/build/rewards
Rewards are the prizes available to program members. They can represent any kind of product or service you wish to offer: physical items, vouchers, discount codes, invites, and more.
Members can acquire rewards by exchanging currency for them or directly via incentive rules (instant rewards). When a member gets a reward, a redemption is created with one or more redemption items; each redemption item corresponds to an acquired reward.
### Attributes
To add a reward, navigate to the Rewards page and select **Create Reward**. In addition to a name and description, rewards have the following attributes:
* *External ID*: This is how the reward will be identified on redemption requests made through API. It must be unique.
* *Reward Type*: Rewards can have **Unlimited** stock, or have **Stock Control**. Stock-controlled rewards need to have an initial stock specified. Stock is automatically updated upon each redemption. Stock can be replenished at will. Stock is controlled via Reward Stock Entries.
* *Prices*: If you want to allow members to exchange currency for this reward, you can set the price of the reward. If no price is set, the reward can still be granted through an incentive rule as an instant reward.
* *Days Available*: The number of days following redemption that the redemption items corresponding to this reward will be available to use. When this period lapses, the redemption item will be marked as expired. If blank, redemption items corresponding to this reward will not expire.
* *Reward End Date Time*: After this date and time, members will no longer be able to acquire this reward. If blank, the reward will be available indefinitely.
* *Reward Cost*: The internal cost of this reward to your organization for accounting purposes.
### Add Reward Stock
If your reward is under **Stock Control**, you'll need to provide its initial stock before members can begin acquiring it.
To do so, access the three-dot menu from the details pane, select **Add Reward Stock** and enter quantity you wish to add.
As members acquire the reward, its stock will be consumed. When the stock has been depleted, no new redemptions of the reward will be allowed until stock has been replenished.
### Statuses
Rewards can be in one of two statuses:
* *Open-Active*: Members can acquire the reward.
* *Resolved-Inactive*: The reward cannot be acquired.
Rewards no longer in use can be deleted.
# Segments
Source: https://docs.fieloloyalty.com/build/segments
Segments are groupings of members that you can use to target incentives to specific subsets of your customer base. When one or more segments are applied to an incentive, only members that are in at least one of those segments will be able to earn rewards through that incentive.
To add a segment, navigate to the Segments page and select **Create Segment**.
### Segment Type
Segments can be one of two types:
* **Criteria**: Segment membership is defined dynamically based on member attributes and is updated on-the-fly. For example, if a member performs an activity that is incentivized only for members who have provided a mobile phone number, Fielo will verify in real time whether the member has indeed provided one. Later on, if the member performs the same activity, Fielo will check once again during incentive processing to see if the member is part of that segment.
* **List**: The segment consists of a list of members that belong to the segment. The list can be updated administratively or via automation. This type of segment is typically used when segment membership is managed outside of Fielo (such as by a Customer Data Platform) or is discretionary (such as a "VIP Members" list).
Once selected, a segment's type cannot be changed.
### Configure a Criteria Segment with AI
You can brainstorm and create a segment by chatting with Fielo AI. On the right side of the Segments page, simply start a conversation around your segment idea.
The agent will ask for any missing information and confirm all details before creating your segment. Once your segment is created, you'll need to review it and then activate it.
If a segment idea requires an attribute that doesn't currently exist, the agent will let you know. Reach out to your account executive to explore how we can bring it to life.
### Manage Criteria Segment Membership
A criteria segment requires one or more conditions, or criteria, that define which members belong to the segment. After you've created a criteria segment, you can add a criterion.
After you've added your criteria, specify whether **All criteria must match** for a member to be part of the segment, or **Any criterion can match**.
When ready, you can activate your segment from its detail page. Under the criteria list, click **Submit**. It can take up to 15 minutes for your segment to become active.
### Manage List Segment Membership
List segments can be managed via API, as well as manually.
You can quickly add and remove members administratively using external IDs. To add or remove members from a segment, access the three-dot menu from the details pane, select **Add Members** or **Remove Members** and enter the external IDs of the members.
You can also modify the segments of a member directly from the member's detail page.
Once you've defined your segment's list, you can go ahead and activate it. From the three-dot menu, choose "Mark as active".
### Statuses
Segments can be in one of three statuses:
* *Open-In progress*: The segment has been created, but not yet activated.
* *Pending-Deploy*: The segment has been submitted for activation and is undergoing deployment. This status applies to criteria segments only.
* *Open-Active*: The segment can be assigned to incentives, and such incentives will only be processed for members who belong to the segment.
* *Resolved-Inactive*: The segment is not in use and cannot be applied to incentives.
Segments no longer in use can be deleted.
# Stores
Source: https://docs.fieloloyalty.com/build/stores
A store is a location at which a sale or presale occurs.
### Attributes
To add a store, navigate to the Stores page and select **Create Store**. In addition to a name and description, stores have the following attributes:
* *Store Code*: Required. This is how a store will be identified on a sale or presale. It must be unique.
* *Address*: Optional. The address fields *Street*, *City*, *State/Province*, *Postal Code*, and *Country* identify the physical location at which a sale or presale occurred for targeting in rules.
* *Is Participating*: This can be used in data set or rule criteria to check whether a store is participating in the program.
### Status
The status of a store is always *Open-Active*. Stores no longer in use can be deleted.
# Tiers
Source: https://docs.fieloloyalty.com/build/tiers
Tiers are a great way to create exclusivity and give members clear milestones to reach in your loyalty program. Create a set of identifiable thresholds that progressively level up a member's experience with your brand.
### Define a Measure
Tiers belong to a single program. A member can only have one tier at any given time.
Before creating individual tiers, you must first define how your tier thresholds will be measured.
Measures can be:
* A numeric field from Sale, such as Total Amount or Incentivizable Amount
* A currency balance
Next, you define a lookback period (in days). The lookback period is the period over which the measure you selected will be evaluated.
### Set a Maintenance Policy
You can define a Stability Period (in days), which is how long a member can stay in a tier before being reevaluated.
If a member is not upgraded within this period of time, he or she is reevaluated and reclassified according to their performance over the lookback period.
### Add a Tier
For each tier, you define a threshold for tier entry (based on the measure you've selected). One tier is allowed to not have a threshold, which means it is the base (or default) tier that all members are eligible for if they haven't met the threshold for any other tier.
### Upgrade
Measurement for tier upgrades occurs in real time. Whenever a sale is registered under a member's name (if tiering based on Sale) or whenever the relevant currency is accrued (if tiering based on a currency balance), Fielo evaluates whether a new tier threshold has been reached. If a new threshold has indeed been reached, the member is upgraded to the new tier immediately.
Members can be rewarded when they are upgraded to a new tier. Tier upgrade rewards are typically differentiated by tier.
### Downgrade
Tier downgrade occurs once per day. Each day, members whose current Tier Reevaluation Date is today are evaluated to determine whether they are to remain in their current tier or be downgraded.
### Tier Movement History
Each time a member is assigned a tier, either by upgrade or downgrade, the following data are captured:
* Previous Tier
* New Tier
* Tier Entry Date
* Tier Reevaluation Date (Tier Entry Date + Stability Period defined for the program)
* Whether it was an upgrade or a downgrade
* Is Current (indicates whether this is the most recent tier update)
### Statuses
A tier can be active or inactive. Inactive tiers cannot be assigned to members (members already in the tier that became inactive can remain there until that tier expires for them).
# Product Updates
Source: https://docs.fieloloyalty.com/changelog
Inaugural release of the AI-powered Fielo Loyalty.
# Loyalty Designer
Source: https://docs.fieloloyalty.com/design/designer
Fielo's Loyalty Designer allows you to rapidly create a loyalty program tailored to your needs, reducing time-to-launch by up to 70%.
Our expert AI advisor applies built-in industry knowledge to surface best practices and automatically populate the most effective strategic elements for your specific business goals.
Forget generic templates - after a short conversation, you gain access to a comprehensive, visual strategy canvas that's ready to convert into a working program.
Ready to rethink your loyalty strategy?
Ideate and design a ready-to-launch program in minutes.
# Platform Capabilities
Source: https://docs.fieloloyalty.com/features
## AI Features
Program performance reviews and incentive impact comparisons with interactive drilldowns.
Chat-based ideation, creation and editing of incentives and rules - no data model knowledge required.
Rapidly ideate and create a loyalty program tailored to your needs, reducing time-to-launch by up to 70%.
Continuous monitoring of incentive performance with automatic, or manually approved, optimizations.
On-demand overviews, insights and recommendations to keep your incentives fresh and impactful.
Keep apprised of where your program stands and recommended next steps, right in your inbox.
Chat-based ideation, creation and editing of segments leveraging your set of member attributes.
Inquire about the reasoning behind AI recommendations, model impacts and explore additional alternatives.
## Key Features
* [Data Sources](/build/datasets)
* [Sales](/run/sales)
* Events
* [Program Management](/build/programs)
* Multi-Program
* Incentives Visualizer
* [Currencies](/run/ledger-entries)
* Multi-Currency
* [Redemption](/run/redemptions)
* [Redemption Ceiling Rules](/build/redemption-ceiling-rules)
* Expiration
* Usage Tracing
* [Incentives](/build/incentives-config)
* Single-Action Rules
* [Gamification](/build/multistep-incentives)
* [Time-Based Rewarding](/build/event-schedules)
* Multirule Rewards
* Accrual Limits
* [Rewards](/build/rewards)
* Catalog Rewards
* Stock Control
* Instant Rewards
* [Badges](/build/badges)
* [Tiers](/build/tiers)
* Real-Time Upgrades
* Maintenance and Downgrade Policy
* [Segmentation](/build/segments)
* List-Based
* Criteria-Based
* [Member Management](/run/members)
* 360º Member View
* Balance Adjustments
* [Products](/build/products)
* [Locations](/build/stores)
* [Analytics](/run/analytics)
* [Fraud Control Policy](/build/caps)
* [REST API](/api-reference)
* Input Data
* Member Experience
* Data Extraction
# Analytics
Source: https://docs.fieloloyalty.com/run/analytics
Fielo offers a variety of out-of-the-box insights, with flexible filtering and drill-down, to help you monitor your programs' operations and impact.
Insights include:
* Number of loyalty-attributed sales
* Member spend
* Average ticket value
* Currency debits and credits by type
* Redemptions over time
* Projected breakage (expiration)
* Currency awarded
* Currency used
* Currency outstanding
* Currency expired
* Tier upgrades
* Tier downgrades
* Scheduled tier expiries
* Member sign-ups
* Number of active members
* Unprocessed sales, events and redemptions indicators
You can also extend the dashboard with your own bespoke metrics. To learn more, reach out to your account executive.
## AI Weekly Digest (Coming Soon)
Fielo can send you periodic updates about your program’s performance, keeping you apprised of engagement trends and providing a heads up on any recommended changes.
The digest can be sent on a weekly or monthly basis and includes:
* Number of new members
* Engagement rate
* Number of accruals
* Number of redemptions
* Period-over-period change
* AI-powered insights and recommendations
### Review Recommendations
Your digest may include suggestions around new ways to segment and incentivize your membership base.
To review those, go to the corresponding program page. On the **Review Recommendations** table, you can get details on each recommendation and approve or reject it.
You can also chat with the Program Agent about your recommendations. It can tell you why those recommendations were made, as well as explore what other alternatives might exist.
Any recommendations that haven't been reviewed by the time your next digest is sent will be automatically withdrawn.
# Incentive Runtime
Source: https://docs.fieloloyalty.com/run/incentives-processing
## AI Insights
Once an incentive is activated, you can access its insights. AI insights include a summary of the incentive's mechanics, the incentive's participation trends, and recommendations on how it might be improved.
## AI Enhancement
You can improve your incentives with Fielo AI. Click on the purple ✨ icon on the right side of an incentive detail page and start a conversation.
The agent will ask for any missing information and confirm all details before enhancing your incentive. Once your enhanced incentive rules are created, you'll need to review and activate them.
## Autonomous AI Optimization
Once your incentive is in full swing, Fielo AI can make sure it stays performant, automatically. On each of your incentives, you control which kinds of optimizations Fielo can carry out on the fly, require admin approval, or are simply admin-only. All autonomous activities are recorded on the Recent Updates list, including a timestamp and the name of the approver (when applicable).
### Optimization Types
* **Extend or shorten duration**: AI can change the incentive start date and end date.
* **Adjust currency reward values**: When currency rewards are being given, reward values can be changed. If no currency rewards are being given, no optimizations of this type are made.
* **Modify expiration policy**: When currency rewards that expire are being given, the expiration policy can be modified. Currency rewards that don't expire are excluded from this type of optimization.
* **Add or remove rewards**: AI can add or remove currency rewards and instant rewards.
* **Adjust rule criteria**: AI can make changes to the comparators and values of existing rule criteria, but not source fields. For example, AI can change the criterion `Total Amount > 100` to `Total Amount >= 150`, but cannot change the "Total Amount" field to different one.
* **Change targeted segments**: AI can add and remove segments to and from the incentive.
### Trust Levels
* **Off**: No autonomous activity of this type permitted.
* **Ask Me**: Ask for approval for activities of this type. When AI recommends an activity of this type, all registered Loyalty Managers are informed by email. The activity can be approved or rejected on the AI Suggestions for Manual Review table on the corresponding incentive page.
* **Automate**: AI is free to execute activities of this type autonomously.
## Incentive Processing
When Fielo is notified of an incentivizable occurrence, such as a new Sale or Event, the system processes it to determine what, if any, reward the member associated with that occurrence should receive. [Incentive](/build/incentives-config) processing follows a series of eliminative steps:
1. **Queue**: The occurrence enters a queue, to be processed in order of insertion (first in, first out). Depending on volume and network conditions, this can take a few seconds to a few minutes.
2. **Data Sets**: Fielo evaluates whether the occurrence meets the criteria of any of the data sets that correspond to its object type. [Data Set](/build/datasets) criteria serve as a first-level filter that can remove occurrences that are generally not incentivizable, such as sales originating from nonparticipating channels. [Caps](/build/caps) are also enforced on this step.
3. **Incentive Eligibility**: The member's segment(s) and/or tier are checked against the incentives whose rules belong to the data set(s) identified in the previous step. Members can only be rewarded on incentives targeted to one of their segments or tiers, as well as those open to all members.
4. **Incentive Rules**: The occurrence is evaluated against the criteria of the rules belonging to the data set(s) identified in step 2 and the eligible incentives identified in step 3.
* **No Competition**: The member will be rewarded by all rules of type "No Competition" whose criteria have been met.
* **Best Option**: For all rules of type "Best Option" whose criteria have been met, only the one whose reward is most favorable to the member will be applied. Usually, this is the rule that awards the most currency. In the event multiple rules award the same amount, the rule with the more generous expiration policy prevails.
## Incentive Results
Post-processing, you have visibility on how an incentivizable occurrence, such as a sale or event, was processed by Fielo. Incentive results show which rewards were granted and which were discarded, including the reasons for each. You can find incentive results on the detail page of a processed occurrence, such as a sale or event with status of "Resolved-Processed".
# Ledger Entries
Source: https://docs.fieloloyalty.com/run/ledger-entries
Ledger entries record every accrual and deduction of currencies in your program. Their purpose is to update a member's currency balance. Positive ledger entries are often assigned expiration dates. Ledger entries can be produced by incentive rules processing, redemptions, manual currency adjustments, and currency expiration.
The main place you can inspect ledger entries is on a member's detail page. You can also find ledger entries on the items that created them, such as incentivized activities (e.g. sales) and redemptions.
### Expiration
Positive ledger entries can, optionally, be set to expire. Each entry has its own date and time of expiry. A ledger entry's expiration date and time are defined by the artefact which generated it, such as an incentive rule or a balance adjustment.
When a ledger entry expires, all of its available (unconsumed) balance is zeroed out and recorded in the *Currency Expired* column. A new, negative ledger entry of type "Expiration" is created to deduct the expired amount from the now-expired positive entry.
### Attributes
Ledger entries have the following attributes:
* *Type*: **Accrual** means a positive entry resulting from the processing of an incentive rule. **Redemption** means a negative entry resulting from a member redeeming currency for a reward. **Adjustment** means a manual addition or removal of currency by an admin. **Expiration** means a negative entry resulting from the expiration of an accrual or positive adjustment.
* *Member*: The member whose balance was updated.
* *Currency*: The currency corresponding to the balance that was updated.
* *Incentive Rule*: If the entry is an accrual, this is the incentive rule which generated it.
* *Sale*: If the entry is the result of an incentive rule on Sale, this is the corresponding sale.
* *Event*: If the entry is the result of an incentive rule on Event, this is the corresponding event.
* *Redemption*: If the entry is of type "Redemption", this is the corresponding redemption.
* *Expiration Ledger Entry*: If the entry is of type "Expiration", this is the positive entry whose remaining balance has been expired.
* *Member Balance Snapshot*: The resulting balance of the member immediately following the insertion of this entry.
* *Currency Awarded*: The amount of currency added or removed.
* *Currency Available*: The amount of currency still available for use (i.e. not already used or expired). For negative entries, this will always be 0.
* *Currency Used*: The amount of currency that the member has used, such as in redemptions. For negative entries, this will always be blank.
* *Currency Expired*: The amount of currency that was consumed due to expiration. For negative entries and positive entries prior their expiration date, this will be blank.
* *Create DateTime*: The date and time at which the entry was inserted.
* *Expiration Date Time*: The date and time at which the positive entry is set to expire. If blank, either the entry is a deduction or it does not expire.
### Statuses
Ledger entries can be in one of three statuses:
* *Open-Available*: The entry is positive, has available balance and does not have an expiration date.
* *Open-AvailableWithExpiry*: The entry is positive, has available balance and has an expiration date in the future.
* *Resolved-Expired*: The entry is positive and any unused balance has been expired.
* *Resolved-Closed*: The entry is negative (redemption, expiration or negative adjustment) or the entry is positive and completely consumed.
# Members
Source: https://docs.fieloloyalty.com/run/members
Members are the people you wish to influence through your program. You can target and motivate subsets of members using segments and tiers. When participating in the program, members can earn currency, which can be used for tiering or redeemed for rewards, as well as instant rewards.
### Attributes
Members can be created via API and from the Members page. Members have the following attributes:
* *External ID*: This is the unique identifier for the member across systems. It is used to identify members on data that can originate from external systems, such as sales and events. It is required.
* *Full Name*: The member's first and last name.
* *Email Address*: The member's email address. Though not required, it cannot be duplicated among members.
* *Mobile Number*: The member's cellular phone number.
* *Date of Birth*: The member's birthday. This can be used to reward members on or near their birthday.
* *Join Date Time*: The day and time the member registered into the program (when status first became *Open-Active*). This can be used to reward members on or near their program anniversary.
* *Program*: A member must belong to one program.
* *Last Activity Date Time*: The most recent day and time that the member was rewarded via an incentive rule or made a redemption.
* *Balances*: For each currency active in the member's program, the member's current balance will be shown on this list. You can administratively add and remove balance. Balances must always be greater than or equal to zero.
### Statuses
Members can be in one of five statuses:
* *Open-Prospective*: An optional preregistration status. The member is not yet registered in the program. Members do not yet earn rewards in this status.
* *Open-Active*: The member is considered actively registered. This is the only status in which members are eligible to earn rewards.
* *Resolved-BlockAccruals*: The member is blocked from receiving rewards (including instant rewards), but can still use any active currency.
* *Resolved-BlockAll*: The member is blocked from receiving rewards and using currency.
* *Resolved-Inactive*: The member is no longer in the program. The member cannot receive rewards or use currency.
# Presales
Source: https://docs.fieloloyalty.com/run/presales
A presale represents a potential future sale that has not yet been finalized. You can think of it as a shopping cart that is pending checkout. It is used to evaluate [Redemption Ceiling Rules](/build/redemption-ceiling-rules).
### Processing
Presales are typically fed to Fielo from an external system of record via API.
When a presale is registered into Fielo, it enters a queue which is cleared on a first-in, first-out basis. The presale is evaluated against the redemption ceiling rules of the program to which the customer belongs and the redemption ceiling is calculated.
### Attributes
For small-scale testing purposes, presales can be created from the Presales page. Presales have all of the attributes that [Sales](/run/sales) have, plus the following additional one:
* *Redemption Ceiling Amount*: The maximum amount of currency applicable, should the presale be finalized as a sale.
### Redemption Ceiling Results
Post-processing, you have visibility on how a presale was processed by Fielo. Redemption ceiling results show which rule prevailed and which were discarded, including the reasons. You can find the results on the detail page of a processed presale.
### Statuses
Presales can be in one of four statuses:
* *Pending-Ready to Process*: The presale has entered the system and is waiting to be processed.
* *Pending-Processing*: The presale is being processed against the redemption ceiling rules of the member's program.
* *Resolved-Processed*: The presale has been successfully processed against the redemption ceiling rules of the member's program.
* *Resolved-Withdrawn*: Presale processing was aborted either because the associated member's status is not *Open-Active* or due to a system error.
# Redemptions
Source: https://docs.fieloloyalty.com/run/redemptions
A redemption is created whenever a member gets a [catalog reward](/build/rewards). Members can acquire rewards by exchanging currency for them or directly via incentive rules (instant rewards). Redemptions contain one or more redemption items; each redemption item corresponds to an acquired reward.
### Processing
Standard redemptions are inserted through the API by an external system, such as a web service connected to your member experience, or administratively via the UI. Redemptions resulting from instant rewards are generated internally during incentive rules processing.
When a redemption is created, the member's currency is immediately deducted, when applicable. If the member has insufficient balance, an error will be thrown.
It then enters a queue which is cleared on a first-in, first-out basis. While the redemption is still in the queue, the member cannot make any additional redemptions. Once cleared, the redemption and its items are ready for use.
### Currency Usage Trace
On standard redemptions, you can verify which positive ledger entries were consumed in order to satisfy the redemption.
To do so, go to the Ledger Entries list on the redemption detail page. Click on the business ID of the negative ledger entry, and then go to its Redemption UsageTrace list. There, you will see the list of positive ledger entries that satisfied the redemption alongside their respective amounts consumed.
### Redemption Items
Each redemption item corresponds to a reward that the member acquired, which can include a voucher code and an expiration date. An item can be used up to its expiration date, after which it's marked as expired.
A redemption item can be used as follows:
* **Lock**: Locking signals that the member has begun the process of "burning" (or using) the redemption item, enabling you to prevent attempts at multiple simultaneous uses.
* **Unlock**: If the attempt to use is aborted, the redemption item can be unlocked so that a new attempt can be made in the future.
* **Use**: An item, once locked, can then be marked as used.
### Attributes
Standard redemptions can be created administratively from the Redemptions page. Redemptions have the following attributes:
* *Member*: The member who made the redemption (or got the instant reward).
* *Program*: The member's program.
* *Origin*: If the redemption results from an incentive rule (i.e. instant reward), this will indicate "Business Rule".
* *Source Data Type*: If the redemption results from an incentive rule (i.e. instant reward), this will indicate the data type of that rule.
* *Items*: The number of items that the redemption contains.
* *Redeemed Currency*: The amount of currency that was consumed by the redemption. This does not apply to redemptions resulting from incentive rules.
* *Redemption Date Time*: The day and time that the redemption took place.
Redemption Items have the following attributes:
* *Redemption*: The redemption to which the item belongs.
* *Reward*: The catalog reward corresponding to the item.
* *Quantity*: The quantity of reward redeemed.
* *Is Instant Reward*: Indicates "Yes" if the item resulted from an incentive rule (i.e. instant reward), and "No" otherwise.
* *Voucher Code*: The code that is provided to the member to facilitate the fulfillment process. It is optional. If needed, it must be provided on insertion of the redemption. For instant rewards, it will always be blank.
* *Create DateTime*: The date and time at which the item was inserted.
* *Expiration Date Time*: The date and time at which the item is set to expire. Upon expiration, the item can no longer be used. If blank, the item does not expire.
### Statuses
Redemptions can be in one of four statuses:
* *Open-Ready To Process*: The redemption has been created and is in the processing queue. Currency has already been deducted, if applicable.
* *Pending-Process Redemption*: The redemption is being processed.
* *Pending-Redeem*: The redemption has been processed. There are one or more redemption items that are available for use.
* *Resolved-Completed*: All redemption items have either been used or expired.
Redemption Items can be in one of three statuses:
* *Open-Available*: The item is available for use and does not have an expiration date.
* *Open-Available With Expiry*: The item is available for use and has an expiration date in the future.
* *Open-Locked*: The item is locked. It can be marked as used or unlocked. If unlocked, the status returns to "Open-Available" or "Open-Available With Expiry".
* *Resolved-Completed*: The item has been marked as used.
* *Resolved-Expired*: The item was not marked as used before reaching its expiration date.
# Sales
Source: https://docs.fieloloyalty.com/run/sales
A sale represents a purchase made by one of your customers. It is a core behavior that programs seek to influence. Different facets of sales can be incentivized, such as ticket size, frequency, product mix, and more.
### Processing
Sales are typically fed to Fielo from an external system of record via API, either in real time or by scheduled job. Fielo can process sales with line item granularity, as well as flat sales data.
When a sale is registered into Fielo, it enters a queue which is cleared on a first-in, first-out basis. The sale is evaluated against the incentive rules of the program to which the customer belongs and, if any rules apply, the customer is rewarded.
### Attributes
For small-scale testing purposes, sales can be created from the Sales page. Sales have the following attributes:
* *External ID*: This is the unique identifier for the sale. It typically originates in the external system of record. It is required.
* *Sale Date Time*: This is the day and time at which the sale occurred. Timeboxed incentives use it to determine whether the sale occurred within the incentive period. If left blank, it will be assumed that the sale occurred at the time it was registered inside Fielo.
* *Store*: This is the physical location at which the sale occurred. It is optional.
* *Store Code*: This is the unique identifier of the store at which the sale occurred. It is used to associate a store with the sale when creating the sale via API. It is optional.
* *Member*: This is the customer associated with the sale.
* *Member External ID*: This is the unique identifier of the member on the sale. It is used to associate a member with the sale when creating the sale via API.
* *Brand*: This is the brand at which the sale was made. It is optional.
* *Sale Channel Code*: This identifies the channel through which the sale occurred. It is optional.
* *Point of Sale ID*: This identifies the POS at which the sale occurred. It is optional.
* *Total Amount*: This is the total amount paid on the sale. If sale items are included on the sale, this will be calculated as the sum of the line item amounts. If flat sales data is provided, this should be filled in when registering the sale inside Fielo.
* *Incentivizable Amount*: This is the amount eligible for incentivization. If sale items are included on the sale, this will be calculated as the sum of the line item amounts of the sale items marked as incentivizable. If flat sales data is provided, this should be filled in when registering the sale inside Fielo.
### Sale Items
Sales can, optionally, be comprised of sale items. A sale item is a line item on the sale associated with a product. Sale items have the following attributes:
* *Line Number*: The order in which the sale item appears on the sale. It is optional.
* *Product*: The product that corresponds to the sale item.
* *Product Code*: This is the unique identifier of the product that corresponds to the sale item. It is used to associate a product with the sale item when creating the sale via API.
* *Description*: The description of the sale item's product. Filled in automatically.
* *Incentivizable*: Indicates if the sale item's product is incentivizable. Filled in automatically.
* *Quantity*: The number of units sold. It is optional.
* *Unit Price*: The price per unit. It is optional.
* *Original Amount*: The line item total before any discounts. It is optional. If desired, it must be filled in; it is not calculated.
* *Net Amount*: The total paid net of any discounts.
* *Discount Amount*: The difference between the original amount and the net amount. If the original amount is blank or less than the net amount, this will evaluate to 0. Filled in automatically.
* *Discount Percentage*: The percentage of reduction from the original amount to the net amount. If the original amount is blank or less than the net amount, this will evaluate to 0. Filled in automatically.
### Statuses
Sales can be in one of four statuses:
* *Pending-Ready to Process*: The sale has entered the system and is waiting to be processed.
* *Pending-Processing*: The sale is being processed against the incentive rules of the member's program.
* *Resolved-Processed*: The sale has been successfully processed against the incentive rules of the member's program.
* *Resolved-Withdrawn*: Sale processing was aborted either because the associated member's status is not *Open-Active* or due to a system error.
# Privacy
Source: https://docs.fieloloyalty.com/trust/privacy
We are committed to transparency regarding how member data is collected, processed, and stored inside your loyalty program. Our privacy framework is designed to help you maintain compliance with global regulations such as GDPR, CCPA, and LGPD.
### Data Minimization
We give you the flexibility to collect and process only the attributes necessary for your members' loyalty experience. By default, the system utilizes a unique, non-personally identifiable external ID to link activities to a member profile without requiring a full set of personal identifiers. PII fields like name, email address, and date of birth are optional and used only when they serve a functional requirement, such as triggering birthday rewards.
### Member Rights & Control
The platform provides tools to honor member privacy requests:
* **Right to Access**: Customer service personnel can view a member's full profile directly inside the app to fulfill access requests.
* **Right to Erasure**: When a member is deactivated, their data can be handled according to your organization’s retention and deletion policies.
* **Processing Restrictions**: Halt data processing for specific members in the case of a dispute or privacy review.
### AI
To leverage the power of frontier LLMs while maintaining member privacy, we implement the following safeguards:
* **PII Masking**: Before data is processed by an LLM, PII such as names and email addresses are masked or anonymized. The model operates on patterns rather than individual identities.
* **Purpose Limitation**: Data processed by AI is used solely for the purpose of enhancing your program and is not shared with third parties for marketing.
* **Transparency**: All incentive processing outcomes are individually auditable, ensuring AI-driven personalization is compliant with your internal governance standards.
# Security
Source: https://docs.fieloloyalty.com/trust/security
Protecting the integrity of your loyalty program data is our highest priority. Fielo Loyalty employs a multi-layered security strategy to ensure that all data, including member and transactional data, remains secure.
### Infrastructure
As an application built on a trusted third-party cloud, we inherit enterprise-grade security controls from a platform that is **zero-trust architected** and **secure by default**.
* **Physical Security**: Data is hosted in secure, Tier-1 cloud environments with 24/7 monitoring and physical access controls.
* **Network Isolation**: We utilize Virtual Private Clouds (VPCs) and advanced firewalls to isolate program data from unauthorized external access.
* **Compliance**: Our third-party infrastructure enjoys over 20 security certifications, including **ISO 27001** and **SOC 2**.
### Data Protection
We employ industry-standard encryption protocols to safeguard sensitive information throughout its lifecycle.
* **Encryption in Transit**: All data moving between external systems of record and our API is encrypted using TLS 1.2+.
* **Encryption at Rest**: Databases storing member attributes, external IDs, and transaction histories are encrypted using AES-256.
* **Role-Based Access Control (RBAC)**: Administratively, you can manage who has the authority to view each area of the app, ensuring the principle of least privilege.
### AI
When leveraging Large Language Models (LLMs) to generate insights and recommendations, we adhere to strict security protocols:
* **No Training Policy**: We use enterprise-tier API agreements with LLM providers. Your proprietary program data and member information are *never* used to train the provider's foundation models.
* **No Data Logging**: LLM processing occurs within a secure, ephemeral environment. Data is sent for the specific task and is not stored by the LLM provider beyond the immediate session (Zero Data Retention where applicable).
* **Prompt Security**: When sending a prompt to a public LLM, content filtering applies to detect and prevent harmful content in prompts and completions.
* **Consistent Performance**: With every release, AI models are verified to ensure consistent performance and efficiency.
# Use Cases
Source: https://docs.fieloloyalty.com/use-cases
## Program Types
* **Points**\
Members earn virtual currency for every dollar spent or action taken. Points can be redeemed for discounts, products, or exclusive experiences.
* **Cashback**\
A percentage of eligible sales is returned to members' accounts. Members can apply this credit to future purchases.
* **Tiers & Benefits**\
Categorize members into levels like Bronze, Silver and Gold based on their engagement or spending history. As members move up, they unlock increasingly valuable perks, creating a sense of status and progression.
## Campaign Types
* **Welcome**\
Greet new members with an immediate reward or points boost upon joining, encouraging early interaction and setting the tone for a positive program experience.
* **Birthday**\
Reward members with a gift, discount or points boost on or a specified number of days before their birthday.
* **Tier Upgrade**\
Reward members when they move to a higher loyalty level, reinforcing the value of their continued loyalty.
* **Program Anniversary**\
Acknowledge your members' loyalty and support retention with an annual milestone reward.
* **Reactivation**\
Recover lost revenue and reengage your at-risk segment by incentivizing members who haven't made a purchase in a while.
* **Currency Multiplier**\
Drive short-term sales or promote specific shopping windows by increasing the rate at which members earn points or cashback.
* **Sprend Threshold**\
Expand incremental revenue by granting rewards only when a member hits a specific transaction value.
* **Product Mix**\
Diversify members' shopping habits or clear aging inventory by encouraging purchases from specific categories or product lines.
* **Location**\
Drive foot traffic to underperforming locations or boost activity in lagging regions with incentives targeted by geography.
* **Channel**\
Steer members toward more cost-effective or higher-engagement choices by tying rewards to a specific sales channel.
* **Payment Method**\
Reduce transaction fees or strengthen strategic partnerships by rewarding members for using a preferred payment method.