This guide is intended to provide a reference to the Logos Dashboard system architecture,
systems, structures, logic and workflow. This is by no means a comprehensive reference. The
primary focus is on aspects of the system most important for ongoing support and development
of the system.
Here are the high level functional components of the system and a brief description of their role
in the overall system.
Dashboard Web Server (logosdashboard.com)
The dashboard web server provides the administrative user interface. Functions of this interface
include but are not limited to:
● Donor login management and permissions setup
● Staff login management and permissions setup
● Donation review and reporting
● Member info review and reporting
● Event and Calendar management
● Access to additional modules (Benefits, Finance, Sacramental Register, etc.)
● Broadcast emails to staff/members
The server runs on IIS, ASPX, primarily coded in VB with some C# and much of the business
logic embedded in stored procedures in the supporting MSSQL database.
Dashboard SynchronizationThis is a web service that runs along side Logos Dashboard for handling synchronization
calls from the sync utility running on Logos II desktop solution. All of the call synchronization
is handled within stored procedures prefixed with ddsy_ in the database. This web service
does little more than route xml payloads between the web service interface and the stored
Ministry Connect Web Server (logosconnect.com)
The ministry connect web server has provided the client/member/parishioner interface for
profile, event and contribution reporting interfaces. New clients are using the Logos Connect
web server in its place, and some existing customers have been switched as well. We still have
about 190 organizations using this web server.
The server runs on the same IIS setup as dashboard against the same database as dashboard.
Logos Connect Web Server (*.logosconnect.com)
This replaces the ministry connect web server as the client facing interface for managing
contributions and profile/family information. This does not have an event solution built into it so
clients requiring that functionality must use the old system.
The Logos Connect web server runs on a linux/lighttpd/mysql/php server running on Amazon
Web Services. It does not share the same database as Dashboard. It communicates with
Dashboard through an API and synchronizes with dashboard via synchronization to the Logos II
Logos II is a desktop solution that synchronizes with Logos Dashboard and Logos Connect web
servers. It is either installed on client (customer) servers or on our own hosted environments
accessible to the client via remote desktop. This serves as the bridge for synchronization
between Logos Dashboard and Logos Connect for member and contribution records.
The email server handles the mass mailing requirements of Logos Dashboard and in some
cases Logos II. The email server runs on a LAMP stack on Amazon Web Services and uses
the AWS SES service for sending email. The email server exposes an api that may be used by
Logos II when configured. A cron job runs on the email server and periodically pulls email from
the dashboard server that has queued up to be sent. File attachments are supported.
Resolving the Database
The Dashboard web server uses a single code base and routes to multiple databases
depending on the context of the request. Initially, every request is handled using the
DashboardDB database. Many organizations simply use the DashboardDB database for
all their records. Other organizations elect to have their data in a separate database. The OrganizationDBNames table in DashboardDB database provides a lookup to resolve org ids
to the correct database. Some modules require an explicit configuration for the database on a
given org within the config file. To support these modules a connection string entry is made to
web.config with the name set to the guid of the org.
Users and Organizations
Logos Dashboard contains multiple modules and user records are represented in different ways
depending on what module you are dealing with. Organizations are represented as a member
record which can lead to confusion if you don’t recognize the differences between organizations
and members within the same table. Something to note, all member records are represented by
GUIDs so if there is ever a question of which table a foreign key is referencing with a member
id you can check it with a join. Also note, in some cases there are foreign keys within a single
column referencing multiple tables so proceed with caution and pay attention to record counts
when checking with a join.
User Tables: Members, Users
Admin user records are represented in the Members table. The Members table is not exclusiveto admin users. The Users table is exclusive to admin records and contains the admin login
password hash and salt. The Users table joins Members on MemberId.
Organizations and Hierarchy
User Tables: Members, OrganizationExtended, MemberHierarchy
Organizations are represented within the members table and work into the parent hierarchy
along with members. Every member record that is not an organization will have a ParentId
referencing the MemberId column of an organization. Organizations may have a parent
organization such as a parish relationship to a diocese. Root level organizations such as
diocese have ParentId set to the MemberID of the sa user. See admin users above. A quick
check to see if you are dealing with an organization is to see if the Organization column is set to
a title. A quick check to see if the organization is the root level org is to check if DioceseId is the
same as MemberId.
The MemberHierarchy table doesn’t contain information different from the effective parent
references of member records but represents the hierarchy from sa to a given member as a
single string delimited by ‘/’. This is used within like statements in selects to select all members
and organizations that fall under a parent.
Note: Some common foreign key column names that reference MemberId in the Members table
are: MemberId, OrganizationId, ParishId, ParentId...
VPIN / PeopleFlow Members
User Tables: Members
Member records for VPIN are part of the Members table hierarchy and represent working staff
of the organization. Adding an individual from the VPIN module generates a new record in the
User Tables: Members
The benefits module like VPIN is related to staff members of the organization and references
the Members table as the primary member record.
Ministry Members and Families
User Tables: Ministry_Member, Ministry_Family
Members/parishioners of the organization/church are separate from the Members table
hierarchy though there is a reference through the family record to the Members table for the
organization the ministry member is related to. Families and members are added via the Church
Community tab within dashboard or in the equivalent module of Logos II. These member
records are basis for all events, contributions and member logins. Member records in the
Ministry_Member table are often (though not always) referred to as FlyMemberId instead of
User Tables: Minstry_Member, Ministry_Family, Ministry_Member_Login
The Ministry Connect module builds logins on top of the ministry member structure Ministry members and families must be created before logins can be generated. The Ministry_Member_Logins table contains the password hash and salt for the login.
Contributions originate from Logos II as a check that was received or from Dashboard as a
transaction that was entered by an admin on behalf of a member (i.e. credit card over the
phone) or from a contribution setup by a member in Logos Connect or Ministry Connect.
Every contribution must be against a ministry member record. The ministry member does not
have to have a ministry member login.
Logos Connect allows for contributions made by guests. For these contributions a temporary
member record is created and held for review. On review an admin may choose to create a new
record or merge it to an existing matching record. Once the member has been reviewed the
record is allowed to sync to Logos II.