1. Abstract
Board Image Cubes provide an intuitive and user-friendly way to upload and preview images within an application. However, storing image binaries permanently inside the Board data model is not recommended for medium and large implementations because it increases application size, impacts backup and deployment times, and provides limited governance over digital assets.
A modern enterprise architecture uses Board as a temporary image intake platform while delegating long-term storage to the customer's cloud infrastructure (Google Cloud Storage, Azure Blob Storage, AWS S3, or equivalent object storage). Board then retrieves those images dynamically through secure HTTP(S) URLs, typically generated as Signed URLs, SAS Tokens, or Pre-Signed URLs.
This methodology minimizes the Board application footprint, improves scalability, centralizes media governance, and allows images to be updated independently of the Board application.
2. Context
Images are increasingly used inside Board applications for product catalogs, retail planning, manufacturing, quality control, maintenance, supplier management, and many other business scenarios. Although Board supports Image Cubes, these cubes were designed primarily to simplify image acquisition and visualization rather than to serve as a permanent digital asset repository.
Large image collections can significantly increase the size of a Board database because every binary file is physically stored within the data model. As the application grows, this results in larger backups, longer migration times, slower deployments, and unnecessary duplication of media already managed by enterprise cloud platforms.
The recommended architecture therefore separates responsibilities. Board manages business data and image references, while the customer's cloud platform manages the media assets. Secure URLs dynamically connect the two environments.
This approach follows modern cloud architecture principles by making the external storage platform the single source of truth for all images while allowing Board to render them transparently.
3. Content
3.1 Use Board Image Cubes – BLOB - as a Temporary Intake Layer
Board Image Cubes provide an intuitive interface for business users. Images can be uploaded through drag-and-drop, immediately previewed, and managed without requiring technical knowledge.
Despite this convenience, Image Cubes should only be considered a temporary staging area.
Permanent storage inside the Board database introduces several disadvantages:
- image binaries significantly increase the size of the data model
- backups and restore operations become slower
- package deployment times increase
- image replacements require modifications to Board cubes
- no native image versioning or lifecycle management is available
- governance remains outside dedicated Digital Asset Management (DAM) processes
For these reasons, the Board database should be viewed as an ingestion layer rather than the permanent repository.
3.2 Export Images from Board
Once uploaded, images should be exported through a Board procedure into Board Azure Storage.
A consistent naming convention is highly recommended. The filename should correspond to the business identifier associated with the image, for example:
- Product Code
- SKU
- Material Number
- Asset ID
- Customer Code
Using business identifiers simplifies downstream automation while ensuring traceability throughout the entire lifecycle.
3.3 Transfer Images to the Customer Environment
After the export, the customer retrieves the files from Board Azure Storage using the preferred integration mechanism, such as:
- Azure Storage Explorer
- Azure REST APIs
- automated integration scripts
- ETL or orchestration tools
From this point onward, ownership of the media assets is transferred entirely to the customer infrastructure.
3.4 Store Images in Enterprise Cloud Storage
The customer uploads the images into the organization's preferred object storage platform.
Typical options include:
- Google Cloud Storage
- Azure Blob Storage
- Amazon S3
- private cloud object storage
- on-premises object storage
This storage layer becomes the authoritative repository for all media assets.
Additional processing can be performed during this stage, including:
- image compression
- resizing
- thumbnail generation
- metadata enrichment
- naming normalization
- quality optimization
- AI-based image classification
Unlike Board, these platforms provide enterprise-grade governance, scalability, redundancy, lifecycle policies, and storage optimization.
3.5 Generate Secure Image URLs
Rather than exposing storage directly, secure temporary URLs should be generated for every image.
The implementation depends on the cloud provider.
Cloud Provider | Secure URL Technology |
|---|
Google Cloud Platform | Signed URL |
Microsoft Azure | SAS Token URL |
Amazon Web Services | S3 Pre-Signed URL |
These URLs embed authentication information and may include:
- expiration time
- digital signature
- integrity validation
- access permissions
Since Board renders images exclusively through HTTP or HTTPS endpoints, secure URLs provide a straightforward and secure integration mechanism.
3.6 Build the URL Mapping File
The generated URLs are stored in a simple mapping file.
Entity Member | Image URL |
|---|
0001 | https://...signed-url... |
0002 | https://...signed-url... |
0003 | https://...signed-url... |
This file establishes the relationship between business entities and externally stored images.
It becomes the authoritative source consumed by Board.
3.7 Import URLs into Board
The mapping file is uploaded into Board Azure Storage.
A Data Reader imports the URLs into a text cube containing one URL for each entity member.
Whenever the signed URLs expire, the customer simply:
- generates a new set of secure URLs
- rebuilds the mapping file
- uploads the updated CSV
- executes the Data Reader
Since dashboards reference the URL cube rather than fixed image locations, no application modifications are required.
This process can be fully automated through scheduling or external orchestration tools.
3.8 Remove Temporary Images from the Board Database (Recommended)
After verifying that all URLs have been imported successfully and images are rendered correctly, the temporary Image Cube should be cleared.
Removing the binaries delivers several important benefits:
- significantly reduces the Board database size
- accelerates backups and restore operations
- shortens deployment and migration times
- prevents obsolete images from remaining inside the application
- establishes external storage as the single source of truth
A simple Board procedure can automate this cleanup as part of the overall image management workflow.
3.9 Display Images Dynamically
Dashboards reference the URL cube or a Picture Algorithm instead of embedded image binaries.
At runtime, Board retrieves the images directly from the customer's cloud storage.
This architecture provides several operational advantages:
- lightweight Board database
- centralized image governance
- immediate image updates
- scalable storage capacity
- secure access through temporary URLs
- elimination of binary duplication inside Board
Users continue to experience the same seamless image visualization while the application remains significantly smaller and easier to maintain.
4. Security Considerations
External image storage introduces additional flexibility, but security should remain an integral part of the overall solution.
The recommended approach is to expose images through temporary signed URLs rather than making storage containers publicly accessible. Each cloud provider offers a secure mechanism to generate authenticated URLs that remain valid only for a limited period.
Access should follow the principle of least privilege, granting applications and automation processes only the permissions required to upload, retrieve, or generate URLs. Long-lived credentials should never be embedded inside Board procedures or stored in configuration files.
All image access should be performed exclusively over HTTPS to guarantee encrypted communication between Board and the storage platform.
Since signed URLs eventually expire, organizations should implement an automated renewal process. Regenerating the URLs, rebuilding the mapping CSV, and reloading the URL cube ensures uninterrupted image availability without requiring modifications to dashboards or layouts.
Following these practices provides secure image delivery while maintaining centralized governance of media assets.
5. Performance Benefits
Replacing image binaries with external URLs significantly reduces the operational footprint of the Board application while improving maintainability and scalability.
Aspect | Images Stored in Board | External URL Architecture |
|---|
Application Size | Large and continuously growing | Minimal growth, only URL references are stored |
Backup and Restore | Slower due to binary data | Faster because only metadata is backed up |
Deployment and Migration | Larger packages and longer deployment times | Smaller packages with faster migrations |
Image Updates | Requires updating the Image Cube | Replace the image externally and refresh the URL mapping |
Governance | Limited versioning and lifecycle management | Managed by enterprise cloud storage policies |
Scalability | Limited by application size and storage growth | Virtually unlimited through object storage services |
Maintenance | Images managed inside Board | Images managed independently from Board |
Security | Images stored within the application | Secure temporary URLs with controlled expiration |
Single Source of Truth | Images duplicated between systems | External repository becomes the authoritative source |
Overall, the URL-based architecture keeps the Board application focused on analytics and planning while leveraging enterprise cloud platforms for media storage, governance, and security. This separation of responsibilities results in a more maintainable, scalable, and future-ready solution, particularly for implementations managing thousands or millions of images.
7. Conclusion
Using Board Image Cubes as a temporary ingestion layer while externalizing permanent image storage represents a scalable and cloud-native architecture suitable for enterprise implementations.
The methodology combines the ease of image upload available in Board with the governance, scalability, and security offered by modern object storage platforms. By storing only image references rather than binaries, Board applications remain lightweight, backups become faster, deployments are simplified, and media management is fully delegated to the customer's cloud infrastructure.
The approach is cloud-agnostic and can be implemented with Google Cloud Storage, Microsoft Azure, Amazon S3, or any object storage platform capable of exposing secure HTTP(S) URLs. As image libraries continue to grow, this architecture ensures that Board remains focused on analytics and planning while the enterprise storage platform manages digital assets according to established governance policies.
