Mapping Core Architectural Entities and Their Roles

Hello. Having completed the first module’s promotion-lifecycle and resilience perspective, we now move into the platform topology that makes those decisions operational. This module establishes the structural vocabulary needed to design a Talon.One integration: what is an organizational boundary, what is a decisioning boundary, where does promotion logic live, and which entities represent enduring customers versus individual commercial interactions.

In this lesson, you will map accounts, Applications, campaigns, rules, customer profiles, and customer sessions to their distinct architectural roles. The important outcome is not merely being able to define each term. It is being able to prevent category mistakes that lead to flawed designs—for example, using an Application as a campaign, treating a session as a customer record, or assuming that a customer profile is the commerce system’s system of record.

A useful way to frame the model is this: Talon.One receives business context, evaluates configured incentive logic, and returns decisions. Its entities separate governance, business scope, promotion strategy, executable logic, customer identity, and transaction context.

---

The six architectural roles at a glance

The Talon.One model is easiest to understand when each entity answers one architectural question.

Entity	Architectural question it answers	Primary role	What it is not
Account	“Which organization administers this Talon.One tenant?”	Top-level governance and tenancy boundary	A shopper account or a campaign container
Application	“Which business context receives this activity and evaluates these campaigns?”	Decisioning, integration, and isolation boundary	A single promotion or a single customer
Campaign	“Which bounded commercial initiative are we running?”	Promotion strategy and operational-control container	The detailed executable logic by itself
Rule	“Under precisely what conditions does a given outcome apply?”	Executable conditions-and-effects logic	A complete business program with dates and budget
Customer profile	“Who is this customer over time?”	Persistent promotion-relevant customer representation	The canonical enterprise customer master
Customer session	“What interaction or transaction context is currently being evaluated?”	Time-bounded decision context, commonly a cart or order journey	A durable customer identity

These roles are related, but they should not be collapsed into one another. A well-designed integration preserves their different lifetimes:

• An account lasts for the commercial relationship with Talon.One.
• An Application lasts while the associated business scope exists.
• A campaign has a defined commercial life, including activation and expiry.
• A rule can change more frequently as business logic evolves.
• A customer profile can persist across many customer journeys.
• A customer session represents a particular journey, cart, checkout, order, or other interaction scope.

The preceding module showed why a final promotion decision can be synchronous at checkout. This lesson explains where that decision comes from: a session and, where relevant, a profile are sent to an Application; the Application evaluates its active campaigns and rules; the Integration API returns effects for commerce to interpret and apply.

---

Account: the tenancy and governance boundary

At architecture level, an account is the top-level Talon.One organizational boundary. Think of it as the tenant your company operates: the place within which Talon.One administration, users, governance, and platform-level configuration are managed.

Do not confuse this with either of these similarly named concepts:

• A customer account in your identity platform represents an individual shopper or business customer.
• A Talon.One account represents your organization’s administrative presence on the platform.

For a principal architecture review, the account boundary raises governance questions rather than cart-pricing questions:

• Which corporate entity controls this tenant?
• Who receives administrative access?
• Who can create or modify Applications and campaigns?
• How are production changes approved?
• How is access separated among marketing, engineering, support, and external implementation partners?
• What data residency, privacy, and audit expectations apply to the account?

A single enterprise Talon.One account can support multiple business contexts. The entity used to organize those contexts is the Application.

---

Application: the business decisioning boundary

An Application is where business data is sent for promotion evaluation and where campaigns are created and managed. It is also associated with the API keys used to send integration data. In practice, it is the critical routing and isolation unit in a Talon.One architecture.

The strongest mental model is:

An Application represents one coherent incentive-decisioning context.

That context is often—but not always—a business region. It can also reflect a currency, time zone, team, brand, channel group, or a deliberate data-isolation requirement.

What belongs in an Application boundary?

Application design is a business architecture decision with technical consequences. Separate Applications when the contexts must be independently managed or cannot safely share promotion activity.

Typical reasons include:

