How CityScreen Deals is put together
CityScreen Deals is a configurable platform. Some capabilities — deals, proposals, inventory, pricing — ship as fixed product features that work the same way everywhere. Other capabilities — document kinds, counterparty types, custom fields, business processes — are defined by each organization’s administrator using the built-in entity system.
Understanding which parts are fixed and which are configured is the key to reading the rest of this documentation.
Organizations
An organization in CityScreen Deals is a tenant — a self-contained workspace with its own employees, inventory, deals, entity types, templates, and processes. Each organization is configured independently. What you see in your organization depends on what your administrator has set up.
Employees belong to exactly one organization. An employee’s access to data within that organization is governed by roles and permissions assigned through employee groups.
What ships fixed
The following capabilities are part of the product and cannot be changed or removed:
- Deals and stages
-
Every deal moves through a fixed sequence of seven stages: Inquiry, Negotiations, Reserved, Booked, Paid, Done, and Canceled. The stage graph is fixed. An administrator can customize the labels displayed for each stage, but the underlying states and their behavior remain the same.
Deals and deal stages cover this in detail.
- Proposals and pricing
-
A deal contains one or more proposals. The pricing engines for digital placements (frequency, duration, blocks, impressions) and printed placements (daily rates, sale rules) are fixed product logic. Discount tiers, organization-wide discount limits, and per-customer discount caps are built in.
Proposals covers proposal structure and pricing.
- Inventory
-
Digital and printed displays are first-class objects with a fixed field set. The map view, availability timeline, and saturation calculations are product features.
Inventory covers display management and availability.
- The permission model
-
The action hierarchy (read, update, delete) and scope hierarchy (own, group, any) are fixed. How roles compose and how field-level permissions interact with entity-level permissions are product behavior.
Roles and permissions covers the model.
- Sign-in and account security
-
The password policy, two-step verification, protection against repeated failed sign-ins, sessions and the sign-in log are part of every organization. No setting switches them off. An administrator chooses their values, such as the minimum password length, and whether two-step verification is required.
Password policy and sign-in protection and Two-step verification cover them.
What is configured per organization
The following are defined by each organization’s administrator. An organization starts with the product mechanisms, and the administrator fills in the specifics.
- Entity types and custom fields
-
An entity type is a schema that defines a kind of record — a document type, a counterparty type, a price list type, a report type, or any other structured record the organization needs. Each entity type has a set of fields (called variables in the API), which can be strings, numbers, dates, links to other records, sets, collections, maps, or computed expressions.
There are eight super types that determine where a record appears and how the product treats it: Document, Counterparty, Directory, Task, Proposal, Price List, Report, and Employee Group.
The entity system is the dedicated section for this mechanism.
- Document kinds
-
Every invoice, contract, booking order, or credit note you see in an organization is an entity type that an administrator defined, with templates and optionally a business process driving its lifecycle.
Paperwork covers working with documents.
- Counterparty types
-
A customer is one kind of counterparty. The administrator can define additional counterparty types for agencies, media owners, subcontractors, or any other party the organization works with.
Counterparties covers counterparty types.
- Business processes
-
The built-in BPMN engine lets an administrator model and publish processes that automate work — user task assignments, email notifications, document generation, entity updates, and deal state transitions. Processes are defined per organization and can be started manually or triggered by entity events.
Process automation covers modeling and running processes.
- Criteria
-
Criteria are labels that can be applied to deals, customers, and inventory items. The administrator defines the available criteria; sales teams use them for filtering and segmentation.
Criteria covers setup and usage.
- Organization settings
-
Currency, user session duration, the password policy, the two-step verification policy, public inventory access, discount limits, deal stage labels, and proposal defaults are all per-organization settings. Currency is a single organization-wide setting.
Organization settings covers each setting.
- Identity services (licensed)
-
OAuth applications, OpenID Connect, the LDAP directory, personal access tokens and app passwords let other programs call CityScreen Deals, sign employees in through it, or read its directory. These functions are licensed. If your organization’s license does not include them, contact CityScreen. An administrator registers the OAuth applications and LDAP consumers, and each employee creates their own tokens and app passwords.
Identity and API access lists them.
The entity system as the spine
Many sections of this documentation describe features whose visible shape depends on what the administrator has configured. Documents, counterparties, reports, and price lists are all built on entity types. A page that describes one of these mechanisms includes a note linking back to the entity system so you can see how the underlying structure works.
The relationship is:
-
An entity type defines a kind of record and belongs to one of the eight super types.
-
A variable (called "data type" in the interface) defines a field on that entity type — its name, its data type, and its behavior.
-
A record is one instance of an entity type, with values for each of its variables.
This three-level structure — type, variable, record — repeats across every configurable area of the product.