Requirement	Why a separate Application can be appropriate
Different country or trading region	Promotions, legal terms, currencies, tax treatment, and calendars may differ
Different currency	Discount values, thresholds, budgets, and price representations need a coherent currency context
Different time zone	Campaign dates and customer-facing promotion timing may require local control
Separate business teams	Each team needs autonomy over campaigns and operational ownership
Distinct brands or businesses	Campaign strategy and customer activity must be isolated
Strong data isolation requirement	Activity and campaign configuration must not cross the boundary

A separate Application is not free. It creates a real isolation boundary: Talon.One documentation states that customer activity and campaigns cannot be shared across different Applications. Therefore, creating Applications merely because two teams prefer different naming conventions or have separate frontend codebases can make a cross-market loyalty or promotion strategy unnecessarily difficult.

For example, consider a retailer operating in the United States and Europe:

• If the retailer uses USD and EUR, runs market-specific calendars, and has legally distinct promotion terms, US and EU Applications are defensible.
• If both storefronts belong to one commercial market, use the same currency and promotion policy, and require customers’ activity to contribute to a shared incentive model, splitting them may introduce avoidable fragmentation.
• If a mobile app, website, and store associate tool all sell within the same market under the same promotion rules, separate Applications for each channel are usually the wrong default. Channel can instead be supplied as session or profile context for rules to evaluate.

The decisive question is not “How many websites do we have?” It is:

“Which activity must be evaluated against the same campaigns and must remain part of the same commercial decisioning scope?”

Application environments are not Applications

Talon.One supports Sandbox and Live environments. An environment answers a different question from an Application:

• Environment: Is this non-production testing or production operation?
• Application: Which business decisioning scope is this activity being sent to?

A sound topology normally pairs them. For example, a US production commerce environment integrates with a US Live Application, while its non-production counterpart integrates with a US Sandbox Application.

The environment distinction has a significant implication for testing: customer profiles created in Sandbox are not production profiles. A promotion result validated in Sandbox is evidence that the configuration and integration behave as expected; it is not evidence of real Live customer state, coupon availability, loyalty balances, or campaign-budget consumption.

---

Campaign: a bounded commercial initiative

A campaign is the container for a specific promotional, loyalty, referral, or gamification initiative inside an Application. It translates a business strategy into something that can be scheduled, controlled, measured, and eventually retired.

Campaigns commonly establish the commercial boundaries around their rules, including:

• start and end dates;
• budget;
• the campaign’s purpose and ownership;
• campaign-level behavior and configuration;
• one or more rules that express its decision logic.

A campaign is therefore more than “10% off.” It is the governed business initiative behind that offer.

Consider this objective:

Reduce end-of-season inventory in the US market during August without exceeding a USD 200,000 discount budget.

A suitable campaign captures the initiative’s scope:

• Business scope: US Application
• Time boundary: August
• Financial boundary: USD 200,000 total discount budget
• Commercial purpose: end-of-season inventory reduction
• Promotion mechanism: a coupon or an automatic discount
• Decision logic: contained in one or more rules

Campaigns belong to Applications. This means the same conceptual initiative may need separate campaigns in different Applications when business contexts are intentionally separated. The European market might use a different currency, different discount depth, different timing, and different legal terms; it should not be treated as an incidental variation of the US campaign.

A campaign should be recognizable to a business owner. If a marketing manager cannot explain what a campaign exists to accomplish, it may actually be an ungoverned collection of unrelated rules.

---

Rule: the executable decision logic

A rule is the detailed expression of promotion logic inside a campaign. It evaluates conditions against the context your integration supplies and produces effects when those conditions are satisfied.

At the conceptual level, every rule answers two questions:

1. What must be true?
   These are the conditions: a valid coupon was entered, the basket qualifies, the customer belongs to a target group, or a required event occurred.

2. What should Talon.One decide?
   These are the effects: apply a session discount, discount qualifying items, accept a coupon, add loyalty points, grant an item, or emit a custom effect for the integration to fulfill.

Using the end-of-summer example:

Level	Example configuration
Application	US commerce decisioning scope
Campaign	Late-summer clearance, active for a specified period and constrained by a discount budget
Rule condition	The entered coupon is valid
Rule effect	Discount the session total by 50%

The distinction matters because a campaign can contain several rules without losing its commercial identity. For example, one “Holiday VIP Event” campaign may have rules for:

• VIP customers receiving a higher discount;
• customers using a specific campaign code;
• customers receiving a free item above a threshold;
• an explicit exclusion for selected product categories.

Do not create a separate campaign for every small conditional branch if all branches are part of one governed commercial initiative and share the same lifecycle. Conversely, do not place unrelated offers into one campaign merely because they happen to use the same percentage discount.

A compact architecture test is:

If the budget, date range, business owner, reporting need, or cancellation decision differs, consider whether you have more than one campaign—not merely more than one rule.

---

Customer profile: persistent customer context for decisioning

A customer profile represents a customer in Talon.One over time. It is where promotion-relevant, relatively durable customer context can be made available to campaign rules.

Examples include:

• an integration identifier that links Talon.One activity to the customer in your identity or CRM system;
• loyalty membership status;
• customer segment;
• acquisition source;
• enrollment date;
• customer attributes relevant to eligibility.

The phrase “persistent context” is essential. A profile is appropriate for facts about the customer that may influence multiple interactions. A cart subtotal, shipping method, coupon entry, or order number should not be treated as profile data merely because it is available during checkout. Those facts belong to the current customer session.

The profile also has a clear ownership limitation. Talon.One can maintain a profile representation used for incentive decisioning, but it should normally not become the canonical master record for customer identity, consent, contact data, or account status. Your identity, CRM, or customer-data platform remains authoritative for those business facts. Talon.One receives the minimized subset that its rules need.

This separation supports both privacy and resilience:

• The profile contains only attributes needed for incentive logic.
• The customer’s primary identity system remains usable even if promotion evaluation is unavailable.
• Updates follow a defined source-to-Talon.One contract rather than ad hoc writes from every channel.

At this point, treat the profile as durable customer decisioning context, not as a full customer record. The next lessons will formalize identifiers and attribute placement.

---

Customer session: the current interaction being evaluated

A customer session represents the specific commercial or behavioral context Talon.One is evaluating at a point in time. In a commerce implementation, it commonly represents a cart progressing toward checkout and eventual order completion.

A session can contain facts such as:

• cart items and quantities;
• prices and additional costs;
• entered promotion codes;
• channel or store;
• delivery option;
• a session-specific attribute;
• the session state relevant to the order lifecycle.

The session is where Talon.One receives the facts needed to answer: what applies to this transaction now?

This leads to a clean distinction:

Fact	Better location	Reason
Customer’s loyalty membership	Customer profile	It persists across transactions
Customer acquisition channel	Customer profile	It usually characterizes the customer relationship
Current cart items	Customer session	It is specific to one shopping interaction
Coupon entered at checkout	Customer session	It is a transaction-level attempt to redeem an offer
Current store or delivery selection	Customer session	It can change between transactions
Total lifetime purchases, if used as an eligibility fact	Customer profile or an appropriate loyalty mechanism	It represents durable customer state rather than one cart

One profile can be associated with many customer sessions over time. The reverse is not the intended identity model: a session is not a reusable customer record.

An anonymous journey illustrates the distinction well. A shopper can build a cart before signing in. The session represents that cart interaction. When the shopper authenticates, commerce can associate the ongoing session with the known customer profile, allowing rules to consider profile-based eligibility without losing the cart-specific context. The session remains the cart journey; the profile remains the customer.

The same division protects effect processing. A rule might use profile data to decide that a shopper is eligible for a VIP promotion, but calculate the actual discount from the cart contents in the session. Talon.One returns the decision; commerce applies it to the matching cart revision, as discussed in the previous module.

---

Putting the model together: one checkout decision

Use the following narrative when explaining Talon.One topology to an engineering or business stakeholder:

1. The organization operates a Talon.One account, which provides the governed platform tenant.
2. The commerce channel selects the appropriate Application based on the relevant business scope, such as the US market in Live.
3. Commerce sends the current customer session, and where known the associated customer profile, to that Application through the Integration API.
4. Talon.One evaluates active campaigns in that Application.
5. Each applicable rule evaluates conditions against the submitted context and produces effects.
6. Commerce interprets those effects and applies the approved outcomes to the matching cart or order.

Notice what this model does not imply:

• Talon.One does not become the owner of the order or payment lifecycle.
• A campaign does not directly represent a shopper’s cart.
• A rule is not a substitute for campaign governance, budget, and dates.
• A customer session should not be reused as the durable identity of a person.
• An Application should not be created casually when the business needs shared activity and campaigns.

---

Architecture decision patterns

The following patterns help turn definitions into defensible design decisions.

Pattern: regional Applications with paired environments

A retailer sells in the United States and Europe. Each region has its own currency, time zone, promotion calendar, tax and legal constraints, and marketing team.

A reasonable topology is:

Environment	US business scope	European business scope
Sandbox	US Sandbox Application	EU Sandbox Application
Live	US Live Application	EU Live Application

Each Live Application has its own integration configuration and receives traffic only from its corresponding production commerce context. Campaigns are promoted and tested within the appropriate regional scope.

Pattern: one Application across channels in one commercial market

A retailer operates web, iOS, Android, and assisted sales in one country, using one currency and one shared promotion strategy. A shopper should receive the same coupon and loyalty treatment regardless of channel.

The initial default should be one Application for that commercial scope, with a channel attribute in the session. Rules can then apply channel-specific behavior where genuinely required, without fragmenting customer activity or duplicating campaigns.

Separate Applications may still be justified if the channels have independently governed incentives or a firm data-isolation need—but not simply because they use different client technologies.

Anti-pattern: using Applications for minor campaign categorization

Suppose marketing wants to distinguish “Welcome,” “Seasonal,” and “Clearance” promotions. Creating separate Applications for each category is usually harmful. Campaigns already provide the appropriate lifecycle and organizational unit for those initiatives. Splitting into Applications would prevent the categories from participating in a common decisioning scope and multiply integration routes.

Anti-pattern: copying the entire customer master into Talon.One

A customer profile should contain promotion-relevant information, not every CRM field. Sending extensive contact, identity, and behavioral data increases privacy exposure, payload size, integration complexity, and risk of stale data. Define a minimal contract based on what campaign rules actually need.

---

Sandbox architecture activity

In your sandbox, inspect one existing or newly created Application and write a concise entity map for it. Keep this as an architecture note, not a configuration tutorial.

Record:

• the business scope represented by the Application;
• why it is an Application boundary rather than a campaign category;
• the non-production client environment that should send data to it;
• one campaign objective, its owner, timing, and budget boundary;
• one rule in that campaign, expressed as conditions and effects;
• the profile facts required for the rule;
• the session facts required for the rule; and
• the commerce system that remains authoritative for customer, cart, order, payment, and fulfillment facts.

If you find yourself writing a cart field under customer profile or a permanent customer fact under session, flag it. Those are precisely the ambiguity points that later produce rule defects and difficult reconciliation behavior.

---

Key takeaways

The Talon.One entity model separates concerns deliberately:

• The account is the organizational tenancy and governance boundary.
• An Application is the business decisioning and integration boundary; it contains campaigns and its own API-key context.
• Sandbox and Live are environments, not alternatives to thoughtful Application boundaries.
• A campaign is a governed commercial initiative with lifecycle and operational constraints.
• A rule is the executable conditions-and-effects logic within a campaign.
• A customer profile supplies durable, promotion-relevant customer context.
• A customer session supplies the current interaction or transaction context, such as the active cart.

The next lesson develops this into a richer domain model by relating profiles and sessions to cart items, events, coupons, referrals, and loyalty entities.